Re: Unifying the rendering approach

On Tue, Jan 28, 2014 at 12:11 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com
> wrote:

> On Tue, Jan 28, 2014 at 8:46 PM, Victor Carbune
> <victor.carbune@gmail.com> wrote:
> > 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.
>
> That's what I tried to say, too, in that first email.
>

I'm sorry, then I misunderstood your line stating that "snap-to-lines: cues
in a region don't have snap-to-lines positioning.", as I would say that
snap-to-lines positioning remains the same within the region.

 > *) 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
>
> Hmm... why do we need to change the dimensions of regions to avoid
> overlapping cues? I don't think we need to deal with region overlap.
>

It's not about overlapping - you need the final region surrounding the cue
to match it's contents in order to honor the authored
percentage-positioning. So if your anonymous region surrounding the cue
ends with a larger size, translating it with (-regionAnchorX%,
-regionAnchorY%) ends up positioning the cue differently.

> 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)
>
> Right.
>
>
> Silvia.
>
> > 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
>