Re: Unifying the rendering approach

On Mon, Feb 3, 2014 at 5:51 PM, Victor Carbune <victor.carbune@gmail.com> wrote:
> On Sun, Feb 2, 2014 at 3:22 AM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>>
>> On Tue, Jan 28, 2014 at 11:10 PM, Victor Carbune
>> <victor.carbune@gmail.com> wrote:
>> > On Tue, Jan 28, 2014 at 12:11 PM, Silvia Pfeiffer
>> > <silviapfeiffer1@gmail.com> wrote:
>> >>
>> >> On Tue, Jan 28, 2014 at 8:46 PM, Victor Carbune
>> >> <victor.carbune@gmail.com> wrote:
>> >> > On Fri, Jan 24, 2014 at 6:26 AM, Silvia Pfeiffer
>> >> > <silviapfeiffer1@gmail.com>
>> >> > wrote:
>> >> >
>> >> >> Cues that have no region reference will be put into an anonymous
>> >> >> region that has:
>> >> >> * no identifier,
>> >> >> * the dimensions of the viewport (vw, vh),
>> >> >> * no scroll,
>> >> >> * a region anchor of (0,100),
>> >> >> * a region viewport anchor of (0,100).
>> >> >>
>> >> >> The intent is to allow us to create a single rendering path for all
>> >> >> cues.
>> >> >>
>> >> >> However, there are differences between cues that are currently
>> >> >> rendered without a region and those that are rendered into a region
>> >> >> and we have to work these out. We can either try to retain the
>> >> >> previous behaviour or come up with a better, more integrated way of
>> >> >> doing it.
>> >> >
>> >> >
>> >> > I actually see the current spec mapped into regions like this:
>> >> > *) snap-to-lines positioning remains the same and applies now within
>> >> > regions
>> >> > (which have fixed height, in terms of number of lines, so being able to
>> >> > put
>> >> > a cue in a specific row of the region makes a lot of sense); further,
>> >> > overlap avoidance is enhanced with Philip's ideas of animating cue
>> >> > scrolling.
>> >>
>> >> That's what I tried to say, too, in that first email.
>> >
>> >
>> > I'm sorry, then I misunderstood your line stating that "snap-to-lines: cues
>> > in a region don't have snap-to-lines positioning.", as I would say that
>> > snap-to-lines positioning remains the same within the region.
>>
>> Right, what I meant is that right now regions don't allow for line
>> positioned cues, but that we can accommodate that, in particular in
>> anonymous regions that cover the full viewport, but also more
>> generally in all regions. Currently regions have a default number of 3
>> lines, so line positioning within those is somewhat restricted unless
>> the author extends the number of lines.
>>
>>
>> >> > *) non-snap-to-lines cues are mapped artificially in an anonymous region
>> >> > with a two-step layout (if no height/width specified, then the region
>> >> > reduces in the second step to the rendered text sizes). I wrote some of
>> >> > my
>> >> > ideas here:
>> >> > http://lists.w3.org/Archives/Public/public-texttracks/2013Dec/0008.html
>> >>
>> >> Hmm... why do we need to change the dimensions of regions to avoid
>> >> overlapping cues? I don't think we need to deal with region overlap.
>> >
>> >
>> > It's not about overlapping - you need the final region surrounding the cue
>> > to match it's contents in order to honor the authored
>> > percentage-positioning.
>>
>> I don't follow. Why does the region have to be shrunk for the cue to
>> be correctly positioned?
>>
>>
>> > So if your anonymous region surrounding the cue ends
>> > with a larger size, translating it with (-regionAnchorX%, -regionAnchorY%)
>> > ends up positioning the cue differently.
>>
>> I don't follow this problem either. Anonymous regions cover the video
>> viewport and are anchored to the bottom left corner. What is the
>> "larger size" you are referring to? Can you maybe explain via an
>> example?
>
> Example: Let's suppose there's a cue with only 1 line, and a region
> that contains is anchored at regionAnchor (50%, 100%) - so
> middle-bottom, and viewportAnchor (50%, 50%) so middle point of the
> video.
>
> This implies that the bottom of the region is over the middle point of
> the video. If the region has height 3, than we have two empty lines at
> the bottom, and our cue line at the top. If the region would have
> height 1, then the cue line will be at the bottom of the region, and
> directly on top of the video center. This is why the region size
> matters.

I think this is more a matter of where a cue is rendered by default
within a region. The spec for non-region cues puts cues by default at
the bottom of the video viewport. I think in future it should put it
by default at the bottom of the region. Thus, in what you are
describing, the one line cue will end up in line 3 and not in line 1.
That is: unless the region is a scrolling region, in which case the
region is resized to 1 line.

> This approach has the following advantages:
> *) We avoid weird absolute-positioned cues in absolute-positioned regions.

What's the problem here?

> *) We support auto sized regions in one or both dimensions.

I see a need for this only for scrollable regions. We could introduce
vertical scrolling, too, for this for vertical cues, but I see that as
an independent issue.

I'll draw up some examples of how I think it could work without
resizing regions. That will also avoid re-drawing regions every time
another cue is rendered into the region.

Cheers,
Silvia.

Received on Tuesday, 18 February 2014 06:18:14 UTC