- From: Anne van Kesteren <annevk@opera.com>
- Date: Fri, 16 Apr 2010 14:32:11 +0900
On Thu, 15 Apr 2010 09:59:06 +0900, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote: > On Thu, Apr 15, 2010 at 3:19 AM, Tab Atkins Jr. <jackalmage at gmail.com> > 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/
Received on Thursday, 15 April 2010 22:32:11 UTC