Re: Rollup captions: an analysis and suggestion

On Wed, Apr 11, 2012 at 2:06 PM, Glenn Maynard <glenn@zewt.org> wrote:
> I disagree with a lot of the use cases in there, but I think it's mostly
> been covered in past discussions, so I won't rehash those discussions.
>
> This bit confuses me, though:
>
>> A second use case for roll-up captions on the Web are captions that are
>> created using automated speech recognition. It's important that users can
>> distinguish easily whether captions are created with lots of care and are
>> supposed to be of high quality, or are
>
> This sounds like you're saying: "Roll-up captions are usually poorly edited
> and lower quality than pop-on captions.  It's important that users can tell
> that captions based on speech recognition are supposed to be poorly-edited,
> and they can do so by noticing that it's a roll-up caption, because roll-up
> captions tend to be of lower quality than pop-on captions."  I doubt that's
> really what you meant, so can you clarify?

Actually, that's almost exactly what I mean. As you can tell from
Shane's reply to my email he is under exactly that impression: rollup
makes people expect poor quality live captions or worse expects that
they are created by speech recognition. So, if that is already the
case, we can just build on it.


> I don't see the need for something like "renderingHint=rollup"; that needs
> use cases.

If the use cases that are listed are not sufficient for you, what will be?


> If roll-ups are going to be supported, I agree that it should be based on
> semantic data, such as which side of the screen/captioning group the caption
> is in.  The one closest to the suggestion I made is:
>
> WEBVTT
>
> 00:00:05:94 00:00:10:61 rollup:box1
> WHEN I GET A SICK BIRD,
>
> except for two things:
>
> 1: "box1" would be which side of the screen it's on (eg. top, bottom, left
> or right).

Why the restriction on rendering locations? As long as a caption
clashes with another already rendered on screen, we have to do
something. It really doesn't matter where that existing cue is
positioned on screen.


> 2: This isn't inherently roll-up-specific information; it's just grouping
> captions by visual area.  So, the keyword "rollup" should be something like
> "grouping".

Yes, the grouping aspect is the one that I tried to address with
grouping cues together through a class-like construct on their
identifier line.


> On Tue, Apr 10, 2012 at 7:28 AM, Silvia
> Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>
>> Are you suggesting that we should completely kill rollup as a feature
>> on the Internet? Further, are you suggesting that the FCC got it wrong
>> when they are requiring captions on the Web to be displayed exactly as
>> they have been displayed on TV,
>
>
> If that's what they said, it'd obviously be wrong.
>
> That's not what you said in your previous summary, though; your quote was
> 'provide captions of at least the same quality (in terms of "completeness,
> placement, accuracy, and timing")', which is a completely different message
> than "displayed exactly as on TV".  To avoid repetition, I'll just link a
> previous response about this which I agree with:
> http://lists.w3.org/Archives/Public/public-texttracks/2011Dec/0033.html ("Or
> maybe..." and "changing them from ...").

Placement and timing are what makes the rollup feature. If we ignore
rollup, we ignore these two dimensions and thus clash.

Silvia.

Received on Wednesday, 11 April 2012 05:06:50 UTC