Re: Unifying regions and non-regions layout algorithms

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

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

Victor

Received on Thursday, 21 November 2013 23:53:37 UTC