Re: Unifying the rendering approach

On Mon, Mar 3, 2014 at 11:55 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
>
> 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?

I want to avoid solving overlap avoidance between non-snap-to-lines
and snap-to-lines cues by:
*) ensuring they never end up in the same region (thus, I don't see a
need to support non-snap-to-lines cues with author-specified regions,
there's no use-case for this situation)
*) deferring the overlap avoidance mechanism to 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.

We need unification: imagine, exaggerating here, having
{snap-to-lines, non-snap-to-lines} x {region, non-region} type of
cues.

One solution is for all cues to end up in regions, anonymous or
author-specified, for rendering purposes.

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

This was for snap-to-lines cues with no author-specified region.

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

Yes, I want an anonymous region for each non-snap-to-line cue.

For a snap-to-line to line cue I see the two cases I mentioned:
*) There's no region attribute set and then the cue belong to the
default region with the full-viewport size
*) There's a region attribute set and then the cue ends up in that
particular region.

Received on Tuesday, 4 March 2014 10:18:05 UTC