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

Overall I see a split use case here. Simple interjections would be better
off with auto width as long as they stay centered where they are. Longer
aligned phrases as in point 10 in the link below need a maximum width
beyond which they can't grow and need to wrap. In the latter case vertical
alignment needs to apply to all lines.

http://www.dcmp.org/captioningkey/text.html

Christian

Sent from my mobile phone.  Please excuse any touchscreen-induced weirdness.
On May 8, 2014 10:28 AM, "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
>>> >>
>>> >
>>>
>>
>