Re: Unifying the rendering approach

On Tue, Jan 28, 2014 at 4: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.
> *) 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

I'm sorry I didn't reply to this at the time, I had drafted a reply
but then got distracted by other things.

>From a very high level, the idea of having only snap-to-line cues and
a single mechanism for absolute positioning is appealing, because it
sounds like it *could* simplify the model, and avoids the somewhat odd
absolutely positioned cues within absolutely positioned regions.

So, the first step is to get rid of the snap-to-lines concept and just
always snap. That's nice, it makes the model simpler, both in API and
rendering algorithm.

It also makes WebVTT less capable, so how do we bring back absolute
positioning? For fixed-size regions it's rather uncomplicated, and for
auto-sized regions this is what the mail from December says:

> Assume we have "height:auto width:auto" and a chunk of text (multiple
> cues) belonging to it. Now, what follows should essentially be a
> two-step layout: first we artificially set the (height, width) to
> (video height, video width) and simply render the lines within this
> box following the the CSS wrapping rules or manually entered line
> breaks.
>
> In most of the cases, we will actually end up with a box which is of
> smaller sizes (at least in one of the dimensions) and then we
> translate the origin of the resulted rendered box (considering the
> actual sizes) with (-regionanchorX%, -regionanchorY%) and we honor the
> region anchor.

OK, do layout, shrink to fit, and then treat that box as a unit,
anchoring it where it's supposed to be. I see no reason why this is a
terrible idea so far. What happens when cues are added or removed to a
region? I assume that each render would work the same, so that the
region can grow and shrink dynamically?

Is my understanding correct? At this point I'm somewhat optimistic
about this approach. I think that in order to see if it really works
we have to flesh out the model in detail, go through all the modes of
rendering we can currently achieve and see if they can be represented
in the new model. If the new model turns out to be *more* powerful,
then we need to make sure there are actually (reasonable) use cases
for the new things.

Silvia, your turn :)

(I've avoided talking about how to map the current model to a new
model, because I think that if enough content depends on the current
model then we shouldn't mess with it.)

Philip

Received on Wednesday, 29 January 2014 10:25:36 UTC