Re: Unifying the rendering approach

On Mon, Mar 3, 2014 at 12:53 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Mon, Mar 3, 2014 at 10:41 PM, Victor Carbune
> <victor.carbune@gmail.com> wrote:
>> On Mon, Mar 3, 2014 at 12:11 PM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>>
>>> Aha! I see. The first case is so as to keep the line counting correct
>>> for snap-to-lines cues, I assume? Couldn't we make these two cases
>>> into a single case if the line positioning both for snap-to-lines and
>>> for non-snap-to-lines is done on the anonymous region that wraps each
>>> cue? What's the advantage of splitting these two cases?
>>
>> If we throw non-snap-to-lines cues within regions it means that we
>> need to support a rendering case for these cues within regions, and
>> also support named regions on them.
>
> I don't think so, since it will be the region that is placed, not the
> cue. So, the cue inside the region is still placed "snap-to-line" even
> if the line is basically just a single line (minus line wrapping and
> newlines).

Well, it's one thing to deal with snap-to-lines, where you only move
one line on top of the other until they don't overlap, and another one
is to deal with overlap between a percentage-positioned cues together
with line-positioned cues; moving lines is simple and straightforward.

>> The advantage of not having non-snap-to-lines cues within regions are:
>
> I agree, we should not have non-snap-to-line cues inside regions. But
> what if the region itself was placed non-snap-to-line, while the cue
> inside it wouldn't.

Yes, I think we're converging to the same idea: basically you set the
region anchor and viewport anchor of the anonymous regions that ends
up surrounding the cue, such that the same positioning is obtained.

>> *) Simple rendering steps within a region (pretty much everything that
>> currently is for snap-to-lines will just be moved within a region).
>
> Agree.
>
>> *) No need to think what happens if some percentage-positioned cue
>> overlaps a line-positioned cue (see "underspecced overlapping
>> positioning" bug)
>
> We still have to deal with overlapping cues, no matter whether they
> are in snap-to-lines regions or in non-snap-to-lines regions.

This would move to dealing with overlapping regions - which we decided
we don't want to support, right? Or at least differ it to a higher
level mechanism that would deal with all the caption boxes from any
format ending up on the screen.

>> *) No boxes in boxes. Only the text lines generated by CSS wrapping or
>> manual author wrapping (snapped into numerical lines of a region).
>
> They are boxes, too, but yes, I agree.
>
>> *) Better abstraction: author can already obtain exactly the same
>> positioning using regions that they can with percentage-positioned
>> cues. Why integrate two different elements solving the same problem
>> together, if we can keep only one?
>
> Because it avoids another big case statement in the rendering
> algorithm. This way we have all three cases in one branch rather than
> 2 different branches. Also, this is just about the rendering, since
> we're still keeping the two different ways of specifying positioning
> (cues with line cue setting and cues inside regions).

Wouldn't this simply be something like: if non-snap-to-lines=true
create on the fly an anonymous region, render the text in it according
to the rules in "paragraph where layout in a region is done" and then
resize the anonymous to perfectly match the cue and set the region
positioning parameters accordingly?

> (Also: thanks for the deja vue - maybe this time with less
> mis-understandings. ;-)
>
>
>>>> *) User-defined regions & cues with region identifier and snap-to-lines=true.
>>>>
>>>> So there's no cue with snap-to-lines=false that ends up in a region.
>>>
>>> A named region, I assume. Since the second case has
>>> snap-to-lines=false cues in an anonymous region.
>>
>> As I mentioned above, I don't see any value in having
>> non-snap-to-lines and snap-to-line cues in a single region, no matter
>> if it is the large default anonymous region for snap-to-lines cues or
>> a named region. It means you have to specify a rendering algorithm
>> that combines both.
>
> Right, I never suggested that. However, I was clarifying your
> statement that " there's no cue with snap-to-lines=false that ends up
> in a region", which isn't true, since in your second non-snap-to-lines
> cues do actually end up in a region.

Well, right. The text in a non-snap-to-lines cue ends up in a region,
and that region would then positioned.

>> A more personal comment: I feel that non-snap-to-lines cues are hard
>> to use for authors that want to actually position things precisely on
>> top of the video, and I'm not aware of other use-cases for it, so I
>> would even go as far as removing them as soon as we support regions.
>
> I don't think we should. I think some people will find the anchors for
> positioning easier and others will prefer the line/position cue
> settings. I don't think we should remove either.
>
>> But since they are already here, we can easily keep them for
>> backwards-compatible purposes with wrapped anonymous regions
>> fulfilling the same positioning behavior.
>
> Agreed.
>
> Silvia.

Received on Monday, 3 March 2014 13:35:23 UTC