Re: Unifying regions and non-regions layout algorithms

On Tue, Nov 26, 2013 at 8:04 PM, Victor Carbune <victor.carbune@gmail.com>wrote:

> On Tue, Nov 26, 2013 at 7:55 AM, Loretta Guarino Reid <
> lorettaguarino@google.com> wrote:
>
>>
>>
>>
>> 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.
>>
>
> This is what I had in mind. Having a scrolling region implies having a
> fixed number of lines, so if a cue has line:4 in a region with height:3, it
> could simply trigger the scrolling effect of a region.
>

OK, so I think that gets back to what Philip proposed and it's just an
extension of what we have currently specced for syntax and parsing of
regions. I think that can work.

Cheers,
Silvia.