Re: Unifying regions and non-regions layout algorithms

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).

>>> 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.

>> 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.

Received on Friday, 22 November 2013 03:17:03 UTC