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

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?

Christian


On Thu, May 8, 2014 at 11:03 AM, Philip Jägenstedt <philipj@opera.com>wrote:

> The auto width was discussed for regions, for a single cue I think one
> should simply make the cue box as big as it can be. That is in fact
> the default size, 100%.
>
> Philip
>
> On Thu, May 8, 2014 at 4:28 PM, Loretta Guarino Reid
> <lorettaguarino@google.com> wrote:
> > Yes, an option for "auto" width would allow this. Philip and Silvia, is
> that
> > still on the table?
> >
> >
> > On Thu, May 8, 2014 at 7:19 AM, Christian Vogler
> > <christian.vogler@gallaudet.edu> wrote:
> >>
> >> For this kind of situation, line wrapping should be considered only as a
> >> method of last resort. If possible, growing the cue to the left, right,
> or
> >> both, would in most cases be preferable. Especially if a line wrap
> breaks up
> >> a single word.
> >>
> >> Christian
> >>
> >> Sent from my mobile phone.  Please excuse any touchscreen-induced
> >> weirdness.
> >>
> >> On May 8, 2014 10:09 AM, "Philip Jägenstedt" <philipj@opera.com> wrote:
> >>>
> >>> Thanks for digging that up, Loretta!
> >>>
> >>> In this example, there are single cues which are positioned, not
> >>> groups of cues, so I don't think regions should be required to achieve
> >>> the same result.
> >>>
> >>> With pre-regions WebVTT this could be reproduced by using the align
> >>> setting and a suitably positioned cue box, it seems.
> >>>
> >>> Note that lineAlign:bottom only controls the alignment of the first
> >>> line, so if a cue wraps then lineAlign can't be used to provide an
> >>> anchor point for the cue as a whole, in particular you couldn't use it
> >>> to avoid overlapping text just below the cue.
> >>>
> >>> I'm guessing that for speaking identification you'll place the cue
> >>> either above or below the speaker. Would a way to control the
> >>> direction in which the cue grows when the font size increases or lines
> >>> wraps be sufficient?
> >>>
> >>> Philip
> >>>
> >>> On Thu, May 8, 2014 at 3:24 PM, Loretta Guarino Reid
> >>> <lorettaguarino@google.com> wrote:
> >>> > (Still trying to find non-pay examples of interesting placement...)
> >>> >
> >>> > Here is one, although the visual motivation for this particular
> >>> > placement
> >>> > isn't clear:
> >>> >
> >>> > https://www.youtube.com/watch?v=NR1PO6zH60c#t=1m53s
> >>> >
> >>> > The positioned captions occur at 2:09
> >>> >
> >>> >
> >>> > On Thu, May 8, 2014 at 6:18 AM, Philip Jägenstedt <philipj@opera.com
> >
> >>> > wrote:
> >>> >>
> >>> >> [I accidentally sent this reply off-list two days ago.]
> >>> >>
> >>> >> In the CPC demo, simple left and right alignment is used to follow
> the
> >>> >> speaker:
> >>> >> http://www.youtube.com/watch?v=BbqPe-IceP4
> >>> >>
> >>> >> Do you have an example where something more fancy than this is used?
> >>> >> Note that just by using the position, size and align setting you can
> >>> >> do fancier things, but an example would help determine if that's
> >>> >> enough or not.
> >>> >>
> >>> >> On Mon, May 5, 2014 at 6:31 PM, Christian Vogler
> >>> >> <christian.vogler@gallaudet.edu> wrote:
> >>> >> > To me, positioning for speaker identification makes the most sense
> >>> >> > in
> >>> >> > terms
> >>> >> > of the anchor point - this point is the target for each speaker.
> >>> >> >
> >>> >> > Christian
> >>> >> >
> >>> >> >
> >>> >> > On Mon, May 5, 2014 at 12:27 PM, David Singer <singer@apple.com>
> >>> >> > wrote:
> >>> >> >>
> >>> >> >>
> >>> >> >> On May 5, 2014, at 5:00 , Philip Jägenstedt <philipj@opera.com>
> >>> >> >> wrote:
> >>> >> >>
> >>> >> >> >> (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.
> >>> >> >>
> >>> >> >> >> (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?
> >>> >> >> >
> >>> >> >>
> >>> >> >> I agree for these that if you want something ‘similar’ to appear
> as
> >>> >> >> what’s
> >>> >> >> already there, the clean thing to do is to re-draw it.  Same
> >>> >> >> content
> >>> >> >> but in
> >>> >> >> a different region (with different position or colors), and so
> on.
> >>> >> >>
> >>> >> >> >
> >>> >> >> >> (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?
> >>> >> >> >
> >>> >> >> >
> >>> >> >>
> >>> >> >> I also am curious
> >>> >> >>
> >>> >> >> David Singer
> >>> >> >> Manager, Software Standards, Apple Inc.
> >>> >> >>
> >>> >> >>
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > --
> >>> >> > 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

Received on Thursday, 8 May 2014 17:26:04 UTC