[Webkit-unassigned] [Bug 110479] [Meta] Implement support for TTML

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=110479





--- Comment #4 from Glenn Adams <glenn at skynav.com>  2013-02-21 11:20:57 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > If anyone plans to work on this, don't forget to follow this process: <http://www.webkit.org/coding/adding-features.html>.
> > 
> > Certainly. Also, I would expect any code to be bracketed with
> > 
> > #if ENABLE(VIDEO_TRACK) && ENABLE(TTML)
> > #endif
> 
> You need consensus to add the feature even if it has a feature flag.

Sure.

> 
> > 
> > > I am not sure that the WebKit community will be interested in having an implementation of TTML, particularly given the dependency on the XSL-FO formatting model.
> > 
> > (1) the use of XSL-FO in the TTML spec is only for explanatory purposes, namely, describing formatting semantics, and not used for implementation purposes; the same semantics can be restated in terms of CSS as well; so that is not really a substantive objection;
> 
> I don't believe the full XSL-FO formatting model can be mapped CSS, or if it can, no one has done so; it may be possible for the subset of XSL-FO used by a subset of TTML.

A very small amount of the XSL-FO model is referenced by TTML. The part that is referenced can easily be mapped to CSS. In any case, the XSL-FO issue is a non-issue IMO.

The TTML spec says:

"The semantics of TTML style presentation are described in terms of the model in [XSL 1.1]. The intended effect of the attributes in this section are to be compatible with the layout model of XSL. Presentation agents may however use any technology to satisfy the authorial intent of the document. In particular since [CSS2] is a subset of this model, a CSS processor may be used for the features that the models have in common."

"Implementors should recognize that it is the layout model of [XSL 1.1] that is being referenced by this specification, not the requirement to use a compliant [XSL 1.1] formatting processor"

If there are in fact XSL-FO semantics required by TTML that cannot be described in terms of CSS semantics, then I'm sure the TTWG would be interested in learning about them, since it was not the intent of the TTWG to make TTML dependent on XSL-FO from an implementation perspective.

> 
> > 
> > (2) IE10 implements support for a subset of TTML;
> > 
> > (3) the FCC rules could translate to mandatory support in a variety of deployment contexts, e.g., HTML5 UAs embedded in television devices available at retail that are already subject to a variety of FCC rules;
> 
> There are many possible interpretations of the FCC rules. Some say that it's not necessary to specifically implement SMPTE-TT, the safe harbor format, as long as a format with all the mandated capabilities is supported. I have yet to hear an interpretation it's required to implement a subset of TTML that's not the same profile as SMPTE-TT.

The real question is whether video service providers will or would like to reference TTML content directly as a delivery format. We have some preliminary input that they will. We also have a variety of downstream ports of WK that are deploying on devices covered by FCC rules that relate to captions. I agree that we don't have the final word on this subject. But I think absence of finality on this matter is not a reasonable objection to exclude TTML from WK. The WK community has added many other features that have less finality or concrete requirements.

> 
> I think you will find addition of this feature is controversial, as WebVTT exists in part because of some browser implementors objecting to the complexity of TTML.

IMO, those objections were based in part in a misunderstanding of the role of XSL-FO in TTML. As I've pointed out, it serves only as a definitional device, and has little or no impact on implementation. I agree that TTML is more general than WebVTT, and as such has some complexities that are not found in WebVTT. However, there is nothing to indicate that we should not support one of the simpler profiles of TTML such as SMPTE-TT or SDP-US.

In any case, I would be willing to claim that an implementation of all of TTML is at least one or two orders of magnitude simpler than SVG or HTML5, or even some of the more complex, recent additions to CSS.

What would be useful is an implementation of a subset of TTML that works in WK against which objective judgments about complexity, etc,  can be made. At present, the arguments are rather speculative in nature, wouldn't you agree?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.