Re: Unifying the rendering approach

On Tue, Mar 4, 2014 at 12:34 AM, Victor Carbune
<victor.carbune@gmail.com> wrote:
> 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.

Correct. I don't see how this is relevant though. If we give all
non-region cues their own anonymous region box, then we never have to
worry about cue overlap inside regions. All we have to worry about is
region overlap.

Was your intent to separate overlap avoidance for the percentage
positioned non-region cues from overlap avoidance of the regions? That
would potentially cause overlap between non-region non-snap-to-line
cues and snap-to-line cues (in regions), right? Are you suggesting not
to deal with that? Would we even do overlap avoidance for regions?


>>> *) 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.

Hmm... I thought we didn't want to deal with overlap for region-cues.
But you're now also saying we don't want to deal with overlap for
non-region snap-to-line cues. I don't think that was the intention.

I can imagine a single overlap avoidance algorithm that works on lines
only where for percentage-positioned cues a line is deemed occupied if
a part of a cue is in it.


>>> *) 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?

Hold on. Earlier you said that all non-snap-to-lines cue will be
rendered in a single anonymous region that covers the full viewport.
What you are instead describing here is the rendering approach for
snap-to-lines-cues.

If you are indeed creating an anonymous region per non-snap-to-lines
cue, too, then that agrees with what I was arguing for.

Sounds like we are converging!

Philip: if you agree, too, I can start preparing patches.

Cheers,
Silvia.

Received on Monday, 3 March 2014 22:56:14 UTC