Re: Unifying regions and non-regions layout algorithms

On Fri, Nov 22, 2013 at 2:16 PM, Victor Carbune
<victor.carbune@gmail.com> wrote:
> On Fri, Nov 22, 2013 at 3:54 AM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> On Thu, Nov 21, 2013 at 3:52 PM, Victor Carbune
>> <victor.carbune@gmail.com> wrote:
>>> On Thu, Nov 21, 2013 at 11:54 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>>>> So, I have been to FOMS, and there was a lot of talk about WebVTT.
>>>>
>>>> One of the things we discussed was how to integrate WebVTT Regions
>>>> more deeply into the spec, to not make it look like something bolted
>>>> on to the side. The different layout algorithms for the regions and
>>>> non-regions cases is a key component here.
>>>
>>> I'm writing down the layout algorithms that we have in the spec now:
>>> 1) Position cues using integer line positions
>>> 2) Position cues using percentage line and position values
>>> 3) Position regions using viewport anchor and region anchor
>>>
>>> The proposal that we discussed about within FOMS was to leave 1) integer
>>> line-positioning as it is (in order to keep the simplicity we all love
>>> about WebVTT) and merge 2) and 3) together, through the use of
>>> regions.
>>>
>>> The merge argument is that we can entirely achieve the behavior of 2)
>>> by carefully crafting on the fly anonymous regions wrapping the text,
>>> with their viewportanchor and regionanchor computed such that the
>>> same behavior is honored.
>>>
>>>> I would like to see if we can make regions do nothing other than
>>>> constrain the space available to layout algorithm, so that rendering
>>>> in a region is equivalent to rendering in a smaller video element,
>>>> with the only exception that the vh/vw units would still be relative
>>>> to the entire video.
>>>>
>>>> As a consequence, scrolling would become possible for any cue, in a
>>>> region or not. I haven't actually read the current spec, but I imagine
>>>> the following. First position the cue in its preferred location. If it
>>>> overlaps any other cue, it move it down until it does not overlap.
>>>> Then it would be moved up, pushing along with it as many cues as are
>>>> necessary to not cause (new) overlap. This "push" may be animated or
>>>> not, subject to author stylesheet and user preference.
>>>
>>> I think this can be achieved fairly straightforward, as long as we
>>> have merged 2) and 3) as above, and we can consider the case for 1) as
>>> the simple free line-scan algorithm that we have either within a
>>> region (if the region setting is on the cue), either within the
>>> viewport.
>>>
>>> If the cue has both line and position percentage values *and* region
>>> identifier, then we have two decide between creating an anonymous
>>> region wrapping the cue, or appending it to the existing named region,
>>> without honoring the percentage positions within the region.
>>>
>>> It obviously won't make sense to have percentage positioned cues within a
>>> percentage positioned region :)
>>
>> Actually, we have that right now. It just means that the position (the
>> one that is not in line-dimension) calculation is relative to the
>> region boundaries rather than the viewport boundaries.
>
> I does make sense to me from the left/right boundaries of the region
> (x-percentage). I don't think it's useful for top/bottom within a
> region (y-percentage).

Right. I agree.


>>>> The missing bit is how to switch between the two kinds of overlap
>>>> avoidance we end up with. Here I would suggest making this a cue-level
>>>> setting, and as a possible optimization have global and region-level
>>>> default for cues with no such setting.
>>>>
>>>> Is this something people are interested in exploring?
>>>
>>> Regions were designed to be able to control the position of a fixed
>>> point of a cue group on the video (while honoring font related changes
>>> and wrapping). Having an algorithm for moving regions themselves to
>>> avoid overlap would defeat their purpose and make them quite useless.
>>>
>>> Hence, if we agree to merge 2) and 3) we would only remain with the
>>> line-scan algorithm for avoiding overlap within a region *or* within
>>> the viewport, depending on whether the cue has the region setting or not.
>>
>> If we follow through with the separation between line-positioned
>> (snap-to-lines) and line-percentage-positioned (non-snap-to-lines)
>> cues, I think that we would only have overlap avoidance for
>> line-positioned cues and they would be outside of regions, wouldn't
>> we?
>
> It can be exactly the same algorithm and we could support integer-line
> positioning within a region. I'll be as explicit as possible - suppose
> you have the following:
>
> Region: id=test lines=3
>
> 00:00:00.000 --> 00:00:20.000 region:test line:1
> First
>
> 00:00:00.000 --> 00:00:20.000 region:test line:3
> Second
>
> This would mean that the "test" region will end up with the middle
> line empty and the same algorithm can be applied for positioning as it
> currently happens for cues displayed directly on the viewport. The
> only difference for regions is that when the region ends up with cues
> below its maximum size (in this case, if there would be a cue with
> line:4, for example), the region could animate and scroll such that
> the last line becomes visible, while the first one is hidden.

Are you suggesting we allow cues in regions to have "line" cue
settings, but only if they are snap-to-line "line" cue settings and
not percentage-line-cue-settings? That would be possible... but
wouldn't it defeat the automatic line positioning that the region
provides already?


>>> If people **really** care so much about overlapping avoidance for
>>> non-snap-to-lines case, we could come up with something that only
>>> re-positions these anonymous regions, created on the fly.
>>
>> At FOMS we discussed to leave the overlap-avoidance to line-positioned
>> (snap-to-lines) cues only.
>
> I'm still strongly in favor of this.

Cool, me too.
Silvia.

Received on Tuesday, 26 November 2013 06:27:26 UTC