TTML/changeProposal015

From W3C Wiki

< Change Proposal Index

Style.CSS - OPEN

  • Owner: Glenn Adams.
  • Started: 14/06/13


Issues Addressed

Summary and Change details

TTML 1.0 did not adopt a number of properties that have subsequently been found to important.

Namely :

margin

the margin property was omitted since it was felt that positioning could generally be made explicit using origin and extent, however a common practice in television content is to indent the second and subsequent lines in a multi line caption. This is hard to replicate in TTML 1.0, as it requires explicit positioning of two relative lines, and only regions may be positioned. It can be approximated by using explicit space characters and xml:space preserve, however this is an inaccurate and not a very elegant solution.

This change proposal adds the margin property as a style properties admissible on block level and inline elements.

[GA] Above description appears to describe hanging indent, not margin. WebVTT doesn't have margin, not sure that use case is adequately motivated. Propose WONTFIX as resolution for time being until a better motivated use case is document and an issue is raised.

padding

The padding property was omitted on all elements except the region. This leads to ugly captions if the only opaque background is in the spans.

This change proposal adds the padding property as a style properties admissible on block level and inline elements.

[GA] Implemented in https://dvcs.w3.org/hg/ttml/rev/edf3344d2924.

line (row) padding

This is ISSUE-286.

Padding can be applied to text in a span to improve readability when text is displayed over a background colour. However if a line break is inserted because the text doesn't fit on a single line the padding does not apply. This change proposal adds the box-decoration-break property to allow the padding to apply at line breaks.

Output Example:

No padding

tight alignment of background area with text can be hard to read


Left and right padding

padding on left and right makes it easier


Left and right padding
broken across a line

but in the simple form doesn't apply across line breaks


Left and right padding
broken across a line with decoration=clone

"box-decoration-break: clone" is intended to solve this problem
NB this last example is a mock-up only because box-decoration-break: clone is not supported on all browsers

Note that EBU-TT-D specifies a syntax for this behaviour as a style attribute, ebutts:linePadding that takes a single length parameter and applies it as inline-progression padding on either end of each wrapped line, i.e. roughly equivalent to specifying start and end padding on a span with box-decoration-break: clone. This prior work should be taken as a starting point for developing a syntax in TTML2, which ideally will be a superset of (or identical to) the EBU-TT-D syntax.

TTML2 syntax

[GA] Simple solution: simply define padding on inline elements to use cloned padding at line breaks, i.e., as if box-decoration-break: clone applied. Since padding on content wasn't supported in TTML1, this does not produce a backward compatibility problem.

border

the border property was omitted, as it was felt that a similar effect could be achieved with the padding applied to regions allowinf the background colour to be visible

This however fails to replicate some effects achievable in 708 window styles, which are raised, depressed, uniform, and drop shadow.

This change proposal adds the border property as a style properties admissible on region elements.

[GA] Implemented in https://dvcs.w3.org/hg/ttml/rev/9b0f69325bde. This resolution supports the 'border' property on region *and* all content element types except br. However, it does so by using the shorthand version of the property which simultaneously to all edges.

line stacking strategy

the line stacking strategy property was omitted for simplicity, and the XSL:FO default was assumed, this however is a barrier to mapping the style properties onto CSS, as this is felt to be a larger use case today than when TTML 1.0 was designed, the line stacking property is added. A ttp:parameter can be used to set the appropriate default for this property to override the default. Thus content authored to TTML 1.0 will retain the original stacking semantics, new content has the option of setting the default to that of CSS.

This change proposal reintroduces the line stacking strategy property as a style properties admissible on block level elements.

[GA] Propose no action at this time, but re-review for certainty.

region anchor points

TTML 1.0 has a single anchor point for regions (namely the top left corner). This suffices for content where the size is known ahead of time, however very often content is required that may have a variable width or height (so called shrink-to-fit) layouts. In such a case it is not possible with any degree of accuracy to create center, bottom or right aligned regions.

