Mapping percentage-positioned cues to regions

I'm forking the thread, since I think these two approaches are orthogonal...

On Fri, Nov 22, 2013 at 12:52 AM, 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.

Yes, I think this is also something we should continue discussing, but
as far as I can tell it is orthogonal to the rewrite I have in mind.

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

I don't see why my suggested simplification depends on your suggested
simplification. Even if we were to keep percentage-positioned cues, it
still seems very much possible to weave the two rendering paths
together.

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

I actually don't think that's crazy, difficult to spec, or difficult
to implement, but I also don't know if it's actually useful...

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

I think that whether or not we do overlap avoidance for regions
themselves is also orthogonal to my initial suggestion, so I didn't
say anything about it.

Now, having said that I think all of these issues can be dealt with
separately, here are my un-polished thoughts on your suggestions:

Getting rid of percentage-positioned cues is not something I feel
particularly strongly about either way. If we want to get rid of them
in favor of using regions, the first thing we should attempt is to
just drop the syntax and rendering algorithm for percentage
positioning. Only if we have existing content that would degrade badly
do we need to consider mapping the existing syntax to implicit
regions.

Further, one key thing we would need in order to map
percentage-positioned cues to regions is a way for regions to grow as
needed, so that text is never hidden. At FOMS you suggested regions
with "auto" values for the width and height, can you outline here how
you think that should work? An alternative approach is to always cause
regions to expand to not hide content, but I don't have a concrete
suggestion for how to do that.

About overlap avoidance for regions, I don't think it's a terrible
idea, *especially* if regions can grow in order to not hide text.
After all, if you have multiple tracks, independently authored, which
have overlapping regions, the only options are to have some text
unreadable, or to move one or both of the regions. However, I don't
have a concrete suggestion for how to do this, yet, and it doesn't
seem to really impact either of our suggested changes.

Philip

Received on Friday, 22 November 2013 12:19:01 UTC