- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 21 Nov 2013 18:54:02 -0800
- To: Victor Carbune <victor.carbune@gmail.com>
- Cc: Philip Jägenstedt <philipj@opera.com>, "public-texttracks@w3.org" <public-texttracks@w3.org>
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. >> 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? > 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. Cheers, Silvia.
Received on Friday, 22 November 2013 02:54:53 UTC