This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
By far the most common use case for paint-on captions was to resume captioning immediately after an interruption by e.g. a commercial, rather than waiting for the captioning buffer to fill, which took a couple of seconds on analog TVs. It's neither necessary nor desirable to convert such cases 1:1 - as long as quality is improved by doing something different and straightforward, that is exactly what we should do. I suggest making a note here: http://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html#paint-on-captions stating the by default, the strong preference is just to generate a simple pop-on cue without the time codes within the cues. There *are* some relatively rare cases where paint-on is a stylistic choice, and wherever these need to be preserved, we can use the time codes, as suggested by the document. Related question: are such time codes within cues expected to play nice with screen readers, such that the cue is read back in its entirety, rather than character by character?
Just to expand on the latter point of a stylistic choice, where paint-on needs to be preserved, is something like the following below: 00:00:00.000 --> 00:00:15.000 [Paces and mumbles <00:00:05.000>.<00:00:06.000>.<00:00:07.000>.] where the timing of the dots actually expresses the long think of the on-screen character.
Will add the suggested improvement. (In reply to comment #0) > Related question: are such time codes within cues expected to play nice with > screen readers, such that the cue is read back in its entirety, rather than > character by character? Screen readers should primarily read out audio descriptions and not captions. But where you want to give it to screenreaders, they will be given the cue in pieces as they get visible. Is that a problem?
Added a note to recommend using pop-on captions when transcoding paint-on CEA608/708 captions. https://dvcs.w3.org/hg/text-tracks/rev/514975d592d5
Regarding my note about screen readers: They also provide the interface to refreshable Braille displays and other accessibility tools for people who are deaf/hard of hearing, and also have a visual impairment. This community also needs access to videos, and one thing to think about is how the reading of captions will interact with them. Maybe this belongs in a separate discussion of its own, not specific to paint-on captions? Paint-on captions just constitute the situation where I see the most potential for problems.
(In reply to comment #4) > Regarding my note about screen readers: They also provide the interface to > refreshable Braille displays and other accessibility tools for people who > are deaf/hard of hearing, and also have a visual impairment. This community > also needs access to videos, and one thing to think about is how the reading > of captions will interact with them. Maybe this belongs in a separate > discussion of its own, not specific to paint-on captions? Paint-on captions > just constitute the situation where I see the most potential for problems. Captions are dealt with as "aria-live" content. I don't really see a cause for problems there. The text will be read out by the screen reader or displayed in Braille successively at the timing given through the time stamps in sync with the video. I don't really see a technical problem there. For Braille it may need to be necessary to slow down the video such that Braille readers can follow the caption text. Or alternatively they should be reading a video transcript if the video is too fast to follow. Transcripts are another feature under discussion in the HTML WG.