Re: Unifying the rendering approach

On Tue, Mar 4, 2014 at 10:46 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
>
> On 4 Mar 2014 20:58, "Victor Carbune" <victor.carbune@gmail.com> wrote:
>>
>> 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.
>
> Agree. That's why I wouldn't want all non-snap-to-lines cues end up in a
> single full-viewport-sized region.
>
>> > >>> *) 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.
>
> Yes, that's the best approach IMO.
>
>> > 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.
>
> Oh! But then you can't do overlap avoidance with these cues either.

Well if all the snap-to-lines cues without an author-specified region
go into the same anonymous region of the size of the video, then you
are just using the cue snap-to-lines positioning algorithm to do
overlapping.

> I'd rather they go into  individual regions, too, and are all dealt with by
> a single overlap avoidance approach that works on regions.

Then how do you honor line positioning for a cue that has no region,
and has line:3 attribute? You will have to make position the region in
line 3 of the video viewport, rather than the text lines of the cue in
a 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.
>
> Silvia.

Received on Wednesday, 5 March 2014 07:29:46 UTC