Re: Unifying regions and non-regions layout algorithms

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.


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