This proposal allows the author greater control to define the anchor point on the region by extending the extent attribute to allow two optional additional values to represent 'right' and 'bottom', and to allow both the origin attribute and extent attributes to admit 'auto' as a value. The default will be 0, 0 thus old content will continue to work as before, but new content will be able to take advantage of the new styles.

For example, a region centered around the 50% vertical, which is 90% of the screen width and 20% of the screen height and placed flush on the bottom screen edge: 


<region tts:origin="5% auto" tts:extent="auto 20% 5% 0%"

[GA] Add tts:position property for use on root (tt) and other region defining elements, as an alternative way to express position by anchoring to a specific point or from an edge. Add tts:width,height which accepts fitContent value (as well as minContent, maxContent, available, etc) for use on div, p, span, and image, thus supporting shrink fit. Upgrade tts:extent to accept measure expression to do same on regions.

text outline

At the time TTML 1.0 was authored, the CSSWG was working on an outline property. This property was never finished, and has since been dropped. A similar effect can be approximated using the text-shadow property. Such an effect is important to reproduce TV content. Thus this change proposal re-defines the text outline property in terms of the text shadow property which is also added (see below).

[GA] Review and determine if textOutline can have its syntax/semantics enlarged to include the semantics of text-shadow. Do not eliminate textOutline for backward compat reasons.

text shadow

See above for rationale. In addition the text-shadow property may be used to create the text raised and lowered effects as well as drop shadows and feathering asked for by SMPTE and the FCC regulations for internet delivered TV. Thus this change proposal adds the text shadow property.

shrink fit

It is sometimes advantageous to be able to define regions such that their width and height is not determined in advance, but is determined instead by the length of the longest natural linebox created by the content. This change proposal allows the values auto to be used in the extent property to achieve this.

[GA] Add tts:width,height which accepts fitContent value (as well as minContent, maxContent, available, etc) for use on div, p, span, and image, thus supporting shrink fit. Upgrade tts:extent to accept measure expression to do same on regions.

[GA] Instead of using width, height, use ipd and bpd in order to be writing mode sensitive. Use tts:extent for image instead of ipd/bpd.

font face rule

This is ISSUE-273

In order to present a document as intended when the document was authored some shared knowledge of the fonts that will be used to render is advantageous. It would reduce the likelihood that rendered text will not fit within the allocated region, and increase the likelihood that the font will be displayed as intended. Another use case is to ensure that all the glyphs required are present: an author may wish to provide a reference to a font resource that is known to include those glyphs. The CSS3 mechanism to provide access to downloadable font resources, which can then be referenced by tts:fontFamily is the @font-face rule. This change proposal allows multiple font-face to be used in the <styling> element to achieve this.

[GA] Add font element definition, though different in syntactic details from the following.

Example TTML (suggested syntax - for review): 

<styling>
   <fontFace fontFamilyName="myNiceFont">
      <fontFaceSource fontFaceUrl="myNiceFont.woff" fontFaceFormat="woff">
      <fontFaceSource fontFaceUrl="myNiceFont.ttf" fontFaceFormat="opentype">
   </fontFace>
   <style id="s1" tts:fontFamily="myNiceFont"/>
</styling>

EBU-TT proposal (advisory, under discussion, not formally proposed to TTWG yet)

[Update]: this proposal is in flux - it is likely that a data structure closer to the CSS @font-face rule and to the ARIB-TT structure will be proposed in place.

An alternative syntax has been proposed for EBU-TT, including fontWeight, fontStyle and fontUnicodeRange to allow for more granularity: 

<fontFace fontFamilyName="Tiresias">
   <fontFaceSource uri="http://typo.com/tiresias-bold" fontWeight="bold"/>
   <fontFaceSource uri="http://typo.com/tiresias-italic" fontStyle="italic"/>
   <fontFaceSource uri=”http://typo.com/tiresias-euro” fontUnicodeRange =”U+20AC“/>
   <fontFaceSource uti="http://typo.com/tiresias"/>
