Re: What is the use case for two levels of background colors?

On Mon, May 12, 2014 at 2:57 PM, Christian Vogler
<christian.vogler@gallaudet.edu> wrote:
> To me, it boils down to groups of cues. If we don't need to support groups
> of cues, then I don't see the need for regions, either, because then the
> default behavior of the background box should be to encompass the bounding
> rectangle of the text + padding.

There are (at least) two ways of thinking about this. One is to let a
region have a position, width and height of its own and lay out the
cues in that region. When the cues can't fit, something happens,
hopefully something other than simply clipping.

The other way is to let the region have no size of its own, but simply
be the bounding box, growing and shrinking as needed. That's pretty
much what I did in this demo:
http://people.opera.com/philipj/2014/03/vttscroll/simple.html

That didn't look great, so some extra magic clipping was needed:
http://people.opera.com/philipj/2014/03/vttscroll/clip.html

That clipping makes it possible that some cue text will become
unreadable, just like with a fixed-size region. It could be made more
clever, I guess.

> If you look at my earlier email, that is why I asked about the decision to
> support roll-up via groups of cues and overlap avoidance. As far as I am
> concerned, that looks like over-engineering to me, and if there is a better
> way to do it that avoids all these complications, we should consider it.

If you're referring to the demos I posted, those are only ideas so
far, the spec has not been changed.

Using overlap avoidance as a means to implement roll-up is really
aimed at reusing more of the old rendering code, and it isn't really
related to the background box that I started this thread about.

> Specifying a cue box AND a region for a pop-on caption makes no sense to me,
> and I don't think any casual caption author would understand it. So, we need
> to make sure that the desired behavior can happen without explicitly
> specifying a region. And if we do that, then again: what is the use case for
> regions, other than dealing with a group of cues -- which brings us back to
> my question above.

Well, if it's acceptable that the background box changes in size as
cues come and go then the bounding-box way would mostly work. Roll-up
complicates things, but given enough effort perhaps an automatic
clipping algorithm could be written as well. That's vaporware for now,
though.

On Mon, May 12, 2014 at 3:02 PM, Christian Vogler
<christian.vogler@gallaudet.edu> wrote:
> Sorry, missed the first paragraph. Yes, quadrupling the box is what happens
> when you double the font size. Again, iOS 7 is a good example of how this
> could be done in practice.

I think that's just using the bounding box of the cue(s), which would
work fine. Having a fixed-size region which you quadruple just to be
safe would leave lots of unused area in the common case, and I wonder
if this is actually how any real system works.

Philip

Received on Monday, 12 May 2014 14:35:37 UTC