Re: Support for advanced caption features (inc rollup)

Thanks for taking this on board!

Some feedback inline.

On Wed, Dec 12, 2012 at 9:13 AM, Ian Hickson <ian@hixie.ch> wrote:

>
> > (2) Character color. All apparatus shall implement captioning such that
> > characters may be displayed in the 64 colors defined in CEA-708 and such
> > that users are provided with the ability to override the authored color
> > for characters and select from a palette of at least 8 colors including:
> > white, black, red, green, blue, yellow, magenta, and cyan.
>
> This we support via CSS and CSS user style sheets (the latter of which can
> be exposed as UI). It does mean that FCC-compliant WebVTT browser
> implementations will have to support CSS.
>

The alternative is what I suggested in the 608/708 to WebVTT mapping spec:
http://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html

We simply define a default CSS user style sheet that browsers use and the
class names it defines can be used by other devices to interpret the colors
etc.

In either case, the point is that this is supported, to which I agree.


> (5) Fonts. All apparatus shall implement captioning such that fonts are
> > available to implement the eight fonts required by CEA-708 and §
> > 79.102(k). Users must be provided with the ability to assign the fonts
> > included on their apparatus as the default font for each of the eight
> > styles contained in § 79.102(k).
>
> Assuming implementations ship with suitable fonts, we support this to the
> letter of the text. However, CSS does not support a distinction between
> "monospace serif" and "monospace sans-serif", and "casual" has no good
> generic mapping either, so we don't support this in a useful way (you have
> to explicitly list font names). That's probably ok though.
>

Agreed - it's good enough. My proposed spec proposes some adequate font
families:
http://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html#browsers
I've picked them as close to the CEA-708 spec proposed fonts as possible.


> (7) Character edge attributes. All apparatus shall implement captioning
> > such that character edge attributes may be displayed and users are
> > provided the ability to select character edge attributes including: no
> > edge attribute, raised edges, depressed edges, uniform edges, and drop
> > shadowed edges..
>
> This we don't do, and CSS doesn't either. See below.
>
[.. later ...]

> Actually, I think you can probably sufficiently fake raised and depressed
> edges using shadows [1], and uniform edges and drop shadowed edges are in
> CSS3 Text, so this one is probably covered sufficiently.
>
> [1] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2010
>

Excellent! I have been wondering about how to do these. My suggestions were
at:
http://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html#caption-text-and-region-settings-in-cea-708
but your solution is much better.

I've registered https://www.w3.org/Bugs/Public/show_bug.cgi?id=20352 on the
608/708 spec. There is a new component for that spec now.


> (8) Caption window color. All apparatus shall implement captioning such
> > that the caption window color may be displayed in the 64 colors defined
> > in CEA-708 and such that users are provided with the ability to override
> > the authored color for the caption window and select from a palette of
> > at least 8 colors including: white, black, red, green, blue, yellow,
> > magenta, and cyan. All apparatus shall implement captioning such that
> > users are provided with the ability to vary the opacity of the caption
> > window and select between opaque, semi-transparent, and transparent
> > background opacities.
>
> Not sure how this varies from 6, but as far as I can tell, this is handled
> by CSS, so as above.
>

Not quite. There is a distinction being made here between captions and
caption windows. The windows are the rendering region into which caption
text is rendered. There can be multiple captions (cues) in one window. The
area of the window can be bigger than just the bounding box of the caption
text, but it is at minimum as big as the bounding box of all the contained
cues. There are two different places where backgrounds can be changed: just
on the cue or or on the window. I've made an example of that in
http://html5videoguide.net/test/WebVTT-with-regions/cpc_video.html from
about 50 sec on.


> (9) Language. All apparatus must implement the ability to select between
> > caption tracks in additional languages when such tracks are present and
> > provide the ability for the user to select simplified or reduced
> > captions when such captions are available and identify such a caption
> > track as “easy reader.”
>
> We don't do the easy reader part. See below.
>

Providing an "easy reader" is up to the publisher. An "easy reader" is
simplified text - usually not a verbatim transcription of what is being
said, but a meaningful summary with less words such that people with
reading disabilities can still follow the content of the video. This does
not require any additional solutions, but is satisfied with the
human-readable @label.


Ok so that leaves three use cases we don't support:
>
>  Allow software developers based in the US who believe they will be
>  covered by the CFR 79.103 rules to support captions while only
>  implementing WebVTT, by allowing caption text to be displayed within
>  one or separate caption windows in a mode where text scrolls up as
>  new text appears.
>

Yes, roll-up caption support.


  Allow software developers based in the US who believe they will be
>  covered by the CFR 79.103 rules to support captions while only
>  implementing WebVTT, by allowing character edge attributes to be
>  displayed, including: no edge attribute, raised edges, depressed
>  edges, uniform edges, and drop shadowed edges.
>

I think that's resolved with CSS as discussed.


  Allow software developers based in the US who believe they will be
>  covered by the CFR 79.103 rules to support captions while only
>  implementing WebVTT, by providing the ability for the user to select
>  simplified or reduced captions when such captions are available and
>  identify such a caption track as 'easy reader'.
>

That's resolved with @label.


You are, however, missing the distinction between "window" and "caption"
background.

Question: Why have the people who keep asking for the first on the basis
> that it's legally required not even mentioned the other two?
>

They are mentioned in the conversion spec and I thought I had a good enough
solution. Though your CSS foo is better and I'm glad for your input!

HTH.

Silvia.