On Thu, 15 Apr 2010 09:59:06 +0900, Silvia Pfeiffer
<[email protected]> wrote:
On Thu, Apr 15, 2010 at 3:19 AM, Tab Atkins Jr. <[email protected]>
wrote:
+1 to Henry's suggestion of just using two formats: SRT, and SRT +
(possibly some subset of) HTML+CSS, where the latter is simply a
normal SRT file with HTML allowed where it would normally only allow
plaintext for the caption.
That seems to be the minimal change that can address this case, and
appears to be a fairly logical extension of an existing widespread
format.
A spec would need to be written for this new extended SRT format.
A spec would also need to be written if we go for this new
TTML-minus-certain-features-and-using-CSS-rather-than-XSL-FO format. That
would probably be worse since we would be forking an existing format in an
incompatible way.
Also, if we are introducing HTML markup inside SRT time cues, then it
would make sense to turn the complete SRT file into markup, not just
the part inside the time cue. Further, SRT has no way to specify which
language it is written in and further such general mechanisms that
already exist for HTML.
What general mechanisms are needed exactly? Why is language needed? Isn't
that already specified by the embedder?
I don't think SRT is the right base format to start extending from.
That extension doesn't give us anything anyway, since no existing SRT
application would be able to do much with it. It is not hard to
replicate the SRT functionality in something new. If we really want to
do "SRT + HTML + CSS", then we should start completely from a blank
page.
It makes things easier for people familiar with authoring SRT. It also
makes it easier to change existing SRT files into rich SRT files.
--
Anne van Kesteren
http://annevankesteren.nl/
