Re: Unifying the rendering approach

On Mon, Feb 24, 2014 at 7:06 PM, Victor Carbune
<victor.carbune@gmail.com> wrote:
> 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.

I think we mean the same thing. I explained to Philip how to do the
scrolling and that also included changing the *rendered* region height
by adapting the "top" attribute, though I am keeping min-height to 0
and max-height to the number of lines (converted to px). Thus, I'm
leaving the height adaptation to CSS.


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

OK.... But you can snap a line in a region. E.g. in a 3-line region
you can position it in line 1, 2, or 3, right? Then you still have to
position these lines absolutely inside the region, don't you?


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

Right, I see why you want to put anonymous regions around every single
non-region cue. You just want positioned boxes that are either
positioned to contain a single cue, or positioned to contain scrolling
cues or automatically positioned cues. You don't want to extend
regions to contain explicit line positioning.


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

Regions as they are currently specified don't have any line settings,
so I assume you want to leave it that way? If so, we indeed can't
position non-region cues into a single anonymous region, since within
regions we don't do line positioning.


> mapping non-snap-to-lines-cues to regions auto-sized to
> match cue text is the second.

I think I understand where you're coming from with this now.


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

Right, that's why regions are currently specified not to have line settings.

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

Now I am confused. Where do we now have anonymous regions of the size
of the video in your model?

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

I don't want to change anything about how regions are specified in the
current spec other than the rendering section. I hope we're still in
agreement on that?

Silvia.

Received on Monday, 3 March 2014 04:48:31 UTC