Re: Absolute region positioning (was Re: Alternative approach to scrolling, with demos)

On Mon, May 5, 2014 at 2:50 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Mon, May 5, 2014 at 10:16 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>> On Mon, May 5, 2014 at 1:38 PM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>> On Mon, May 5, 2014 at 9:17 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>>>> On Tue, Apr 8, 2014 at 9:21 AM, Silvia Pfeiffer
>>>> <silviapfeiffer1@gmail.com> wrote:
>>>>> On Sun, Mar 30, 2014 at 4:41 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>>>>>>
>>>>>> == Absolute positioning and scrolling ==
>>>>>>
>>>>>> Demo: http://people.opera.com/philipj/2014/03/vttscroll/absolute.html
>>>>>>
>>>>>> Finally, an idea for how scrolling might work with absolutely
>>>>>> positioned cues. You simply position all the cues at the point where
>>>>>> scrolling should begin, and they'll scroll up from there.
>>>>>
>>>>> I've attached a vtt file for you with two "regions". The cues should
>>>>> each get limited to their "region".
>>>>>
>>>>> You can see for yourself how this breaks down with 2 regions present.
>>>>>
>>>>> I think it's quite clear that the concept of cue groups codified in
>>>>> regions is a more appropriate approach than building ad-hoc groups of
>>>>> captions by trying to group them based on them overlapping each other.
>>>>
>>>> For simplicity in the demo, I scrolled all the cues by the same amount
>>>> without checking if they actually overlap, which of course falls apart
>>>> when you have two groups of cues. If implemented properly, I don't see
>>>> that cues scrolling in different parts of the video would be a
>>>> problem. If scrolling implemented as overlap avoidance, the situation
>>>> has to be handled anyway.
>>>>
>>>> How are overlapping regions handled? Not at all AFAICT, some text
>>>> would simply be obscured.
>>>
>>> Indeed, we're not currently handling overlapping regions. I don't
>>> think we need to either, because not even CEA708 has an overlap
>>> avoidance algorithm. Instead, it specifies z-index (called "priority")
>>> so the author can determine which cue sits in front if overlap
>>> happens.
>>>
>>> I don't mind that actually, because it provides an alternative to the
>>> default cues which do overlap avoidance.
>>
>> I do mind. Why should we accept this deficiency just because CEA708
>> has it? Unless the video is entirely filled with text (unlikely) there
>> will be a way to show all of it without overlap, so why not deal with
>> the situation since WebVTT already has overlap avoidance?
>
> I don't see it as a deficiency. I actually think it's a strength
> knowing exactly where ones content ends up being rendered on screen
> without the browser interfering with positioning. What if I'd like to
> author my cues such that they overlap? Maybe it's because it's the
> lesser evil than overlapping other content on the screen? I really
> think we may be over engineering the overlap avoidance issues if we're
> trying to avoid overlap at all cost.

If we tried to add overlap avoidance to the CEA708 model at any cost I
would probably agree, that could turn into a mashup of two models that
doesn't make sense. However, the approach I was taking with my demo
was trying to solve the use cases by using the existing overlap
avoidance. Matching CEA708 semantics wasn't the goal, and I guess
that's the crux of the issue...

> NB: Incidentally, following CEA708 rendering as exactly as possible is
> inline with what the US law prescribes, namely identical rendering
> between TV and Online. Though, to be honest, there is a line of "rough
> identity" that I am prepared to accept and I would call overlap
> avoidance an optimisation of sorts, which is why I'm not really
> accepting this as an argument.

What will we do if the European Union introduces similar legislation
and broadcasters say that their existing content is EBU-TT, a TTML
flavor? Should the TTML model be added to WebVTT?

In Sweden, live news programs use the teletext system for captioning,
and erasures to fix typos are rather common. This feature is also
supported by 608, described in the section "Backing Up and Making
Corrections" in "The Closed Captioning Handbook". Should it be added
to WebVTT?

I guess I just don't understand what the criteria for adding new
features to WebVTT should be...

Philip

Received on Monday, 5 May 2014 14:15:02 UTC