RE: Ruby in TTML

Sylvia: "I think XSL-FO, the namespaces and possibly the lack of hyperlinks are some of the issues for DFXP. But there are further requirements at http://wiki.whatwg.org/wiki/Timed_tracks , which it would be good to have a reply for how to do them in DFXP."

The http://wiki.whatwg.org/wiki/Timed_tracks  page doesn't contain a lot of justification or history, so I don't see that it represents much of a consensus, therefore I'm hesitant to spend a lot of time working on stuff that's going to be ignored, but I've jotted some notes below. If someone would like to tell me how to add this to a relevant Wiki that would be helpful.  I see no mention of hyperlinks in the whatwg page, and I think they are out of scope, so I'm not going to deal with that until I see what a proposed model would look like.

The namespaces are really a red herring, they are trivial to implement, and they support TTML's extensibility model so I'm not going to waste time justifying them. HTML5 is handling 6 namespaces already so a couple more aren't an issue, if the WG wants to co-opt TTML syntax into HTML, as is done with SVG and MathML, then they can deal with the namespaces in the same way.

Timed Tracks

Requirements: 
   Subtitle/Caption/Karaoke File Format - TTML covers all that (and can be scoped using the profile mechanism to more or less exactly that)

   Track-wide formatting: TTML covers that except for the pseudo element idea (which I think is a non-requirement - see below)

   HTML: These are largely outside of the caption format per se. and stated without justification, however I'll go through the interesting ones.:

      >> some mechanism for text in the page to be used instead of external files, for subtitles/captions or audio description 
           --- Don't know what the use case is here, but this could be as simple as allowing the <track> element to point to an XML island in the HTML using a fragment URI. If it needs to be more fine-grained then we could use XInclude in a TTML file.

  >> an API to allow a segment to be dynamically inserted into the rendering on the fly 
         --- Again no use case or justification is presented, so I have to guess what all the terms mean, but adding a TTML file into a running media presentation is not a problem, and it's possible to merge two TTML time-trees if necessary, although I don't think it is.

  >> an API for exposing what the currently relevant segments of each timed track are 
  -- I don't know what is meant by "currently relevant segments" or why they need to be exposed.  But TTML lends itself to computing all of the display changes in advance and there is a worked example of how to construct a DOM of the active elements at any given time in the TTML spec.

   >> a way to hook into this to manually render timed tracks 
 -- Again no justification, but this is a corollary of the prior point.


Architecture: Not sure what the point of the picture is. Doesn't mean very much to me.
>> The caption format should be reasonable for either a web engine or a media engine to render, since implementation strategies may differ. 
  -- TTML has been implemented in a variety of web and media engine contexts.


The declaring timed tracks section is agnostic as to format.



Pretty much all of http://wiki.whatwg.org/wiki/Use_cases_for_timed_tracks_rendered_over_video_by_the_UA  can be done by TTML except for rotated text and line art. I'm not sure of the priority of that but if its high, then we could introduce an SVG extension to TTML to cover it, as has been done with PNG images in another context.

I'm not sure why CSS is considered such an issue, but certainly applicative style using selectors would work with TTML just as it does with any other XML format and the required properties are all in CSS (see below).  Ian's proposed styling extensions of course are not going to work with the caption rendering in a nested browsing context, so they are a bit of a non-starter if they are in the HTML page and will likely lead to an objection if they are proposed. 

Here is a mapping of Ian's CSS extensions to plain old CSS selectors applied using CSS binding to TTML

video::cue { color: white; background: rgba(0,0,0,0.5); font: 900 sans-serif; text-transform: uppercase; }
-- this is simply p { color: white; background: rgba(0,0,0,0.5); font: 900 sans-serif; }

All uppercase text is bad for reading and is only used in 608 because of legacy issues. Let's not perpetuate that mistake.

video::cue(narrator) { color: white; font-style: italics; }
-- this is simply p[role='narration'] { color: white; background: rgba(0,0,0,0.5); font: 900 sans-serif; }

video::cue(1) { color: yellow; }
video::cue(2) { color: lime; }

Here Ian seems to be shortcutting the CSS WG, but in CSS3 selectors (still WD) this would look like:
div:nth-child(1) { color: yellow; }
div:nth-child(2) { color: lime; }

All of the properties in XSL:FO used by TTML are defined in terms of CSS, although since the CSS WG didn't really wake up to internationalisation, and semi opaque colour till version 3, they are only just getting round to some of the necessary, and most of it such as a generalised box model is still in early WD, which is why TTWG based their formatting on XSL rather than waiting for CSS. I think HTML5 will have the same issue if they are going to have a dependency on CSS.

Here is a mapping of TTML style properties into CSS:

BackgroundColor => css2 equivalent. 'background-color'    (rgba is CSS3)
Color  =>        css2 equivalent. 'color' 
Direction  =>      css2 equivalent. 'direction' 
Display =>       css2 equivalent. 'display' 
DisplayAlign =>    css3 equivalent. 'alignment'
Extent =>       css2 equivalent. 'right and bottom'
FontFamily =>css2 equivalent. 'font-family' 
FontSize =>      css2 equivalent. 'font-size' 
FontStyle =>      css2 equivalent. 'font-style' 
FontWeight =>css2 equivalent. 'font-weight' 
LineHeight =>css2 equivalent. 'line-height' 
Opacity =>       css3 equivalent. 'opacity'
Origin =>       css2 equivalent. 'top and left'
Overflow =>      css2 equivalent. 'overflow' 
Padding =>       css2 equivalent. 'padding' 
ShowBackground =>   no css equivalent.
TextAlign =>      css2 equivalent. 'text-align' 
TextDecoration =>   css2 equivalent. 'text-decoration' 
TextOutline =>     css3 equivalent. 'text-outline'
UnicodeBidi =>     css2 equivalent. 'unicode-bidi' 
Visibility =>css2 equivalent. 'visibility' 
WrapOption =>css3 equivalent. 'text-wrap'
WritingMode =>     css3 equivalent. 'writing mode'
ZIndex =>       css2 equivalent. 'z-index'



DOM API.
I don't think this is relevant since I see no reason for JS to be able to delve into a nested browsing context, so I'd like some use case justification for this. If an API is necessary for TTML then I think HTMLWG should ask the TTWG for one.


-----Original Message-----
From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] 
Sent: Thursday, April 29, 2010 12:50 AM
To: Sean Hayes
Cc: Janina Sajka; John Foliot (jfoliot@stanford.edu); HTML Accessibility Task Force
Subject: Re: Ruby in TTML

On Thu, Apr 29, 2010 at 9:24 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
> Discussion, and an example of display Ruby in TTML is documented here  http://lists.w3.org/Archives/Public/public-tt/2009Jul/0006.html  Not ideal, but a workaround until it can be done properly in v.next.
>
> I would also point out that for the most part Asian legacy subtitles and caption formats use graphics rather than text as a workaround for downloading Asian fonts.
>
> Also note that TTML has an extension mechanism which has been used to address both of these in private implementations.


Thanks for this information. I would suggest bringing this into any discussion that will likely occur soon on the WHATWG or HTML WG mailing lists.

I think XSL-FO, the namespaces and possibly the lack of hyperlinks are some of the issues for DFXP. But there are further requirements at http://wiki.whatwg.org/wiki/Timed_tracks , which it would be good to have a reply for how to do them in DFXP.

Cheers,
Silvia.

Received on Thursday, 29 April 2010 12:06:35 UTC