Re: Unifying the rendering approach

On Sun, Feb 23, 2014 at 12:44 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> Hi Philip,
>
> On Sun, Feb 23, 2014 at 4:14 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>> On Sun, Feb 23, 2014 at 11:05 AM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>> Victor, Philip, all,
>>>
>>> Does this make sense to you? If so, I can start preparing a branch
>>> with patches for this.
>>
>> I've read all the mails in this thread but don't see a concrete
>> suggestion for unification. What concrete changes are we talking
>> about, and what are they unifying?
>
> I was referring in particular to the examples that I had sent with the
> suggestions at the end.

Thanks, here it is again so I can reply:

> * the spec currently says that cues in region are added one line at a
> time below existing cue lines -> this will need to be conditioned on
> the cue being in a scrolling region only
> * the spec currently prohibits "line" settings on cues in regions -
> this should be allowed for cues that are not in scrolling regions
>
> Once that is done, the rendering of non-scrolling regions and
> anonymous regions is identical with only scrolling regions having some
> special rules. That should make it easier to consolidate the rendering
> section. Have I overlooked any corner cases?

While I don't know precisely which bits of the spec will be changed,
this sounds good. However, the unification I'm most interested in is
actually that of scrolling regions with the non-regions case, which is
what the rest of my email is about:

>> As for an implicit anonymous region, I think that is the wrong way to
>> phrase this in the spec.
>
> I'm surprised about this because I thought at FOMS we had all agreed
> that this would be the right approach.

I certainly agreed that we should try to make the two cases more
similar, but I hadn't actually read the rendering algorithm for
regions at FOMS, so the issue of the big fork in the rendering
algorithm wasn't really clear to me.

>From a DOM/CSS point of view, the output of the rendering algorithm is
a bunch of boxes that are children of the video element. With regions
they're instead contained in a regions box that is a child of the
video element. That's why I think an anonymous or implicit region is
an odd way to phrase this: there's no need to insert an extra box that
is the same size as the video for cues that aren't in a region. It's
not an anonymous region, it's no region at all.

(I suspect that we're simply using words slightly differently, since
we haven't gone into the details of how to unify the rendering
before.)

>> Certainly currently it would be completely
>> wrong since a region changes the rendering algorithm completely.
>
> Not really. Most of the rendering between the region and non-region
> paths is identical. This is why creating an anonymous region around
> the normal rendering algorithm and making the rest of the non-region
> rendering approaches available to regions should work.

There's a fork in the rendering algorithm at "If cue's text track cue
region is null, run the following substeps". Only the non-regions case
does "Apply WebVTT cue settings". This fork is what I want to
eliminate to the greatest extent possible. Ideally, the only between
regions and no regions in the rendering algorithm should be what the
parent box is, I think.

>> I'd
>> like us to have an internal concept of constraining the size available
>> for layout that is honored for snap-to-line cues and that a region
>> simply establishes such a constraint. We don't need an anonymous
>> region because lack of a region is simply a lack of such a
>> constraint...
>
> Are you suggesting to completely drop the region rendering path and
> try to reconstruct it within the normal layout algorithm by
> constraining the available size for layout for snap-to-line cues? That
> would mean that this is the only difference between regions and
> non-regions? However, what do you do with the other "constraints":
> width, region anchor, viewport anchor, and the scrolling? You can't
> replicate scrolling unless you have an explicit box for the cues and
> for the regions. Just restricting the size for the background box
> doesn't resolve this IMO.

Yes, the details are fuzzy, but that's exactly the path I think we
should take. As I've outlined in another mail, I think that scrolling
should be a property of individual cues, not something that they get
from being in a region.

>> (Not honoring constraints for non-snap-to-line cues gets rid of the
>> percentage-positioned-cue-in-region case which AFAIK there is no use
>> case for.)
>
> Are you referring to the case of giving a cue a position offset in a region?
> I know that this is an explicit feature of CEA708. It allows rendering
> of the following (i.e. indented lines in a region):
>
> ---------
> | This line is left aligned in the region.
> |      This line has an indent.
> | This line is again left aligned.
> ----------
>
> Each line is a separate cue in this example.
> Ken (+CC) can clarify if this is a feature of CEA708 (PAC) is in
> actual use - I just made sure we can replicate it in regions.

I can't find anything in the regions rendering path that does anything
with any of the cue-level position settings, that's all in the "Apply
WebVTT cue settings" which isn't run. Am I missing it, or is it TDB?

In any event, I don't think it would actually involve any extra
complexity to have non-snap-to-lines cues scrolling in a region, but
it certainly seems like an odd case. The indent case you give can be
done with position/size/align AFACIT, it wouldn't require resorting to
a percentage line.

(It's great that we're finally discussing the specifics of this stuff!)

Philip

Received on Sunday, 23 February 2014 07:48:30 UTC