Re: [ttml2] Action-369 - collate smpte issues and draft dispositions

From: Glenn Adams <<>> Date: Thursday, 5 March 2015 14:46

On Thu, Mar 5, 2015 at 1:35 AM, Nigel Megitt <<>> wrote:
From: Glenn Adams <<>> Date: Wednesday, 4 March 2015 18:49

On Wed, Feb 25, 2015 at 8:22 AM, Nigel Megitt <<>> wrote:
As discussed in our meeting of 2015-02-12, I've updated this draft disposition as below, taking into account the guidance from that meeting (minutes at There are no outstanding questions on the dispositions, though an editorial pass would be a good idea before sending outside the TTWG.

NB the dispositions are intended to capture the sense of the implementation state, with the intent that if that is captured correctly it should be edited as needed prior to issuing as a formal communication.

Relating to the liaison at – I considered the previous requests concerning metadata to be out of scope of this action.

This is Issue-224

Disposition: Implementing using the tts:disparity style attribute applicable to div, p and region, as a positive or negative length value matching the requested semantics. Note that the animate element may be used to continuously animate the value of this style attribute if required.
The applicability of disparity to div and p needs to be qualified to avoid confusion. In fact, it is not directly applicable to div or p, but is applicable to an anonymous inline region to be associated with the div or p. That is, specifying disparity on div or p behaves like specifying extent or origin on div or p, in that it triggers generation of an anonymous inline region to which these properties directly apply.

Yes, thanks for pointing that out – I suggest we simply remove the div and p references, as it's really only applicable to a region. I think the TTML2 spec could also use some non normative text describing the various (three by my count) ways to specify region placement also, perhaps in the Introduction section 1.2. Also I see that implied inline regions are omitted from the specification of region in 11.1.2, where I'd expect to see it, even if only to define the priorities of region creation if a content element has both origin/extent attributes and an explicit inline region.

tts:fontSize as percentage of root container dimensions
This is Issue-225 - CLOSED

Disposition: Implemented by adding vw and vh metrics to all values whose syntax is specified as <length>, where vw is 1% of the width of the root container region and vh is 1% of the height of the root container region.

<p> origin and extent
This is Issue-226 – CLOSED duplicate of Issue-176 – CLOSED.

Disposition: Implemented by permitting tts:origin and tts:extent to be specified on <p> and <div> as a shorthand for specifying an inline region.
s/inline region/anonymous inline region/

I think you mean "implied inline region"?

maybe; but the phrase anonymous inline region is also used

"implied inline region" is the defined term in TTML2 ED so it makes more sense to use it here.

<p> fade-up and –down
- apply tts:opacity to <p>
This is Issue-227 - CLOSED

Disposition: Implemented: tts:opacity style attribute now applies to body, div, p, region and span, and the animate element may be applied for specifying continuous (as opposed to discrete) changes to styling attributes including opacity.

Ruby text
- position before or after
- offset –1.0 em to +infinity
This is Issue-228 - CLOSED

Disposition: Implemented within constraints of Ruby Annotations using new syntax, i.e. by introducing ruby attributes on <span> elements, not by introducing <ruby>, <rt>, <rb> etc elements as per HTML5.
The positions permitted are before, after and around. The offset is not constrained.

Might be useful to explicitly cite the new tts:rubyPosition and tts:rubyOffset properties. Note also the tts:rubyAlign property which wasn't explicitly asked for by SMPTE (AFAICT), but which is commonly required in practice.

Okay – then s/ruby attributes/the ruby attributes tts:rubyAlign, tts:rubyOffset and tts:rubyPosition/

Mixed vertical-horizontal progression direction
This is Issue-357 – CLOSED duplicate of Issue-229 – CLOSED.

Disposition: Implemented using tts:textCombine style attribute based on semantics on CSS Writing Modes §9.1. This allows horizontal text in a <span> to be inserted into vertical writing mode text so that the combined glyph areas fit in the em square of the surrounding vertical text. If the desired effect is to extend beyond a single em square, the applicable font size
or line height
in the surrounding area can be increased to make the em square bigger in the context of the horizontal group.
The latter is not entirely accurate (or specified as such). At present, the spec require the UA to fit the horizontal content into an EM square, which matches CSS's lack of specificity. Therefore, it is UA dependent as specified as to whether and how much scaling might be automatically applied.

In practice, I suspect it would be useful to have one or more additional properties that allow the author to give guidance to the UA on how to do this.

So would this work in place of the last sentence:

If the desired effect is to extend beyond a single em square, presentation processors can apply scaling to the em square for example to match the font size or line height, however this behaviour is currently unspecified.

change to "can apply scaling to the horizontal content to obtain a fit, however ..."


Forced display
This is Issue-230 - CLOSED

Disposition: Implemented using the condition attribute and a bound parameter named 'forced' - this allows the value of for example the style attribute tts:visibility to be conditionally set to "visible" or "hidden" on style elements which can then be applied to the text that is 'non-forced' to determine whether or not it should be rendered.

Individual character rotation
This is Issue-229 - CLOSED

Disposition: Implemented using the tts:textOrientation style attribute that can be applied to a <span>.
It might be useful to point out that only a small set of discrete orientations are supported at present, and inquire whether arbitrary rotation is required or not.

This done in my subsequent update relating to Issue-231.

Bottom-to-top text direction
This is Issue-232 - CLOSED

Disposition: Not implemented – marked as 'won't fix'. We have not identified a use case for this. If there is a use case please tell us what it is. Also note that there is no support for bottom to top writing mode in CSS so a mapping into HTML/CSS may not be possible for this feature.

Superscript and subscript character style
- baseline vertically offset by –0.5em or +0.5em
- fontsize 0.6em

This is Issue-233 – CLOSED duplicate of Issue-24 – CLOSED.

Disposition: Implemented using the tts:fontVariantPosition style attribute with values normal/sub/super and semantics based on CSS Fonts §6.5. Note that the requested behaviour of baselines offset by +0.5em or –0.5em and a font size of 0.6em is not required by this solution, but may be acceptable in some implementations. However it would be preferable to avoid offsetting the baseline and use the superscript and subscript variant glyphs in the font where available, or where not available, to use the subscript and superscript fallback metrics specified within the font t's OS/2 table. fontVariationPosition does apply cumulatively to nested <span>s.
Note that we expect to rename and generalize tts:fontVariantPosition to tts:fontVariant.

We should generally disclaim that this is a work in progress and details may change – the current snapshot has tts:fontVariantPosition so we should keep it.

Drop shadow character style
- diagonally below and to the right
- specify color
- specify thickness in em

This is Issue-234 - CLOSED
Disposition: Implemented using the tts:textShadow style attribute, based on the semantics of CSS Text Decoration Module Level 3 §4 text-shadow property.

Feathering of shadow and outline effects

This is Issue-235 - CLOSED
Disposition:  Implemented using the tts:textShadow style attribute, based on the semantics of CSS Text Decoration Module Level 3 §4 text-shadow property.

Character spacing, i.e. Letter-spacing with a span in units of em from –1em to +infinity
Inline space –1em to +infinity

This is Issue-236 duplicated as Issue-354 - CLOSED
Disposition: Implemented using the tts:letterSpacing style attribute, based on the semantics of CSS Text Module Level 3 §8.2 letter-spacing property.

[end of requests]


This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.


Received on Wednesday, 18 March 2015 10:44:54 UTC