Re: Scrolling as overlap avoidance (Re: Alternative approach to scrolling, with demos)

On Tue, Apr 8, 2014 at 8:57 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> Hi Philip,
>
> I'm pulling out each of the issues in your "alternative approach"
> thread into a separate thread, because I'd like to address the issues
> individually.
>
> On Sun, Mar 30, 2014 at 4:41 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>>
>> == Scrolling as an overlap avoidance ==
>>
>> Demo: http://people.opera.com/philipj/2014/03/vttscroll/simple.html
>>
>> When a cue overlaps, it's moved down until it doesn't overlap, then
>> all the cues are moved up. Scrolling is implemented by moving cues,
>> not their container.
>>
>> This approach makes things much more similar to the regular overlap
>> avoidance. You will end up with cues occupying approximately the same
>> space in both modes, the only difference is the order.
>
> The VTT file that you associated with this approach is as follows:
>
> ==
> WEBVTT
>
> 00:00:00.181 --> 00:00:07.120 position:15% size:70%
> NOW THE ROLL-UP MODE.
>
> 00:00:02.884 --> 00:00:07.622 position:15% size:70%
> THIS MODE IS NORMALLY USED
>
> 00:00:04.018 --> 00:00:08.789 position:15% size:70%
> FOR TV NEWS PROGRAMS.
>
> 00:00:06.187 --> 00:00:10.124 position:15% size:70%
> CAPTION LINES ROLL UP
>
> 00:00:07.120 --> 00:00:10.124 position:15% size:70%
> FROM THE SCREEN BOTTOM
>
> 00:00:07.622 --> 00:00:10.124 position:15% size:70%
> ONE LINE AT A TIME.
>
> ==
>
> Your approach to this is to make a cue that would be rendered into the
> place of an existing cue move that cue out of the way. That was my
> original suggestion to Hixie on how to do this, too.
>
> However, it was argued at the time - and I think there is merit - that:
> * rendered cues should move as little as necessary, preferably not at all
> * only rollup captions move existing rendered cues out of the way -
> Karaoke captions don't, but instead find the nearest empty space to
> render themselves into
>
> Thus, it was determined that cues marked up as above will not move,
> but every newly added cue will be added into a free space nearest to
> the line that it is authored to be rendered into.
>
> Since this has been the case for all of WebVTT since its inception, we
> should not change this behaviour now.

Of course we shouldn't change the default behavior, my point is just
that overlap avoidance and scrolling are very similar problems, and
could be implemented using largely the same code paths. Some extra bit
of syntax would be needed to actually switch between the modes, but
that's trivial compared to actually implementing the rendering.

> Looking at the full demo that you are showing there, this syntax is,
> however, not required. It would work just as well with the existing
> region syntax.
>
> The existing region syntax together with the region box satisfies the
> following use cases that CEA708 has:
> (1) there is a maximum number of rollup lines (assume that all your
> cues end at 10.124 - how do you make sure there are never more than 4
> lines of scrolling text on screen?)

Clipping was another demo:
http://people.opera.com/philipj/2014/03/vttscroll/clip.html

> (2) the background color on the width and height of the rollup area
> needs to be changeable

Why? As I noted in the "background box tweaking" thread that's still
possible with the sum of my suggestions, but I don't understand what
the use case is.

> (3) font size changes on the region need to make the region go bigger
> centered out from the anchor point

That's not handled by the current spec. We've talked about using
font-relative units but that hasn't happened. I'd love to understand
the use case for this though. Do you have an example video frame where
scaling around an anchor point is necessary as opposed to mode of
scaling that happens with classical WebVTT?

> (4) move all the cues in the region as a group to another location

This is also not handled by the current spec. I don't think it makes
sense either, why not just end the cues and repeat them in a new
position?

> (1) I know we could also put logic in to count the lines and not make
> more of them appear than 4.

Right. That would also work for variable-height lines, which you
brought up in another thread.

> (2) I can see your backgroundTweak which is faking the region
> background on the individual divs of each cue to get a combined
> "region background" (did you notice that Chrome has a weird bug with a
> gap between the lines?).
> (3+4) We can also change the position of every individual cue by hand
> when we change the fontsize or when we move the "region" to another
> location.
>
> But really: all of these are hacks to avoid introducing another box
> that would take care of all this functionality more easily.

I agree that the background tweak is a hack. If two layers of
backgrounds were very important (are they? why?) I'd probably suggest
something that wraps a group of cues and provides a background for
them without influencing their position.

Philip

Received on Monday, 5 May 2014 12:00:53 UTC