</fontFace>

The elements are:

  • Element fontFace
  • Type: xs:string
  • Cardinality: 0..*
  • Content: 1 or more fontFaceSource elements

The fontFace element has a single required attribute.

  • Attribute: fontFamilyName
  • Type: <familyName> | <genericFamilyName>
  • REQUIRED
  • Description: this is used to match the tts:fontFamily attribute value with this element.

The fontFace element has a required child element.

  • Element fontFaceSource
  • Child of fontFace
  • Cardinality: 1..*
  • Content: none
  • Description: The fontFaceSource element allows the author to identify a resource for a font used during authoring text for a particular fontFamily.

The fontFaceSource element has a single required attribute.

  • Attribute: uri
  • Type: xs:anyURI
  • REQUIRED
  • Description: this is used to specify a location for the referenced fontFace.

The fontFaceSource element has three optional attributes.

  • Attribute: fontWeight
  • Type: enum normal|bold
  • OPTIONAL
  • Description: this is used to qualify the referenced fontFace as specific for text that has bold styling applied.


  • Attribute: fontStyle
  • Type: enum normal|italic
  • OPTIONAL
  • Description: this is used to qualify the referenced fontFace as specific for text that has italic styling applied.


  • Attribute: fontUnicodeRange
  • Type: xs:string (The value is a comma-delimited list of Unicode range (<urange>) values. Each <urange> value is a UNICODE-RANGE token made up of a "U+" or "u+" prefix followed by a codepoint value as either: a single decimal codepoint (e.g. U+416) represented as one to six hexadecimal digits; or an interval range (e.g. U+400-4ff) represented as two hyphen-separated Unicode codepoints indicating the inclusive start and end codepoints of a range. Note: Multiple single codepoints and ranges may occur within the fontUnicodeRange value.)
  • OPTIONAL
  • Description: this defines the set of Unicode codepoints that may be referenced from the fontFaceSource for which it is declared. If this attribute is absent then all codepoints may be (attempted to be) referenced from the fontFaceSource. If this attribute is present then, if a codepoint in text content falls within the range(s) of Unicode codepoints specified, then glyphs from the referenced source URI may be used as reference when processing the document.

The fontFaceSource child elements must be interpreted as follows. A fontFaceSource element with fontUnicodeRange qualifying attributes should be used as a reference for a specific fontFamily if the codepoints (and applied styling) of any text within the document match the fontUnicodeRange qualification and any other specified qualifying attributes on this fontFaceSource element. If multiple fontFaceSource child elements match a given codepoint by fontUnicodeRange qualification, then any additional qualifying attributes are examined and the fontFaceSource child element with the closest matching qualifying attributes is used as reference, or in the event of multiple matches, the first declared fontFaceSource child element is used as a reference. Closeness is defined using in decreasing order of precedence 1) a unicode range match 2) count(matches([fontWeight, fontStyle])) 3) document order (earlier is preferred).

Further examples: 

<fontFace fontFamilyName=”Tiresias”>
<fontFaceSource uri=”http://typo.com/tiresias”/>   !- Would match a NON bold and NON italic Euro symbol
< fontFaceSource uri=”http://typo.com/tiresias-euro-bold” fontWeight =”bold” fontUnicodeRange =”U+20AC“/>   !- Would match a bold Euro symbol
< fontFaceSource uri=”http://typo.com/tiresias-euro-italic” fontStyle =”italic” fontUnicodeRange =”U+20AC“/>   !- Would match an italic Euro symbol
< fontFaceSource uri=”http://typo.com/tiresias-bold” fontWeight =”bold” />
< fontFaceSource uri=”http://typo.com/tiresias-italic” fontStyle =”italic” />
</fontFace>



