Re: Mapping percentage-positioned cues to regions

On Fri, Nov 22, 2013 at 11:18 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> 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.

Getting rid of line-percentage-positioned cues was the goal and I
don't think that was Victor's intention. I don't think we should
change any of the syntax at this stage, but just try to be more clever
in the rendering section.

Are you trying to get rid of line-percentage-positioned cues? (I guess
I'm still struggling to understand what you're actually proposing if
it's not what Victor proposed and what we discussed at FOMS.)


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

When we render line-percentage-positioned cues into an anonymous
region, then the regions needs to be as big as the video viewport. I
think that's where the "auto" value came in.


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

"auto" could indeed mean that an anonymous region is as big as the
video viewport, or as big as the cue needs to be. We could make it a
flexbox both in width and height with max-width and max-height being
the video viewport. I think that could work. I don't know yet which
would be better...

If we only do overlap avoidance within regions, then it's probably
simpler if "auto" just means the full video viewport.


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

It would be against the needs of CEA708 to reposition regions. There,
regions simply have a priority which places them on top of each other
in a particular order. That's easy to map to CSS, which was also what
I originally envisaged when trying to replicate CEA708 windows for
WebVTT: http://www.w3.org/community/texttracks/wiki/MultiCueBox . That
page covers more of the CEA708 features than we now have in the WebVTT
spec - alas, I think what we have in the spec satisfies the FCC
requirements. The remaining features can always be added at a later
stage - they didn't seem urgent.

Cheers,
Silvia.

Received on Tuesday, 26 November 2013 21:20:13 UTC