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

Thanks. It would be good to get definite answers on these things, because I
suspect that this ultimately will determine what consumers think about the
impact of the rendering simplification proposals.

Christian


On Thu, May 8, 2014 at 7:47 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

>
> On 9 May 2014 09:08, "Christian Vogler" <christian.vogler@gallaudet.edu>
> wrote:
> >
> > Hmm, ok, I see a potential problem with the use case under point #10 in
> http://www.dcmp.org/captioningkey/text.html - for the purpose of showing
> as much image as possible, you want the background width to be no larger
> than the actual text width + padding. That is what is shown in this image
> (and also in #9). But if you scale the font, you eventually need to wrap
> around when the left/right cues grow too close to each other.
> >
> > That leaves two options:
> >
> > 1. explicitly specify cue width, and have the background extend all the
> way across the width. That covers more image than you should, and also
> doesn't look very pleasing aesthetically if you have a large
> black/translucent bar with no text in it.
> >
> > 2. force some kind of maximum width, after which you wrap around - but
> the cue width can be smaller than the max depending on font metrics. And
> the background extends only across the real cue width.
> >
> > I'm not yet fully up to speed - does WebVTT cover #2? Or are there
> alternatives that could give the desired behavior?
>
> Yes, vtt does #2.
>
> These are two cues: one under each speaker. Since you don't want them to
> run into each other, you specify the size (I.e. width) of the cue that they
> go into. That provides the display that #10 shows. Then you increase the
> font size. When the text gets bigger than the cue width, it wraps.
>
> > Christian
> >
> >
> > On Thu, May 8, 2014 at 6:58 PM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com> wrote:
> >>
> >> On Fri, May 9, 2014 at 3:25 AM, Christian Vogler
> >> <christian.vogler@gallaudet.edu> wrote:
> >> > Just checking here, what does this mean for text background? Say, you
> have
> >> > white text on black background - will the black extend only to the
> width of
> >> > the actual text plus padding?
> >>
> >> In the non-region case:
> >>
> >> If you explicitly specify the width of your cue and the text is much
> >> smaller than the width, the background will still cover the fully
> >> specified width.
>
> Actually, I might have been wrong on this. I'd have to check (on a train
> now). The cue box has the size as width, but I think background may still
> only be rendered on the actual text. Let me get back to you on this.
>
> Silvia.
>
> >> If you do not specify a width, then the cue with is determined
> >> automatically based on the text width and the background will only be
> >> on the width of the text.
> >>
> >>
> >> In the region case:
> >>
> >> The non-region case background on ::cue still applies.
> >>
> >> However, there is now also a region box whose size is explicitly
> >> determined (width/height). You can set a background color on that box
> >> with ::cue-region . That background covers the full width of the
> >> region no matter the width of the cues or cue text inside.
> >> As for the height: in the case of scrolling regions, the height is
> >> dynamic and depends on the number of lines that are being rendered.
> >> For non-scrolling regions the height is fixed, so a non-scrolling
> >> region without cues inside with a red background will be a red
> >> rectangle on screen.
> >>
> >>
> >> Hope that clarifies it?
> >>
> >> Silvia.
> >
> >
> >
> >
> > --
> > Christian Vogler, PhD
> > Director, Technology Access Program
> > Department of Communication Studies
> > SLCC 1116
> > Gallaudet University
> > http://tap.gallaudet.edu/
> > VP: 202-250-2795
>



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