Re: Unifying the rendering approach

Thanks for the quick answer.

On Mon, Mar 3, 2014 at 8:41 PM, Victor Carbune <victor.carbune@gmail.com> wrote:
>>
>>>>> 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?
>
> Yes. I am (maybe mistakenly) using the term "absolute" positioning
> only when both horizontal and vertical attribute are percentages
> (non-snap-to-lines case).

Ah right.


> I'm supporting line-snapping within regions (mentioned this from the
> first email on this thread [1])
> http://lists.w3.org/Archives/Public/public-texttracks/2014Jan/0043.html

I didn't remember this. That's interesting and could work, I guess.


>>> 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 don't want percentage-positioned cues within regions. They don't make sense.
>
> When we have a percentage-positioned cues, I just want to wrap it in
> an anonymous region and set the positioning attributes of the regions
> such as we have backward compatibility for non-snap-to-lines case.

Yes, I think I now follow and it makes sense to me.


>>> 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'll just rewrite:
> *) An anonymous region with video width & height for all the cues that
> have snap-to-lines=true and no region specifier.
> *) One anonymous region with auto width & height wrapping each
> snap-to-lines=false cue that has no region specifier

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?

> *) User-defined regions & cues with region identifier and snap-to-lines=true.
>
> So there's no cue with snap-to-lines=false that ends up in a region.

A named region, I assume. Since the second case has
snap-to-lines=false cues in an anonymous region.

Cheers,
Silvia.

Received on Monday, 3 March 2014 11:11:56 UTC