Re: Unifying the rendering approach

On Tue, Feb 18, 2014 at 7:17 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> 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.

I was just explaining here why the region size matters - gets
positioned differently; where the cue ends up in the region by default
(first or last line) is just a detail.

>> This approach has the following advantages:
>> *) We avoid weird absolute-positioned cues in absolute-positioned regions.
>
> What's the problem here?

I don't see any use case for this, thus why support it? It just looks
like it enhances 'chaos' in a region. Just snapping lines within
regions covers all the use-cases, IMO.

Having absolute-positioned cues makes me conceptually transform the
cue text into a box, and position it within another box, which is the
region. I'd like to think that the only boxes we will have in this
spec will be the regions. The cues will just be some wrapped text
lines, automatic or due to author line breaks (should be treated the
same).

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

Why do scrolling regions need auto-sizing? You need a fixed height,
otherwise the region grows indefinitely as you add cues and no
scrolling animation happens, as no cue will ever be outside the
region.

I see auto-sizing as a mean to get rid of non-snap-to-lines cues and
render them directly using regions.

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

I read your following examples, and the main disagreement point is
along the same lines: non-snap-to-lines cues in regions. If we want to
unify, supporting only snap-to-lines cues within the region is the
first step, mapping non-snap-to-lines-cues to regions auto-sized to
match cue text is the second.

One other major advantage of not supporting non-snap-to-lines cues
within regions is that you will avoid overlap completely (since text
can only snap in lines).

The last aspect is the anonymous region of the size of the video,
while I'm not entirely happy about it, I already mentioned that I like
it because it keeps the simplicity of VTT - you can have a cue with
text and line index and you're done.

(I know the thread has already gone further into details of applying
cue setting within regions, but I think we should step back for now
and agree on positioning elements; a different thread for cue settings
might be a good idea).

Victor

Received on Monday, 24 February 2014 08:07:37 UTC