Re: Unifying regions and non-regions layout algorithms

On Mon, Nov 25, 2013 at 10:26 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com
> wrote:

> On Fri, Nov 22, 2013 at 2:16 PM, Victor Carbune
> <victor.carbune@gmail.com> wrote:
> > On Fri, Nov 22, 2013 at 3:54 AM, Silvia Pfeiffer
> > <silviapfeiffer1@gmail.com> wrote:
> >> 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.
> >
> > I does make sense to me from the left/right boundaries of the region
> > (x-percentage). I don't think it's useful for top/bottom within a
> > region (y-percentage).
>
> Right. I agree.
>
>
> >>>> 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?
> >
> > It can be exactly the same algorithm and we could support integer-line
> > positioning within a region. I'll be as explicit as possible - suppose
> > you have the following:
> >
> > Region: id=test lines=3
> >
> > 00:00:00.000 --> 00:00:20.000 region:test line:1
> > First
> >
> > 00:00:00.000 --> 00:00:20.000 region:test line:3
> > Second
> >
> > This would mean that the "test" region will end up with the middle
> > line empty and the same algorithm can be applied for positioning as it
> > currently happens for cues displayed directly on the viewport. The
> > only difference for regions is that when the region ends up with cues
> > below its maximum size (in this case, if there would be a cue with
> > line:4, for example), the region could animate and scroll such that
> > the last line becomes visible, while the first one is hidden.
>
> Are you suggesting we allow cues in regions to have "line" cue
> settings, but only if they are snap-to-line "line" cue settings and
> not percentage-line-cue-settings? That would be possible... but
> wouldn't it defeat the automatic line positioning that the region
> provides already?
>

Since region height is always specified in lines, allowing cues to have
line numbers makes a lot of sense for a non-scrolling region. I'm not sure
what the behavior would be for  a scrolling region, however.

Since the region can already be positioned exactly, I'm not sure what the
use case would be for percentage positioning within a region.


>
>
> >>> 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.
> >
> > I'm still strongly in favor of this.
>
> Cool, me too.
> Silvia.
>
>