Re: Unifying the rendering approach

On Fri, Jan 24, 2014 at 6:26 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
 wrote:

> Cues that have no region reference will be put into an anonymous
> region that has:
> * no identifier,
> * the dimensions of the viewport (vw, vh),
> * no scroll,
> * a region anchor of (0,100),
> * a region viewport anchor of (0,100).
>
> The intent is to allow us to create a single rendering path for all cues.
>
> However, there are differences between cues that are currently
> rendered without a region and those that are rendered into a region
> and we have to work these out. We can either try to retain the
> previous behaviour or come up with a better, more integrated way of
> doing it.
>

I actually see the current spec mapped into regions like this:
*) snap-to-lines positioning remains the same and applies now within
regions (which have fixed height, in terms of number of lines, so being
able to put a cue in a specific row of the region makes a lot of sense);
further, overlap avoidance is enhanced with Philip's ideas of animating cue
scrolling.
*) non-snap-to-lines cues are mapped artificially in an anonymous region
with a two-step layout (if no height/width specified, then the region
reduces in the second step to the rendered text sizes). I wrote some of my
ideas here:
http://lists.w3.org/Archives/Public/public-texttracks/2013Dec/0008.html

The default case, with
*) cues that have snap-to-lines set and no region specified end up in the
anonymous region you described at the beginning (hence the same rendering
happens as the current spec)

On Tue, Jan 28, 2014 at 9:39 AM, Philip Jägenstedt <philipj@opera.com>wrote:

> On Tue, Jan 28, 2014 at 3:16 PM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
> > On Mon, Jan 27, 2014 at 8:35 PM, Philip Jägenstedt <philipj@opera.com>
> wrote:
>
> >> I wrote about how I think we should solve this in
> >> http://lists.w3.org/Archives/Public/public-texttracks/2013Nov/0012.html
> >
> > Sorry I missed that. :-(
> >
> >> To reiterate, I'd like to turn the scrolling into part of the overlap
> >> avoidance, so that when a cue would overlap at its preferred position,
> >> one of two things happen:
> >>
> >> 1. The cue (horizontal text at line -1) is moved up until a free space
> >> is found and it is left there. (this is the current spec)
> >
> > This would be used for scroll=false. I like this, it meets with what I
> > suggested above (in more complicated words).
> > Since anonymous regions would have scroll=false, they get this
> > behaviour, which meets with the existing overlap avoidance algorithm
> > for snap-to-lines. So, the new thing would be that this also applies
> > to percentage-positioned cues.
>
> Oh, I hadn't thought about percentage-positioned cues. There's a bug
> with a ton of comments on that topic:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22029


If we map these into anonymous regions (as briefly discussed at FOMS), then
the problem really changes to supporting overlap avoidance for regions,
which I remember we didn't want to support.

Or, region overlap avoidance could be deferred to an upper level mechanism
(on the lines of what Silvia briefly pointed out): each track (VTT or not)
throws a couple of boxes (x, y, width, height) - regions in the case of VTT
- with respect to the viewport and they are re-positioned such that no
overlap happens. The good part is that this problem could be tackled in the
future, when there's a need for it.

>> 2. The cue is moved down until a free space is found. Then, this cue
> >> is moved (optionally animated, i.e. scrolling) up to its preferred
> >> position. Any cue it then overlaps is moved up by an equal amount. Any
> >> cues that overlap in turn are also moved up, and so on until
> >> everything has been moved.
> >
> > Right, that's what happens when scroll=true right now already.
>
> Well, approximately, but it's completely separate from the other
> overlap avoidance mode. My suggestion is to make it part of the
> "Adjust the positions of boxes according to the appropriate steps from
> the following list:" steps.
>
> >> The overlap avoidance mode would ideally be a property of the cue, to
> >> relieve regions of that responsibility.
> >
> > Hmm, interesting. Scrolling would happen within the region, but it
> > would take into account all other cues currently rendered?
>
> I'm suggesting that moving other cues (possibly animated) be an
> overlap avoidance mode, not dependent on regions at all. It would be a
> per-cue thing, so that when a cue that has this mode is rendered, it
> can move any other cue in order to get the position it wants. (You can
> create interesting cases with cues being pushed back and forth, but I
> don't expect this to be a problem since the algorithm handles the cues
> in a deterministic order.)


This sounds great, from my point of view.  In my suggested mapping, I see
this blending in good for snap-to-lines cues within regions (I believe the
approach you're suggesting doesn't care whether the cue lies in a region or
not).

Victor