Fwd: Mapping percentage-positioned cues to regions

(I accidentally replied only to Philip... forwarding the email to the list now)

On Fri, Nov 22, 2013 at 1:18 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> I'm forking the thread, since I think these two approaches are orthogonal...

I apologize, the thread looked to me more as giving a heads-up from FOMS, sorry.

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

If there is anyone aware of someone relying on this, it would great to
know, but I don't know the best to figure this out. Since regions are
a super-set of this cue percentage positioning scheme,

The main disadvantage I can see for removing the syntax is that
redefining regions each time to change the positions doesn't look like
a friendly light alternative.

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

The idea would be to honor the region's anchor point, the "pin-point"
on top of the video viewport. This means that no matter the ending
size of the box of the region, the anchor within this box is over the
same point on the video viewport.

Assume we have "height:auto width:auto" and a chunk of text (multiple
cues) belonging to it. Now, what follows should essentially be a
two-step layout: first we artificially set the (height, width) to
(video height, video width) and simply render the lines within this
box following the the CSS wrapping rules or manually entered line
breaks.

In most of the cases, we will actually end up with a box which is of
smaller sizes (at least in one of the dimensions) and then we
translate the origin of the resulted rendered box (considering the
actual sizes) with (-regionanchorX%, -regionanchorY%) and we honor the
region anchor.

This is probably the simplest approach; one could also consider an
heuristic with the idea of rendering the text just until it hits video
margins (inspiring from ideas that are currently in the spec) and
maybe re-position the resulted cue box, but I didn't think about this
approach in too much detail, as I don't really think it's necessary if
one will be using a fixed width and auto height, for example.

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

Well, I guess if someone comes up with a deterministic solution of
reasonable complexity, it could just be there. I just don't find
extremely important.

Victor

Received on Friday, 6 December 2013 14:57:40 UTC