Re: Unifying regions and non-regions layout algorithms

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.


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


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

Cheers,
Silvia.

Received on Friday, 22 November 2013 02:54:53 UTC