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

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.

Christian


On Mon, May 12, 2014 at 8:52 AM, Philip Jägenstedt <philipj@opera.com>wrote:

> On Mon, May 12, 2014 at 2:25 PM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
> > On Mon, May 12, 2014 at 10:16 PM, Philip Jägenstedt <philipj@opera.com>
> wrote:
> >> On Mon, May 12, 2014 at 10:24 AM, Silvia Pfeiffer
> >> <silviapfeiffer1@gmail.com> wrote:
> >>> On Mon, May 12, 2014 at 6:12 PM, Philip Jägenstedt <philipj@opera.com>
> wrote:
> >>>> Using the cue box as the background box was what I did in
> >>>> http://people.opera.com/philipj/2014/03/vttscroll/background.html
> >>>
> >>> There's a difference: you're putting a background on the individual
> >>> cues while the background on the region is putting a background on the
> >>> group of cues in one go. There is no chance of a gap appearing between
> >>> the cues because of this.
> >>
> >> Yes, that is true. (Trying to emulate a grid-based format should have
> >> similar problems.)
> >>
> >>>> However, I've realized that this creates a bit of a tension between
> >>>> two goals: in order to "look nice" the background should not be much
> >>>> bigger than the cue text, but to give the cue size to grow when the
> >>>> font size changes, it should be as big as possible.
> >>>>
> >>>> This would likely cause authors to create boxes that are too small,
> >>>> causing unnecessary line wrapping when the font size increases. Note
> >>>> that using a font-relative unit like em doesn't eliminate the problem,
> >>>> as illustrated here:
> >>>> http://jsfiddle.net/zLB3N/
> >>>>
> >>>> If the use case was to provide a common background for a number of
> >>>> lines (possibly from different cues) simply taking the bounding box of
> >>>> those lines and adding some padding would be enough.
> >>>
> >>> That's what the region is for.
> >>
> >> Doesn't regions have exactly the problem I describe? Not that I have a
> >> solution, I don't know how this could be made reliably when fonts and
> >> their sizes is under user control...
> >
> > Yes, the bounding box around a couple of lines/captions is always big
> > and has some whitespace in it. That's, however, not a problem, but
> > rather expected, IIUC.
>
> Leaving room for doubling the font size requires that the area of the
> background box is quadrupled. Is this really what is done in practice,
> or does it simply break down when you try to increase the font size
> more than a few percent?
>
> > Also, Christian just made a very good point about why such a bounding
> > box is important: it allows users to override the background on the
> > group of captions with a single setting (
> > ::cue-region(){background-color: red;} ).
>
> If it's important that users be able to override this background, then
> we need to figure out what to do when regions are not used. As I asked
> in another mail, is it possible to *not* use windows in 708?
>
> >>>> However, if the background needs to be unchanging over time
> >>>
> >>> What do you mean by "unchanging"?
> >>
> >> I mean a background which isn't just the bounding box of the cues
> >> current showing, but those that will be shown. The author cannot know
> >> what that box is, and calculating it at runtime would require
> >> rendering all cues once and assuming scripts won't change them...
> >
> > I don't think I've seen that requirement nor did I read that out of
> > CEA708 nor the FCC.
>
> See Nigel's mail. I have no idea if it's important to end users or not.
>
> Philip
>



-- 
Christian Vogler, PhD
Director, Technology Access Program
Department of Communication Studies
SLCC 1116
Gallaudet University
http://tap.gallaudet.edu/
VP: 202-250-2795