[Bug 10320] [WebSRT voice] Allow an arbitrary string as the voice for forwards compatilbity


--- Comment #19 from Philip Jägenstedt <philipj@opera.com> 2010-10-14 11:11:30 UTC ---
(In reply to comment #18)
> (In reply to comment #17)
> > I am not sure it makes sense to have the same timed track for captions and
> > subtitles, that seems like one of those things that sounds clever to software
> > engineers like us but in practice is not that great (case in point, as far as I
> > know it's never been done before). We could, though, in the future, introduce a
> > new kind of cue that the browser could then offer either as a subtitle track or
> > a caption track, with the subtitle version having certain things hidden and the
> > caption track having character names shown in some cases, or some such.
> > 
> > For the specific example of "<v Mary><sound>cough", in practice most captions
> > I've seen would instead use <v desc>Mary coughs</v>" or some such, in italics,
> > not the word "cough" in a special colour or anything. But my experience here is
> > admittedly limited.
> I tend to agree - I think we may be trying to over-engineer this if we shove
> captions and subtitles in the same file. If somebody wanted to keep only one
> copy in a databases with some extra fields for captions that then help
> dynamically create the subtitles and caption files, that would equally deal
> with this potential duplication of data.
> Another potential approach towards solving this is to allow the @kind attribute
> to have multiple values such that we can use e.g. an English caption file both
> for caption and subtitle purposes.

After actually trying to author such a file with stuff like "<v
Mary><sound>cough" I'd be inclined to agree as well, this should at least wait
a bit until people have had more time to experiment with what works and not. Ti
that end, we should provide enough styling hooks to make this possible using
only CSS though, which I think we'll do anyway.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 14 October 2010 11:11:32 UTC