<fontFace fontFamilyName=”Tiresias”>
< fontFaceSource uri=”http://typo.com/tiresias”/>   !- Would match all codepoints except between 2000-20FF
< fontFaceSource uri=”http://typo.com/tiresias-range1” fontUnicodeRange =”U+2000-20FF“/>   !- Would match all codepoints between 2000-20FF except italics (this should be used for bold!)
< fontFaceSource uri=”http://typo.com/tiresias- range1-italic” fontStyle =”italic” fontUnicodeRange =”U+2000-20FF“/>   !- Would match all italics codepoints between 2000-20FF
< fontFaceSource uri=”http://typo.com/tiresias-bold” fontWeight =”bold”/>   !- Would match all bold codepoints except between 2000-20FF
< fontFaceSource uri=”http://typo.com/tiresias-italic” fontStyle =”italic”/>   !- Would match all italic codepoints except between 2000-20FF
</fontFace>

ARIB-TT font-face

The ARIB-TT format (PDF) also defines an element font-face element of type <arib:font-faceType>.

This is defined as: 

<xsd:element name="font-face" type="arib:font-faceType"/>

<xsd:complexType name="font-faceType">
   <xsd:sequence>
      <xsd:element name="src" type="arib:font-face-srcType" maxOccurs="unbounded"/>
   </xsd:sequence>
   <xsd:attribute name="font-family" type="xsd:string" use="required"/>
   <xsd:attribute name="unicode-range” type="xsd:string"/>
   <xsd:attribute name="id" type="xsd:ID"/>
</xsd:complexType>

<xsd:complexType name="font-face-srcType">
   <xsd:attribute name="url" type="xsd:anyURI" use="required"/>
   <xsd:attribute name="format" type="xsd:string"/>
   <xsd:attribute name="id" type="xsd:ID"/>
</xsd:complexType>

ToDo:

translate the accompanying prose into English (at least for English readers!)

multiple row alignment (flex box in CSS mapping)

This is ISSUE-285

A common captioning presentation style requires the alignment of displayed rows of text relative to each other, and alignment of the set relative to a region. This can be achieved using the flex property in CSS.

For example (when mapped to HTML/CSS): 

<div style="display: flex; justify-content: center; width: 75%;">
<p style="text-align: left;">
Beware the Jubjub bird, and shun<br/>
The frumious Bandersnatch!
</p>
</div>

This example renders as:

Beware the Jubjub bird, and shun
The frumious Bandersnatch!

A TTML-style syntax for this mapping is defined in EBU-TT and EBU-TT-D using the ebutts:multiRowAlign attribute, which modifies the behaviour of tts:textAlign.

The above example would be expressed in EBU-TT (omitting irrelevant bits) as: 

<styling>
   <style id="s2" textAlign="center" ebutts:multiRowAlign="start"/>
</styling>
...
<body>
   <div>
      <p style="s2">
         <span>Beware the Jubjub bird, and shun<br/>The frumious Bandersnatch!</span></p>
 ...

The mapping of multiRowAlign to the justify-content property applied to a HTML div with the display property set to flex is:

multiRowAlign justify-content
start flex-start
center center
end flex-end

[GA] Allow tts:textAlign on span which causes it to use inline-block display formatting semantics, thus supporting a distinct alignment from outer paragraph block.

superscript and subscript (font-variant-position in CSS mapping)

This is ISSUE-24

Dependencies on other packages

As the effects that the new properties allow are not in general achievable using TTML 1.0 properties authors are potentially faced with a dilemma in creating content which will work adequately on older processors while still taking advantage of the new properties. The Conditional Styling proposal will allow graceful forward compatibility to the extent possible.

Edits to be applied

TBD

Edits applied

Impact

  • Simplifies conversion from 608 and 708 content.
  • Fixes incompatibilities with CSS
  • Allows greater control of margins within a paragraph.
  • Allows more flexible content to be authored
  • Allows greater control of rendered appearance of text

References

Retrieved from "https://www.w3.org/wiki/index.php?title=TTML/changeProposal015&oldid=101242"