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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10320

--- Comment #20 from Philip Jägenstedt <philipj@opera.com> 2010-10-14 11:40:56 UTC ---
(In reply to comment #18)
> (In reply to comment #17)
> > At this point I'm leaning towards replacing the voice mechanism with <v foo>,
> > where "foo" is any character name or other appropriate voice identifier. I
> > think it might make sense to drop the hard-coded ones like <sound> and
> > <narrator> and just have them be voices too, as in <v sfx> or <v narrator>. The
> > <v foo> construct would only be allowed at the "top level" of a cue, and the
> > </v> would be optional if the <v> was the first thing in the cue.
> 
> 
> That seems to be more akin to the role of <span class="blah"></span> in HTML. I
> think I like it. I also wonder if calling it "voice" may be too specific and it
> should just be a region marker, maybe <m foo></m> ?

I'm quite sympathetic towards removing the hard-coded voices. I'm not sure what
the point of only allowing them at the top level is, that seems to make the
parser slightly more complicated and disallows marking up chipmunk-style cues
where part of the cue is spoken by more than one speaker. What's the benefit?

As for merging (the currently non-existent) styling hooks and voices syntax,
I'm not so sure. At least with the <v Name O'Character> syntax and some CSS,
it's possible to use that to show the speaker name somewhere for the benefit of
HoH. Without that, you'd have to write specific CSS for each captions file.

As stated elsewhere, I actually think TTML does the speaker syntax quite well.
The downside is that it complicates things and we'd need to put some stuff in a
header.

Admittedly, this is a bit theoretical, since not many (any except TTML?)
formats actually have semantic markup for the speaker.

-- 
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:41:00 UTC