Re: Unifying the rendering approach

On Mon, Mar 3, 2014 at 5:47 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Mon, Feb 24, 2014 at 7:06 PM, Victor Carbune
> <victor.carbune@gmail.com> wrote:
>> On Tue, Feb 18, 2014 at 7:17 AM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>> On Mon, Feb 3, 2014 at 5:51 PM, Victor Carbune <victor.carbune@gmail.com> wrote:
>>>> On Sun, Feb 2, 2014 at 3:22 AM, Silvia Pfeiffer
>>>> <silviapfeiffer1@gmail.com> wrote:
>>>>>
>>>>> On Tue, Jan 28, 2014 at 11:10 PM, Victor Carbune
>>>>> <victor.carbune@gmail.com> wrote:
>>>>> > On Tue, Jan 28, 2014 at 12:11 PM, Silvia Pfeiffer
>>>>> > <silviapfeiffer1@gmail.com> wrote:
>>>>> >>
>>>>> >> On Tue, Jan 28, 2014 at 8:46 PM, Victor Carbune
>>>>> >> <victor.carbune@gmail.com> wrote:
>>>>> >> > On Fri, Jan 24, 2014 at 6:26 AM, Silvia Pfeiffer
>>>>> >> > <silviapfeiffer1@gmail.com>
>>>>> >> > wrote:
>>>>> >> >
>>>>> >> >> Cues that have no region reference will be put into an anonymous
>>>>> >> >> region that has:
>>>>> >> >> * no identifier,
>>>>> >> >> * the dimensions of the viewport (vw, vh),
>>>>> >> >> * no scroll,
>>>>> >> >> * a region anchor of (0,100),
>>>>> >> >> * a region viewport anchor of (0,100).
>>>>> >> >>
>>>>> >> >> The intent is to allow us to create a single rendering path for all
>>>>> >> >> cues.
>>>>> >> >>
>>>>> >> >> However, there are differences between cues that are currently
>>>>> >> >> rendered without a region and those that are rendered into a region
>>>>> >> >> and we have to work these out. We can either try to retain the
>>>>> >> >> previous behaviour or come up with a better, more integrated way of
>>>>> >> >> doing it.
>>>>> >> >
>>>>> >> >
>>>>> >> > I actually see the current spec mapped into regions like this:
>>>>> >> > *) snap-to-lines positioning remains the same and applies now within
>>>>> >> > regions
>>>>> >> > (which have fixed height, in terms of number of lines, so being able to
>>>>> >> > put
>>>>> >> > a cue in a specific row of the region makes a lot of sense); further,
>>>>> >> > overlap avoidance is enhanced with Philip's ideas of animating cue
>>>>> >> > scrolling.
>>>>> >>
>>>>> >> That's what I tried to say, too, in that first email.
>>>>> >
>>>>> >
>>>>> > I'm sorry, then I misunderstood your line stating that "snap-to-lines: cues
>>>>> > in a region don't have snap-to-lines positioning.", as I would say that
>>>>> > snap-to-lines positioning remains the same within the region.
>>>>>
>>>>> Right, what I meant is that right now regions don't allow for line
>>>>> positioned cues, but that we can accommodate that, in particular in
>>>>> anonymous regions that cover the full viewport, but also more
>>>>> generally in all regions. Currently regions have a default number of 3
>>>>> lines, so line positioning within those is somewhat restricted unless
>>>>> the author extends the number of lines.
>>>>>
>>>>>
>>>>> >> > *) non-snap-to-lines cues are mapped artificially in an anonymous region
>>>>> >> > with a two-step layout (if no height/width specified, then the region
>>>>> >> > reduces in the second step to the rendered text sizes). I wrote some of
>>>>> >> > my
>>>>> >> > ideas here:
>>>>> >> > http://lists.w3.org/Archives/Public/public-texttracks/2013Dec/0008.html
>>>>> >>
>>>>> >> Hmm... why do we need to change the dimensions of regions to avoid
>>>>> >> overlapping cues? I don't think we need to deal with region overlap.
>>>>> >
>>>>> >
>>>>> > It's not about overlapping - you need the final region surrounding the cue
>>>>> > to match it's contents in order to honor the authored
>>>>> > percentage-positioning.
>>>>>
>>>>> I don't follow. Why does the region have to be shrunk for the cue to
>>>>> be correctly positioned?
>>>>>
>>>>>
>>>>> > So if your anonymous region surrounding the cue ends
>>>>> > with a larger size, translating it with (-regionAnchorX%, -regionAnchorY%)
>>>>> > ends up positioning the cue differently.
>>>>>
>>>>> I don't follow this problem either. Anonymous regions cover the video
>>>>> viewport and are anchored to the bottom left corner. What is the
>>>>> "larger size" you are referring to? Can you maybe explain via an
>>>>> example?
>>>>
>>>> Example: Let's suppose there's a cue with only 1 line, and a region
>>>> that contains is anchored at regionAnchor (50%, 100%) - so
>>>> middle-bottom, and viewportAnchor (50%, 50%) so middle point of the
>>>> video.
>>>>
>>>> This implies that the bottom of the region is over the middle point of
>>>> the video. If the region has height 3, than we have two empty lines at
>>>> the bottom, and our cue line at the top. If the region would have
>>>> height 1, then the cue line will be at the bottom of the region, and
>>>> directly on top of the video center. This is why the region size
>>>> matters.
>>>
>>> I think this is more a matter of where a cue is rendered by default
>>> within a region. The spec for non-region cues puts cues by default at
>>> the bottom of the video viewport. I think in future it should put it
>>> by default at the bottom of the region. Thus, in what you are
>>> describing, the one line cue will end up in line 3 and not in line 1.
>>> That is: unless the region is a scrolling region, in which case the
>>> region is resized to 1 line.
>>
>> I was just explaining here why the region size matters - gets
>> positioned differently; where the cue ends up in the region by default
>> (first or last line) is just a detail.
>
> I think we mean the same thing. I explained to Philip how to do the
> scrolling and that also included changing the *rendered* region height
> by adapting the "top" attribute, though I am keeping min-height to 0
> and max-height to the number of lines (converted to px). Thus, I'm
> leaving the height adaptation to CSS.
>
>
>>>> This approach has the following advantages:
>>>> *) We avoid weird absolute-positioned cues in absolute-positioned regions.
>>>
>>> What's the problem here?
>>
>> I don't see any use case for this, thus why support it? It just looks
>> like it enhances 'chaos' in a region. Just snapping lines within
>> regions covers all the use-cases, IMO.
>
> OK.... But you can snap a line in a region. E.g. in a 3-line region
> you can position it in line 1, 2, or 3, right? Then you still have to
> position these lines absolutely inside the region, don't you?

Yes. I am (maybe mistakenly) using the term "absolute" positioning
only when both horizontal and vertical attribute are percentages
(non-snap-to-lines case).

I'm supporting line-snapping within regions (mentioned this from the
first email on this thread [1])
http://lists.w3.org/Archives/Public/public-texttracks/2014Jan/0043.html

>> Having absolute-positioned cues makes me conceptually transform the
>> cue text into a box, and position it within another box, which is the
>> region. I'd like to think that the only boxes we will have in this
>> spec will be the regions. The cues will just be some wrapped text
>> lines, automatic or due to author line breaks (should be treated the
>> same).
>
> Right, I see why you want to put anonymous regions around every single
> non-region cue. You just want positioned boxes that are either
> positioned to contain a single cue, or positioned to contain scrolling
> cues or automatically positioned cues. You don't want to extend
> regions to contain explicit line positioning.

I don't want percentage-positioned cues within regions. They don't make sense.

When we have a percentage-positioned cues, I just want to wrap it in
an anonymous region and set the positioning attributes of the regions
such as we have backward compatibility for non-snap-to-lines case.

>>> I'll draw up some examples of how I think it could work without
>>> resizing regions. That will also avoid re-drawing regions every time
>>> another cue is rendered into the region.
>>
>> I read your following examples, and the main disagreement point is
>> along the same lines: non-snap-to-lines cues in regions. If we want to
>> unify, supporting only snap-to-lines cues within the region is the
>> first step,
>
> Regions as they are currently specified don't have any line settings,
> so I assume you want to leave it that way? If so, we indeed can't
> position non-region cues into a single anonymous region, since within
> regions we don't do line positioning.
>
>
>> mapping non-snap-to-lines-cues to regions auto-sized to
>> match cue text is the second.
>
> I think I understand where you're coming from with this now.
>
>
>> One other major advantage of not supporting non-snap-to-lines cues
>> within regions is that you will avoid overlap completely (since text
>> can only snap in lines).
>
> Right, that's why regions are currently specified not to have line settings.
>
>> The last aspect is the anonymous region of the size of the video,
>> while I'm not entirely happy about it, I already mentioned that I like
>> it because it keeps the simplicity of VTT - you can have a cue with
>> text and line index and you're done.
>
> Now I am confused. Where do we now have anonymous regions of the size
> of the video in your model?

I'll just rewrite:
*) An anonymous region with video width & height for all the cues that
have snap-to-lines=true and no region specifier.
*) One anonymous region with auto width & height wrapping each
snap-to-lines=false cue that has no region specifier
*) User-defined regions & cues with region identifier and snap-to-lines=true.

So there's no cue with snap-to-lines=false that ends up in a region.

>> (I know the thread has already gone further into details of applying
>> cue setting within regions, but I think we should step back for now
>> and agree on positioning elements; a different thread for cue settings
>> might be a good idea).
>
> I don't want to change anything about how regions are specified in the
> current spec other than the rendering section. I hope we're still in
> agreement on that?

Yes.

Victor

Received on Monday, 3 March 2014 09:41:57 UTC