TTML Profiles for Internet Media Subtitles and Captions 1.0.1 (IMSC1)

W3C Candidate Proposed Recommendation 13 July 2017

This version:
https://www.w3.org/TR/2017/CR-ttml-imsc1.0.1-20170713/ https://www.w3.org/TR/2018/PR-ttml-imsc1.0.1-20180220/
Latest published version:
https://www.w3.org/TR/ttml-imsc1.0.1/
Latest editor's draft:
https://w3c.github.io/imsc/imsc1/spec/ttml-ww-profiles.html
Implementation report:
https://www.w3.org/wiki/TimedText/IMSC1_0_1_Implementation_Report
Previous version:
https://www.w3.org/TR/2017/WD-ttml-imsc1.0.1-20170322/ https://www.w3.org/TR/2017/CR-ttml-imsc1.0.1-20170713/
Editor:
Pierre Lemieux ,
Latest IMSC1 recommendation:
https://www.w3.org/TR/ttml-imsc1/

Abstract

This document specifies two profiles of [ TTML1 ]: a text-only profile and an image-only profile. These profiles are intended to be used across subtitle and caption delivery applications worldwide, thereby simplifying interoperability, consistent rendering and conversion to other subtitling and captioning formats.

It is feasible to create documents that simultaneously conform to both [ ttml10-sdp-us ] and the text-only profile.

The document defines extensions to [ TTML1 ], as well as incorporates extensions specified in [ ST2052-1 ] and [ EBU-TT-D ].

Both profiles are based on [ SUBM ].

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the Timed Text Working Group as a Candidate Proposed Recommendation. This document is intended to become a W3C Recommendation. Comments regarding this document are welcome. Please send them to public-tt@w3.org ( subscribe , archives ) with [imsc] at the start of your email's subject. The W3C publishes a Candidate Recommendation Membership and other interested parties are invited to indicate that review the document is believed to be stable and send comments to encourage implementation by public-tt@w3.org ( subscribe , archives ) through 20 March 2018. Advisory Committee Representatives should consult their WBS questionnaires . Note that substantive technical comments were expected during the developer community. This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 13 August 2017. review period that ended 15 February 2018.

Please see the Working Group's implementation report .

For this specification to exit the CR stage, The implementation report documents that there are at least 2 independent implementations of for every feature defined in this specification but not already present in [ IMSC1 ] need to be documented in the implementation report. The implementation report is based on implementer-provided test results for ], thereby satisfying the exit criteria test suite . The Working Group does not require that implementations are publicly available but encourages them to be so.

The Working Group has not identified features "at risk" for this specification.

A list of the substantive changes applied since the initial Working Draft is found at substantive-changes-summary.txt .

This revision of the document is designed such that Processors and document instances that conform to the Recommendation dated 21 April 2016 also conform to this revision. As a result, review should focus on the modifications made since the Recommendation dated 21 April 2016 , including the 6.7.5 ittp:activeArea and 6.7.6 itts:fillLineGap features. For convenience, a complete diff between this version and the previous Candidate Recommendation dated 21 April 2016 13 July 2017 is found offered at diff.html the W3C HTML Diff service .

Publication as a Candidate Proposed Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .

This document is governed by the 1 March 2017 February 2018 W3C Process Document .

1. Scope

This specification defines two profiles of [ TTML1 ]: a text-only profile and an image-only profile. These profiles are intended for subtitle and caption delivery worldwide, including dialog language translation, content description, captions for deaf and hard of hearing, etc.

The text profile is a syntactic superset of [ ttml10-sdp-us ], and a document can simultaneously conform to both [ ttml10-sdp-us ] and the text-only profile.

The document defines extensions to [ TTML1 ], as well as incorporates extensions specified in [ ST2052-1 ] and [ EBU-TT-D ].

This version of the specification makes editorial corrections and adds two optional features ( 6.7.5 ittp:activeArea and 6.7.6 itts:fillLineGap ) over the Recommendation dated 21 April 2016 . Processors and document instances that conform to the Recommendation dated 21 April 2016 also conform to this version of the specification.

2. Documentation Conventions

This specification uses the same conventions as [ TTML1 ] for the specification of parameter attributes, styling attributes and metadata elements. In particular:

All content of this specification that is not explicitly marked as non-normative is considered to be normative. If a section or appendix header contains the expression "non-normative", then the entirety of the section or appendix is considered non-normative.

This specification uses Feature and Extension designations as defined in Appendices D.1 and E.1 at [ TTML1 ]:

If the name of an element referenced in this specification is not namespace qualified, then the TT namespace applies (see 6.3 Namespaces .)

3. Terms and Definitions

Default Region . See Section 9.3.1 at [ TTML1 ].

Document Instance . See Section 2.2 at [ TTML1 ].

Extension . See Section 2.2 at [ TTML1 ].

Feature . See Section 2.2 at [ TTML1 ].

Intermediate Synchronic Document . See Section 9.3.2 at [ TTML1 ].

Document Interchange Context . See Section 2.2 at [ TTML1 ].

Document Processing Context . See Section 2.2 at [ TTML1 ].

Linear White-Space . See Section 2.3 at [ TTML1 ].

Processor . Either a Presentation processor or a Transformation processor .

Presentation processor . See Section 2.2 at [ TTML1 ].

Transformation processor . See Section 2.2 at [ TTML1 ].

Related Media Object . See Section 2.2 at [ TTML1 ].

Related Video Object . A Related Media Object that consists of a sequence of image frames, each a rectangular array of pixels.

Root Container Region . See Section 2.2 at [ TTML1 ].

Text Alternative . As defined in [ WCAG20 ].

4. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY , SHALL , SHALL NOT , SHOULD , and SHOULD NOT are to be interpreted as described in [ RFC2119 ].

A Document Instance that conforms to a profile defined herein:

Note

A Document Instance , by definition, satisfies the requirements of Section 3.1 at [ TTML1 ], and hence a Document Instance that conforms to a profile defined herein is also a conforming TTML1 Document Instance.

A presentation processor that conforms to a profile defined in this specification:

A transformation processor that conforms to a profile defined in this specification:

Note

The use of the term presentation processor ( transformation processor ) within this specification does not imply conformance to the DFXP Presentation Profile (DFXP Transformation Profile) specified in [ TTML1 ]. In other words, it is not considered an error for a presentation processor ( transformation processor ) to conform to a profile defined in this specification without also conforming to the DFXP Presentation Profile (DFXP Transformation Profile).

Note

This specification does not specify presentation processor or transformation processor behavior when processing or transforming a non-conformant Document Instance .

Note

The permitted and prohibited dispositions do not refer to the specification of a ttp:feature or ttp:extension element as being permitted or prohibited within a ttp:profile element.

5. Profiles

5.1 General

Notwithstanding special cases, e.g. a Document Instance that contains no p , span , br element and no smpte:backgroundImage attribute, it is generally not possible to construct a Document Instance that conforms to the Text Profile and Image Profile simultaneously, and it is not possible to construct a Document Instance that results in the presentation of both text data and image data.

In applications that require subtitle/caption content in image form to be simultaneously available in text form, two distinct Document Instances , one conforming to the Text Profile and the other conforming to the Image Profile , SHOULD be offered. In addition, the Text Profile Document Instance SHOULD be associated with the Image Profile Document Instance such that, when image content is encountered, assistive technologies have access to its corresponding text form. The method by which this association is made is left to each application.

Note

The ittm:altText element specified 6.7.4 ittm:altText also allows text equivalent string to be associated with an image, e.g. to support indexation of the content and also facilitate quality checking of the document during authoring.

Annex D. WCAG Considerations specifically discusses this specification in the context of the [ WCAG20 ] guidelines.

5.2 Text Profile

The Text Profile consists of Sections 6. Common Constraints and 7. Text Profile Constraints .

5.3 Image Profile

The Image Profile consists of Sections 6. Common Constraints and 8. Image Profile Constraints .

5.4 Profile Resolution Semantics

For the purpose of content processing, the determination of the resolved profile SHOULD take into account both the signaled profile, as defined in 6.9 Profile Signaling , and profile metadata, as designated by either (or both) the Document Interchange Context or (and) the Document Processing Context , which MAY entail inspecting document content.

If the resolved profile is not a profile supported by the Processor but is feasibly interoperable with the Text Profile , then the resolved profile is the Text Profile ; otherwise, if the resolved profile is not a profile supported by the Processor but is feasibly interoperable with the Image Profile , then the resolved profile is the Image Profile .

If the resolved profile is a profile supported by the Processor , then the Processor SHOULD process the Document Instance according to the resolved profile. If the resolved profile is neither Text Profile nor Image Profile , processing is outside the scope of this specification.

If the resolved profile is undetermined or not supported by the Processor , then the Processor SHOULD nevertheless process the Document Instance using one of its supported profiles, with a preference for the Text Profile over the Image Profile ; otherwise, processing MAY be aborted.

6. Common Constraints

6.1 Document Encoding

A Document Instance SHALL use UTF-8 character encoding as specified in [ UNICODE ].

6.2 Foreign Element and Attributes

A Document Instance MAY contain elements and attributes that are neither specifically permitted nor forbidden by a profile.

A transformation processor SHOULD preserve such elements or attributes whenever possible.

Note

Document Instances remain subject to the content specification for the tt root document element and its descendants, as conformance requirements specified in at Section 3.1 of [ TTML1 ]. In particular, the [ TTML1 a Document Instance ] content specification specifies that can contain elements and attributes not in any TT namespace, i.e. in foreign namespaces, are permitted as follows: the metadata element is the only element whose child elements can belong to foreign namespaces, and the metadata element is permitted on all since such elements defined by [ TTML1 ] with the exception of the following: ttp:feature , ttp:extension , tt , style , ttm:title , ttm:desc , ttm:copyright , ttm:agent , ttm:name , and ttm:actor ; and foreign namespace attributes are permitted on all elements defined pruned by the algorithm at Section 4 of [ TTML1 ]. ] prior to evaluating content conformance.

Note
For validation purposes it is good practice to define and use a content specification for all foreign namespace elements and attributes used within a Document Instance .

6.3 Namespaces

The following namespaces (see [ xml-names ]) are used in this specification:

Name Prefix Value Defining Specification
XML xml http://www.w3.org/XML/1998/namespace [ xml-names ]
TT tt http://www.w3.org/ns/ttml [ TTML1 ]
TT Parameter ttp http://www.w3.org/ns/ttml#parameter [ TTML1 ]
TT Styling tts http://www.w3.org/ns/ttml#styling [ TTML1 ]
TT Feature none http://www.w3.org/ns/ttml/feature/ [ TTML1 ]
SMPTE-TT Extension smpte http://www.smpte-ra.org/schemas/2052-1/2010/smpte-tt [ ST2052-1 ]
EBU-TT Styling ebutts urn:ebu:tt:style [ EBU-TT-D ]
EBU-TT Metadata ebuttm urn:ebu:tt:metadata [ EBU-TT-D ]
IMSC 1.0 Styling itts http://www.w3.org/ns/ttml/profile/imsc1#styling This specification
IMSC 1.0 Parameter ittp http://www.w3.org/ns/ttml/profile/imsc1#parameter This specification
IMSC 1.0 Metadata ittm http://www.w3.org/ns/ttml/profile/imsc1#metadata This specification
IMSC 1.0 Extension none http://www.w3.org/ns/ttml/profile/imsc1/extension/ This specification
IMSC 1.0 Text Profile Designator none http://www.w3.org/ns/ttml/profile/imsc1/text This specification
IMSC 1.0 Image Profile Designator none http://www.w3.org/ns/ttml/profile/imsc1/image This specification

The namespace prefix values defined above are for convenience and Document Instances MAY use any prefix value that conforms to [ xml-names ].

The namespaces defined by this specification are mutable [ namespaceState ]; all undefined names in these namespaces are reserved for future standardization by the W3C .

6.4 Overflow

A Document Instance SHOULD be authored assuming strict clipping of content that falls out of region areas, regardless of the computed value of tts:overflow for the region.

Note

As specified in [ TTML1 ], tts:overflow has no effect on the extent of the region, and hence the total normalized drawing area S(E n ) at 9.3 Paint Regions .

6.6 Synchronization

Each intermediate synchronic document of the Document Instance is intended to be displayed on a specific frame and removed on a specific frame of the Related Video Object .

When mapping a media time expression M to a frame F of a Related Video Object , e.g. for the purpose of rendering a Document Instance onto the Related Video Object , the presentation processor SHALL map M to the frame F with the presentation time that is the closest to, but not less, than M.

Note

In typical scenario, the same video program (the Related Video Object ) will be used for Document Instance authoring, delivery and user playback. The mapping from media time expression to Related Video Object above allows the author to precisely associate subtitle video content with video frames, e.g. around scene transitions. In circumstances where the video program is downsampled during delivery, the application can specify that, at playback, the relative video object be considered the delivered video program upsampled to is original rate, thereby allowing subtitle content to be rendered at the same temporal locations it was authored.

6.7 Extensions

6.7.1 ittp:aspectRatio

The ittp:aspectRatio attributes allows authorial control of the mapping of the root container Root Container Region of a Document Instance to each image frame of the Related Video Object .

If present, the ittp:aspectRatio attribute SHALL conform to the following syntax:

ittp:aspectRatio
ittp:aspectRatio
  : numerator denominator          // with int(numerator) != 0 and int(denominator) != 0
                                   // where int(s) parses string s as a decimal integer.
numerator | denominator
  : <digit>+                 // no linear white-space is implied or permitted
                                   // between each <digit> token

The root container Root Container Region of a Document Instance SHALL be mapped to each image frame of the Related Video Object according to the following:

  1. If ittp:aspectRatio is present, the root container Root Container Region SHALL be mapped to a rectangular area within the image frame such that:

    1. the ratio of the width to the height of the rectangular area is equal to ittp:aspectRatio ,
    2. the center of the rectangular area is collocated with the center of the image frame,
    3. the rectangular area is entirely within the image frame, and
    4. the rectangular area has a height or width equal to that of the image frame.
  2. Otherwise, the root container Root Container Region of a Document Instance SHALL be mapped to the image frame in its entirety.

An ittp:aspectRatio attribute is considered to be significant only when specified on the tt element.

Note

The ittp:aspectRatio parameter effectively defines the display aspect ratio (DAR) of the root container, while the tts:extent style property on the root element effectively defines the storage aspect ratio (SAR) of the root container. Root Container Region . As a result, when both tts:extent and ittp:aspectRatio are specified on the tt element, the effective pixel aspect ratio (PAR) of the root container Root Container Region is equal to the ratio of the DAR to the SAR.

Note
The mapping algorithm above allows the author to precisely control caption/subtitle position relative to elements within each frame of the video program, e.g. to match the position of actors. This mapping algorithm does not however specify the presentation of either the video frame or root container Root Container Region on the ultimate display device. This presentation depends on many factors, including user input, and can involve displaying only parts of the content. Authors are therefore encouraged to follow best practices for the intended target applications. Below are selected examples:
  • A 16:9 video program is authored to ensure adequate presentation on 4:3 display devices using a center-cut. Accordingly subtitle/captions are authored using ttp:aspectRatio="4 ittp:aspectRatio="4 3" , allowing the combination to be displayed on both 4:3 and 16:9 display devices while preserving both caption/subtitles content and the relative position of caption/subtitles with video elements.
  • A playback system zooms the content of example (a) to fill a 21:9 display, perhaps as instructed by the user. The system elects to scale the root container Root Container Region to fit vertically within the display (maintaining its aspect ratio as authored), at the cost of losing relative positioning between caption/subtitles and video elements.
  • The system described in (b) instead elects to map the root container Root Container Region to the video frame, maintaining relative positioning between caption/subtitles and video elements but at the risk of clipping subtitles/captions.

6.7.2 ittp:progressivelyDecodable

A progressively decodable Document Instance is structured to facilitate presentation before the document is received in its entirety, and can be identified using ittp:progressivelyDecodable attribute.

A progressively decodable Document Instance is a Document Instance that conforms to the following:

  1. no attribute or element of the TTML timing vocabulary is present within the head element;
  2. given two intermediate synchronic documents A and B of the Document Instance , with start times TA and TB , respectively, TA is not greater than TB if A includes a p element that lexically precedes any p element that B includes;
  3. no attribute of the TTML timing vocabulary is present on a descendant element of p ; and
  4. no element E1 explicitly references another element E2 where the opening tag of E2 is lexically subsequent to the opening tag of E1 .

If present, the ittp:progressivelyDecodable attribute SHALL conform to the following syntax:

ittp:progressivelyDecodable
ittp:progressivelyDecodable
  : "true"
  | "false"

An ittp:progressivelyDecodable attribute is considered to be significant only when specified on the tt element.

If not specified, the value of ittp:progressivelyDecodable SHALL be considered to be equal to "false" .

A Document Instance for which the computed value of ittp:progressivelyDecodable is "true" SHALL be a progressively decodable Document Instance .

A Document Instance for which the computed value of ittp:progressivelyDecodable is "false" is neither asserted to be a progressively decodable Document Instance nor asserted not to be a progressively decodable Document Instance .

Example 3
Example 3
<tt
  xmlns="http://www.w3.org/ns/ttml"
  xmlns:ttm="http://www.w3.org/ns/ttml#metadata" 
  xmlns:tts="http://www.w3.org/ns/ttml#styling"
  xmlns:ttp="http://www.w3.org/ns/ttml#parameter" 
  xmlns:ittp="http://www.w3.org/ns/ttml/profile/imsc1#parameter"
  ittp:progressivelyDecodable="true"
  ttp:profile="..."
 >
 ...

</

tt

>

Note

[ TTML1 ] specifies explicitly referencing of elements identified using xml:id in the following circumstances:

  • an element in body referencing region elements. In this case, Requirement 4 above is always satisfied.
  • an element in body referencing style elements. In this case, Requirement 4 above is always satisfied.
  • a region element referencing style elements. In this case, Requirement 4 above is always satisfied.
  • a style element referencing other style elements. In this case, Requirement 4 provides an optimization of style element ordering within the head element.
  • a ttm:actor element referencing a ttm:agent element. In this case, Requirement 4 provides optimization of metadata elements ordering within the document.
  • a content element referencing ttm:agent elements using the ttm:agent attribute. In this case, Requirement 4 provides optimization of metadata elements ordering within the document.

6.7.3 itts:forcedDisplay

itts:forcedDisplay can be used to hide content whose computed value of tts:visibility is "visible" when the processor has been configured to do so via the application parameter displayForcedOnlyMode .

If and only if the value of displayForcedOnlyMode is "true" , a content element with a itts:forcedDisplay computed value of "false" SHALL NOT produce any visible rendering, but still affect layout, regardless of the computed value of tts:visibility .

The itts:forcedDisplay attribute has no effect on content layout or composition, but merely determines whether composed content is visible or not.

The itts:forcedDisplay attribute SHALL conform to the following:

Values: false | true
Initial: false
Applies to: body , div , p , region , span
Inherited: yes
Percentages: N/A
Animatable: discrete

Annex C. Forced content (non-normative) illustrates the use of itts:forcedDisplay in an application in which a single document contains both hard of hearing captions and translated foreign language subtitles, using itts:forcedDisplay to display translation subtitles always, independently of whether the hard of hearing captions are displayed or hidden.

The presentation processor SHALL accept an optional boolean parameter called displayForcedOnlyMode , whose value MAY be set by a context external to the presentation processor . If not set, the value of displayForcedOnlyMode SHALL be assumed to be equal to "false" .

The algorithm for setting the displayForcedOnlyMode parameter based on the circumstances under which the Document Instance is presented is left to the application.

Example 4
<?xml version="1.0" encoding="UTF-8"?> </ tt >

Note

As specified in [ TTML1 ], the background of a region can be visible even if the computed value of tts:visibility equals "hidden" for all active content within. The background of a region for which itts:forcedDisplay equals "true" can therefore remain visible even if itts:forcedDisplay equals "false" for all active content elements within the region and displayForcedOnlyMode equals "true" . Authors can avoid this situation, for instance, by ensuring that content elements and the regions that they are flowed into always have the same value of itts:forcedDisplay .

Note

Although itts:forcedDisplay , like all the TTML style attributes, has no defined semantics on a br content element, itts:forcedDisplay will apply to a br content element if it is either defined on an ancestor content element of the br content element or it is applied to a region element corresponding to a region that the br content element is being flowed into.

Note

It is expected that the functionality of itts:forcedDisplay will be mapped to a conditional style construct in a future revision of this specification.

Note

The presentation semantics associated with itts:forcedDisplay are intended to be compatible with those associated with the forcedDisplayMode attribute defined in [ CFF ].

6.7.4 ittm:altText

ittm:altText allows an author to provide a text string equivalent for an element, typically an image. This text equivalent MAY be used to support indexing of the content and also facilitate quality checking of the document during authoring.

The ittm:altText element SHALL conform to the following syntax:

<ittm:altText
  xml:id = ID
  xml:lang = string
  xml:space = (default|preserve)
  {

  {any attribute not in the default namespace, any TT namespace or any IMSC namespace}>

  Content: #PCDATA
</ittm:altText>

The ittm:altText element SHALL be a child of the metadata element.

8. Image Profile Constraints specifies the use of the ittm:altText element with images.

Example 5
<?xml version="1.0" encoding="UTF-8"?> </ tt >

Note

In contrast to the common use of alt attributes in [ HTML5 ], the ittm:altText attribute content is not intended to be displayed in place of the element if the element is not loaded. The ittm:altText attribute content can however be read and used by assistive technologies.

6.7.5 ittp:activeArea

The Active Area of a Document Instance is the area within the root container Root Container Region that the author intends to be minimally visible to the viewer. This area typically fully contains all of the referenced regions within the Document Instance .

Note

Under normal circumstances, the entirety of the root container Root Container Region is presented. However, under special circumstances, such as when the related video object is cropped, a system can, for instance, use the ittp:activeArea parameter to avoid cropping areas of the root container Root Container Region that are intended to be visible to the viewer. The specific behavior of the system is however left undefined intentionally: the system can select a presentation mode appropriate to the display shape, user preferences, etc. The ittp:activeArea is analogous to the Active Format Description (AFD) metadata commonly used in broadcast applications.

The Active Area is specified using the ittp:activeArea attribute.

If present, the ittp:activeArea attribute SHALL conform to the following syntax:

ittp:activeArea
ittp:activeArea
  : leftOffset topOffset width height
  
leftOffset | topOffset | width | height
  : <percentage>                // where <percentage> is non-negative and not greater than 100%.

The width percentage value is relative to the width of the root container. Root Container Region .

The height percentage value is relative to the height of the root container. Root Container Region .

The width and height percentage values are the width and height of the Active Area .

The leftOffset and topOffset percentage values specify an alignment point between the root container and the Active Area .

The origin top left {x, y} percentage coordinates of the Active Area SHALL be calculated as follows:

x = leftOffset * (1 - width/100)
x = leftOffset * (1 - width/100)
y = topOffset * (1 - height/100)
          
Note

The use of left and top offset positions is co-incident with the [ css3-background ] background-position property where a two percentage value position is used.

Note

The syntax of the ittp:activeArea parameter is such that the Active Area SHALL NOT cannot extend outside the root container Root Container Region in any dimension.

The ittp:activeArea attribute is considered to be significant only when specified on the tt element.

If the ittp:activeArea attribute is not specified, the Active Area SHALL be the root container. Root Container Region .

Example 6
<?xml version="1.0" encoding="UTF-8"?> </ tt >

6.7.6 itts:fillLineGap

The itts:fillLineGap attribute allows the author to control the application of background between successive line areas.

If itts:fillLineGap="true" then the background of each inline area generated by descendant spans of the p element SHALL extend to the before-edge and after-edge of its containing line area ( before-edge and after-edge are defined at Section 4.2.3 of [ XSL11 ]).

The itts:fillLineGap attribute SHALL conform to the following:

Values: false | true
Initial: false
Applies to: p
Inherited: yes
Percentages: N/A
Animatable: discrete

In the following example, the p specifies itts:fillLineGap="true" , and, as a result, no gap exists between its lines.

Example 7
<?xml version="1.0" encoding="UTF-8"?> </ tt >

itts:fillLineGap rendering example 1
Figure 1 Illustrative rendition of the example immediately above with itts:fillLineGap="true" removed (left) or preserved (right). Blue lines have been added to show the before-edge and after-edge of each line area, which are coincident for successive line areas.

Also, as illustrated in the following example, because the line areas of successive p elements are contiguous, no gap exists between two successive p elements where itts:fillLineGap="true" .

Example 8
itts:fillLineGap rendering example 2
Figure 2 Illustrative rendition of the example immediately above, where itts:fillLineGap="true" on the two paragraphs of the top region, itts:fillLineGap="false" on the two paragraphs of the bottom region.

6.8 Region

6.8.1 Presented Region

A presented region is a temporally active region that satisfies the following conditions:

  1. the computed value of tts:opacity is not equal to "0.0" ; and
  2. the computed value of tts:display is not "none" ; and
  3. the computed value of tts:visibility is not "hidden" ; and
  4. either (a) content is selected into the region or (b) the computed value of tts:showBackground is equal to "always" and the computed value of tts:backgroundColor has non-transparent alpha.

6.8.2 Dimensions and Position

All regions SHALL NOT extend beyond the root container, Root Container Region , i.e. every coordinate in the set of coordinates of each region is also in the set of coordinates of the root container. Root Container Region .

No two presented regions in a given intermediate synchronic document SHALL overlap, i.e. the intersection of the sets of coordinates within each presented region is empty.

6.8.3 Maximum number

The number of presented regions in a given intermediate synchronic document SHALL NOT be greater than 4.

6.9 Profile Signaling

The ttp:profile attribute SHOULD be present on the tt element and equal to the designator of the IMSC1 IMSC 1.0 profile to which the Document Instance conforms, and the ttp:profile element SHOULD NOT be present, unless:

The ttp:profile and ebuttm:conformsToStandard elements SHALL NOT signal conformance to both Image Profile and Text Profile in a given Document Instance .

6.10 Hypothetical Render Model

It SHALL be possible to apply the Hypothetical Render Model specified in Section 9. Hypothetical Render Model to any sequence of consecutive intermediate synchronic documents without error as defined in Section 9.2 General .

6.11 Features and Extensions

See 4. Conformance for a definition of permitted , prohibited and optional .

Feature Disposition Additional provision
Relative to the TT Feature namespace
#animation permitted
#backgroundColor-block permitted
#backgroundColor-region permitted
#cellResolution permitted If the Document Instance includes any length value that uses the c expression, ttp:cellResolution SHOULD be present on the tt element.
#clockMode prohibited
#clockMode-gps prohibited
#clockMode-local prohibited
#clockMode-utc prohibited
#core permitted
#display-block permitted
#display-inline permitted
#display-region permitted
#display permitted
#dropMode prohibited
#dropMode-dropNTSC prohibited
#dropMode-dropPAL prohibited
#dropMode-nonDrop prohibited
#extent-root permitted If the Document Instance includes any length value that uses the px expression, tts:extent SHALL be present on the tt element.
#extent permitted
#frameRate permitted If the Document Instance includes any clock time expression that uses the frames term or any offset time expression that uses the f metric, the ttp:frameRate attribute SHALL be present on the tt element.
#frameRateMultiplier permitted
#layout permitted
#length-cell permitted c units SHALL NOT be present outside of the value of ebutts:linePadding .
#length-integer permitted
#length-negative prohibited
#length-percentage permitted
#length-pixel permitted
#length-positive permitted
#length-real permitted
#length permitted
#markerMode prohibited
#markerMode-continuous prohibited
#markerMode-discontinuous prohibited
#metadata permitted
#opacity permitted
#origin permitted
#overflow permitted
#overflow-visible permitted
#pixelAspectRatio prohibited
#presentation permitted See constraints applied to #profile.
#profile permitted See 6.9 Profile Signaling .
#showBackground permitted
#structure permitted
#styling-chained permitted
#styling-inheritance-content permitted
#styling-inheritance-region permitted
#styling-inline permitted
#styling-nested permitted
#styling-referential permitted
#styling permitted
#subFrameRate prohibited
#tickRate permitted ttp:tickRate SHALL be present on the tt element if the document contains any time expression that uses the t metric.
#timeBase-clock prohibited
#timeBase-media permitted

NOTE: [ TTML1 ] specifies that the default timebase is "media" if ttp:timeBase is not specified on tt .

#timeBase-smpte prohibited
#time-clock-with-frames permitted
#time-clock permitted
#time-offset-with-frames permitted
#time-offset-with-ticks permitted
#time-offset permitted
#timeContainer permitted
#timing permitted
  • All time expressions within a Document Instance SHOULD use the same syntax, either clock-time or offset-time .
  • For any content element that contains br elements or text nodes or a smpte:backgroundImage attribute, both the begin attribute and one of either the end or dur attributes SHOULD be specified on the content element or at least one of its ancestors.
#transformation permitted See constraints at #profile .
#visibility-block permitted
#visibility-region permitted
#writingMode-horizontal-lr permitted
#writingMode-horizontal-rl permitted
#writingMode-horizontal permitted
#zIndex permitted NOTE: While permitted, this feature has no effect since, as specified at 6.8.2 Dimensions and Position , regions do not overlap in a Document Instance .
Extension Disposition Provisions
Relative to the IMSC 1.0 Extension namespace
#aspectRatio permitted
#forcedDisplay permitted
#progressivelyDecodable permitted
#altText permitted
#activeArea optional NOTE: This feature is optional such that a processor that conforms to the earlier version of this specification also conforms to this version.
Note

As specified in [ TTML1 ], a #time-offset-with-frames expression is translated to a media time M according to M = 3600 · hours + 60 · minutes + seconds + (frames ÷ ( ttp:frameRateMultiplier · ttp:frameRate )).

6.12 Style Resolution

The following style properties are subject to the Style Resolution procedures specified at Section 8.4 of [ TTML1 ]:

7. Text Profile Constraints

7.1 Profile Designator

This profile is associated with the following profile designator:

Profile Name Profile Designator
IMSC 1.0 Text http://www.w3.org/ns/ttml/profile/imsc1/text
Note

As specified in 6.11 Features and Extensions , the presence of the ttp:profile attribute is not required by this profile. The profile designator specified above is intended to be generally used to signal conformance of a Document Instance to the profile. The details of such signaling depends on the application, and can, for instance, use metadata structures out-of-band of the Document Instance .

7.3 Reference Fonts

When rendering codepoints matching one of the combinations of computed font family and codepoints listed in A. Reference Fonts , a processor SHALL use a font that generates a glyph sequence whose dimension is substantially identical to the glyph sequence that would have been generated by one of the specified reference fonts.

Note

This clause only applies to codepoints supported by the processor. See 7.2 Recommended Character Sets for codepoints that a processor is likely to encounter for various languages.

Note

When a content author sets a bounding box for a subtitle, they want to maximize the likelihood that the text will fit within it when displayed by the processor. If the processor doesn't use the specific font the content author had in mind, the font actually used might cause the text to grow in size so that it no longer fits in the bounding box. This is further compounded by differences in the way text wraps when a font has bigger glyphs, which might increase the number of lines used, and increased line spacing, which might also push some of the text outside the bounding box.
To help ensure that things such as text size, line breaking, and line height behave as expected relative to the size of the bounding box set by the content author, the author can use one of the reference fonts defined by this specification. This specification requires processors to support one or more fonts with similar font metrics as reference fonts. Note that, however, the reference fonts as currently defined only cover characters used for a few writing systems – in particular, a subset of those based on Latin, Greek, Cyrillic, Hebrew, and Arabic scripts.

Note

Implementations can use fonts other than those specified in A. Reference Fonts . Two fonts with equal metrics can have a different appearance, but flow identically.

7.4 Features and Extensions

See 4. Conformance for a definition of permitted , prohibited and optional .

Feature Disposition Additional provisions
Relative to the TT Feature namespace
#backgroundColor-inline permitted
#backgroundColor permitted
#bidi permitted
#content permitted
#color permitted

The initial value of tts:color SHALL be "white" .

NOTE 1: This is consistent with [ ST2052-1 ].

NOTE 2: The named color "green" defined in [ TTML1 ] is equivalent to the RGB triplet #008000 and is not full luminance. For full luminance green, an author can specify the RGB triplet #00ff00ff or the named color "lime" .

#direction permitted
#displayAlign permitted
#extent-region permitted The tts:extent attribute SHALL be present on all region elements, where it SHALL use either px units or "percentage" syntax.
#fontFamily-generic permitted

In absence of specific instructions on the choice of font families, and in order to enhance reproducibility of line fitting, authors are encouraged to use the monospaceSerif or proportionalSansSerif generic font families, for which reference font metrics are defined at A. Reference Fonts .

If the computed value of tts:fontFamily is "default" , then the used value of tts:fontFamily SHALL be "monospaceSerif" .

NOTE: The term used value is defined in CSS 2.1, as normatively referenced by [ TTML1 ].

#fontFamily-non-generic permitted
#fontFamily permitted

Linear white-space SHOULD NOT appear between components of the specified value of tts:fontFamily .

#fontSize-anamorphic prohibited
#fontSize-isomorphic permitted
#fontSize See individual disposition of #fontSize-anamorphic and #fontSize-isomorphic .
#fontStyle-italic permitted
#fontStyle-oblique permitted
#fontStyle permitted
#fontWeight-bold permitted
#fontWeight permitted
#length-em permitted
#lineBreak-uax14 The processor SHALL implement the #lineBreak-uax14 feature defined in the TT Feature namespace.
#lineHeight permitted As implementation of the "normal" value is not uniform at the time of this writing, tts:lineHeight SHOULD NOT be set to "normal" and SHOULD be explicitly specified such that the specified style set of each p element contains a tts:lineHeight property whose value is not assigned by initial value fallback.
#nested-div permitted
#nested-span permitted
#origin permitted The tts:origin attribute SHALL use px units or "percentage" representation, and SHALL NOT use em units.
#padding-1 permitted
#padding-2 permitted
#padding-3 permitted
#padding-4 permitted
#padding permitted
#textAlign-absolute permitted
#textAlign-relative permitted
#textAlign permitted
#textDecoration-over permitted
#textDecoration-through permitted
#textDecoration-under permitted
#textDecoration permitted
#textOutline-blurred prohibited
#textOutline-unblurred permitted
#textOutline permitted The computed value of tts:textOutline on a span element SHALL be 10% or less than the computed value of tts:fontSize on the same element.
#unicodeBidi permitted
#visibility permitted
#visibility-inline permitted
#wrapOption permitted
#writingMode permitted
#writingMode-vertical permitted
Extension Disposition Provisions
Relative to the SMPTE-TT Extension Namespace
#image prohibited
Relative to the IMSC 1.0 Extension namespace
#linePadding permitted

If used, the attribute ebutts:linePadding MAY be specified on elements region , body , div and p in addition to style .

The processor :

  • SHALL apply ebutts:linePadding to p only; and
  • SHALL treat ebutts:linePadding as inheritable.

NOTE: The ebutts:linePadding attribute only supports c length units.

#multiRowAlign permitted

If used, the attribute ebutts:multiRowAlign MAY be specified on elements region , body , div and p in addition to style

The processor :

  • SHALL apply ebutts:multiRowAlign to p only; and
  • SHALL treat ebutts:multiRowAlign as inheritable.
#fillLineGap optional NOTE: This feature is optional such that a processor that conforms to the earlier version of this specification also conforms to this version.
Note

In contrast to this specification, [ EBU-TT-D ] specifies that the attributes ebutts:linePadding and ebutts:multiRowAlign are allowed only on the style element.

8. Image Profile Constraints

8.1 Profile Designator

This profile is associated with the following profile designator:

Profile Name Profile Designator
IMSC 1.0 Image http://www.w3.org/ns/ttml/profile/imsc1/image
Note

As specified in 6.11 Features and Extensions , the presence of the ttp:profile attribute is not required by this profile. The profile designator specified above is intended to be generally used to signal conformance of a Document Instance to the profile. The details of such signaling depends on the application, and can, for instance, use metadata structures out-of-band of the Document Instance .

8.2 Presented Image

8.2.1 Definition

A presented image is a div element with a smpte:backgroundImage attribute that flows into a presented region .

8.2.2 Constraints

In a given intermediate synchronic document , each presented region SHALL contain at most one div element, which SHALL be a presented image .

8.2.3 Intermediate Synchronic Document Construction

For the purposes of constructing an intermediate synchronic document , a div element with a smpte:backgroundImage attribute SHALL NOT be considered empty.

8.3 smpte:backgroundImage Constraints

If a smpte:backgroundImage attribute is applied to a div element:

Note

In [ TTML1 ], tts:extent and tts:origin do not apply to div elements. In order to individually position multiple div elements, each div can be associated with a distinct region with the desired tts:extent and tts:origin .

8.4 Features and Extensions

See 4. Conformance for a definition of permitted , prohibited and optional .

Feature Disposition Additional provisions
Relative to the TT Feature namespace
#backgroundColor-inline prohibited
#backgroundColor See individual disposition of #backgroundColor-inline , #backgroundColor-region and #backgroundColor-block .
#bidi See individual disposition of #direction , #unicodeBidi and #writingMode-horizontal .
#color prohibited
#content permitted The p , span and br elements SHALL NOT be present. See Section 8.2.2 Constraints for constraints on div elements.
#direction prohibited
#displayAlign prohibited
#extent-region permitted The tts:extent attribute SHALL be present on all region elements, where it SHALL use px units.
#fontFamily prohibited
#fontFamily-generic prohibited
#fontFamily-non-generic prohibited
#fontSize prohibited
#fontSize-anamorphic prohibited
#fontSize-isomorphic prohibited
#fontStyle prohibited
#fontStyle-italic prohibited
#fontStyle-oblique prohibited
#fontWeight prohibited
#fontWeight-bold prohibited
#length-em prohibited
#lineBreak-uax14 No processor requirement is specified.
#lineHeight prohibited
#nested-div prohibited
#nested-span prohibited

NOTE: The prohibition of span elements by this profile implies the prohibition of this feature.

#padding prohibited
#padding-1 prohibited
#padding-2 prohibited
#padding-3 prohibited
#padding-4 prohibited
#textAlign prohibited
#textAlign-absolute prohibited
#textAlign-relative prohibited
#textDecoration prohibited
#textDecoration-over prohibited
#textDecoration-through prohibited
#textDecoration-under prohibited
#textOutline prohibited
#textOutline-blurred prohibited
#textOutline-unblurred prohibited
#unicodeBidi prohibited
#visibility See individual disposition of #visibility-inline , #visibility-region and #visibility-block .
#visibility-inline prohibited
#wrapOption prohibited
#writingMode See individual disposition of #writingMode-vertical and #writingMode-horizontal .
#writingMode-vertical prohibited
Extension Disposition Provisions
Relative to the SMPTE-TT Extension namespace
#image permitted
  • smpte:backgroundImage MAY be used according to 8.3 smpte:backgroundImage Constraints with the semantics of the attribute defined by Sections 5.5.2 of [ ST2052-1 ].
  • smpte:backgroundImageHorizontal and smpte:backgroundImageVertical SHALL NOT be used.
  • smpte:image SHALL NOT be used.
Relative to the IMSC 1.0 Extension namespace
#fillLineGap prohibited
Note

The rendering semantics of smpte:backgroundImage are not identical to those of background-image specified at Section 7.8.3 of [ XSL11 ]. In particular, Section 5.5.6 at [ ST2052-1 ] amends the semantics of background-image by specifying values for its min-height and min-width properties.

9. Hypothetical Render Model

9.1 Overview (non-normative)

This Section specifies the Hypothetical Render Model illustrated in Figure 2 3 Hypothetical Render Model .

The purpose of the model is to limit Document Instance complexity. It is not intended as a specification of the processing requirements for implementations. For instance, while the model defines a glyph buffer for the purpose of limiting the number of glyphs displayed at any given point in time, it neither requires the implementation of such a buffer, nor models the sub-pixel character positioning and anti-aliased glyph rendering that can be used to produce text output.

Hypothetical Render Model
Figure 2 3 Hypothetical Render Model

The model operates on successive intermediate synchronic documents obtained from an input Document Instance , and uses a simple double buffering model: while an intermediate synchronic document E n is being painted into Presentation Buffer P n (the "front buffer" of the model), the previous intermediate synchronic document E n-1 is available for display in Presentation Buffer P n-1 (the "back buffer" of the model).

The model specifies an (hypothetical) time required for completely painting an intermediate synchronic document as a proxy for complexity. Painting includes drawing region backgrounds, rendering and copying glyphs, and decoding and copying images. Complexity is then limited by requiring that painting of intermediate synchronic document E n completes before the end of intermediate synchronic document E n-1 .

Whenever applicable, constraints are specified relative to root container dimensions, the dimensions of the Root Container Region , allowing subtitle sequences to be authored independently of Related Video Object resolution.

To enable scenarios where the same glyphs are used in multiple successive intermediate synchronic documents , e.g. to convey a CEA-608/708-style roll-up (see [ CEA-608 ] and [ CEA-708 ]), the Glyph Buffers G n and G n-1 store rendered glyphs across intermediate synchronic documents , allowing glyphs to be copied into the Presentation Buffer instead of rendered, a more costly operation.

Similarly, Decoded Image Buffers D n and D n-1 store decoded images across intermediate synchronic documents , allowing images to be copied into the Presentation Buffer instead of decoded.

9.2 General

The Presentation Compositor SHALL render in Presentation Buffer P n each successive intermediate synchronic document E n using the following steps in order:

  1. clear the pixels, except for the first intermediate synchronic document E 0 for the which the pixels of P 0 SHALL be assumed to have been cleared;
  2. paint, according to stacking order, all background pixels for each region;
  3. paint all pixels for background colors associated with text or image subtitle content; and
  4. paint the text or image subtitle content.

The Presentation Compositor SHALL start rendering E n :

The duration DUR(E n ) for painting an intermediate synchronic document E n in the Presentation Buffer P n SHALL be:

DUR(E n ) = S(E n ) / BDraw + DUR T (E n ) + DUR I (E n )

where

The contents of the Presentation Buffer P n SHALL be transferred instantaneously to Presentation Buffer P n-1 at the presentation time of intermediate synchronic document E n , making the latter available for display.

Note

It is possible for the contents of Presentation Buffer P n-1 to never be displayed. This can happen if Presentation Buffer P n is copied twice to Presentation Buffer P n-1 between two consecutive video frame boundaries of the Related Video Object .

It SHALL be an error for the Presentation Compositor to fail to complete painting pixels for E n before the presentation time of E n .

Unless specified otherwise, the following table SHALL specify values for IPD and BDraw.

Parameter Initial value
Initial Painting Delay (IPD) 1 s
Normalized background drawing performance factor (BDraw) 12 s -1
Note

BDraw effectively sets a limit on fillings regions - for example, assuming that the root container Root Container Region is ultimately rendered at 1920×1080 resolution, a BDraw of 12 s -1 would correspond to a fill rate of 1920×1080×12/s=23.7×2 20 pixels s -1 .

Note

IPD effectively sets a limit on the complexity of any given intermediate synchronic document .

9.3 Paint Regions

The total normalized drawing area S(E n ) for intermediate synchronic document E n SHALL be

S(E n ) = CLEAR(E n ) + PAINT(E n )

where CLEAR(E 0 ) = 0 and CLEAR(E n | n > 0 ) = 1, i.e. the root container Root Container Region in its entirety.

Note

To ensure consistency of the Presentation Buffer, a new intermediate synchronic document requires clearing of the root container. Root Container Region .

PAINT(E n ) SHALL be the normalized area to be painted for all regions that are used in intermediate synchronic document E n according to:

PAINT(E n ) = ∑ R i ∈R p NSIZE(R i ) ∙ NBG(R i )

where R_p SHALL be the set of presented regions in the intermediate synchronic document E n .

NSIZE(R i ) SHALL be given by:

NSIZE(R i ) = (width of R i ∙ height of R i ) ÷ (root container ( Root Container Region height ∙ root container Root Container Region width)

NBG(R i ) SHALL be the total number of tts:backgroundColor attributes associated with the given region R i in the intermediate synchronic document . A tts:backgroundColor attribute is associated with a region when it is explicitly specified (either as an attribute in the element, or by reference to a declared style) in the following circumstances:

Even if a specified tts:backgroundColor is the same as specified on the nearest ancestor content element or animation element, specifying any tts:backgroundColor SHALL require an additional fill operation for all region pixels.

9.4 Paint Images

The Presentation Compositor SHALL paint into the Presentation Buffer P n all visible pixels of presented images of intermediate synchronic document E n .

For each presented image , the Presentation Compositor SHALL either:

Two images SHALL be identical if and only if they reference the same encoded image source.

The duration DUR I (E n ) for painting images of an intermediate synchronic document E n in the Presentation Buffer SHALL be as follows:

DUR I (E n ) = ∑ I i ∈ I c NRGA(I i ) / ICpy + ∑ I j ∈ I d NSIZ(I j ) / IDec

where

NRGA(I i ) is the Normalized Image Area of presented image I i and SHALL be equal to:

NRGA(I i )= (width of I i ∙ height of I i ) ÷ ( root container Root Container Region height ∙ root container Root Container Region width )

NSIZ(I i ) SHALL be the number of pixels of presented image I i .

The contents of the Decoded Image Buffer D n SHALL be transferred instantaneously to Decoded Image Buffer D n-1 at the presentation time of intermediate synchronic document E n .

The total size occupied by images stored in Decoded Image Buffers D n or D n-1 SHALL be the sum of their Normalized Image Area.

The size of Decoded Image Buffers D n or D n-1 SHALL be the Normalized Decoded Image Buffer Size (NDIBS).

Unless specified otherwise, the following table SHALL specify ICpy, IDec, and NDBIS.

Parameter Initial value
Normalized image copy performance factor (ICpy) 6
Image Decoding rate (IDec) 1 × 2 20 pixels s -1
Normalized Decoded Image Buffer Size (NDIBS) 0.9885

9.5 Paint Text

In the context of this section, a glyph is a tuple consisting of (i) one character and (ii) the computed values of the following style properties:

Note

While one-to-one mapping between characters and typographical glyphs is generally the rule in some scripts, e.g. latin script, it is the exception in others. For instance, in arabic script, a character can yield multiple glyphs depending on its position in a word. The Hypothetical Render Model always assumes a one-to-one mapping, but reduces the performance of the glyph buffer for scripts where one-to-one mapping is not the general rule (see GCpy below).

For each glyph associated with a character in a presented region of intermediate synchronic document E n , the Presentation Compositor SHALL :

Example of Presentation Compositor Behavior for Text Rendering
Figure 3 4 Example of Presentation Compositor Behavior for Text Rendering

The duration DUR T (E n ) for rendering the text of an intermediate synchronic document E n in the Presentation Buffer is as follows:

DUR T (E n ) = ∑ g i ∈ Γ r NRGA(g i ) / Ren(g i ) + ∑ g j ∈ Γ c NRGA(g j ) / GCpy

where

The Normalized Rendered Glyph Area NRGA(g i ) of a glyph g i SHALL be equal to:

NRGA(g i ) = (fontSize of g i as percentage of root container Root Container Region height) 2

Note

NRGA(G i ) does not take into account decorations (e.g. underline), effects (e.g. outline) or actual typographical glyph aspect ratio. An implementation can determine an actual buffer size needs based on worst-case glyph size complexity.

The contents of the Glyph Buffer G n SHALL be copied instantaneously to Glyph Buffer G n-1 at the presentation time of intermediate synchronic document E n .

It SHALL be an error for the sum of NRGA(g i ) over all glyphs Glyph Buffer G n to be larger than the Normalized Glyph Buffer Size (NGBS).

Unless specified otherwise, the following table specifies values of GCpy, Ren and NGBS.

Normalized glyph copy performance factor (GCpy)
Script property (see Standard Annex #24 at [ UNICODE ]) for the character of g i GCpy
latin, greek, cyrillic, hebrew or common 12
any other value 3
Text rendering performance factor Ren(G i )
Block property (see [ UNICODE ]) for the character of g i Ren(G i )
CJK Unified Ideograph 0.6
any other value 1.2
Normalized Glyph Buffer Size (NGBS)
1
Note

The choice of font by the presentation processor can increase rendering complexity. For instance, a cursive font can generally result in a given character yielding different typographical glyphs depending on context, even if latin script is used.

A. Reference Fonts

Computed Font Family Code Points Reference Font
monospaceSerif All code points specified in B. Recommended Character Sets Courier New or Liberation Mono
proportionalSansSerif All code points specified in B. Recommended Character Sets , excluding the code points defined for Hebrew and Arabic scripts. Arial or Helvetica or Liberation Sans

C. Forced content (non-normative)

Figure 4 5 Illustration of the use of itts:forcedDisplay below illustrates the use of forced content, i.e. itts:forcedDisplay and displayForcedOnlyMode . The content with itts:forcedDisplay="true" is the French translation of the "High School" sign. The content with itts:forcedDisplay="false" are French subtitles capturing a voiceover.

Illustration of the use of itts:forcedDisplay
Figure 4 5 Illustration of the use of itts:forcedDisplay

When the user selects French as the playback language but does not select French subtitles, displayForcedOnlyMode is set to "true" , causing the display of the sign translation, which is useful to any French speaker, but hiding the voiceover subtitles as the voiceover is heard in French.

If the user selects French as the playback language and also selects French subtitles, e.g. if the user is hard-of-hearing, displayForcedOnlyMode is set to "false" , causing the display of both the sign translation and the voiceover subtitles.

The algorithm for setting the displayForcedOnlyMode parameter and selecting the appropriate combination of subtitle and audio tracks depends on the application.

D. WCAG Considerations

In order to meet the guidelines in [ WCAG20 ], the following considerations apply.

Guideline 1.1 of [ WCAG20 ] recommends that an implementation provide Text Alternatives for all non-text content. In the context of this specification, this Text Alternative is intended primarily to support users of the subtitles who cannot see images. Since the images of an Image Profile Document Instance usually represent subtitle or caption text, the guidelines for authoring text equivalent strings given at Images of text of [ HTML5 ] are appropriate.

Thus, for each subtitle in an Image Profile Document Instance , a text equivalent content in a Text Profile Document Instance SHOULD be written so that it conveys all essential content and fulfills the same function as the corresponding subtitle image. In the context of subtitling and captioning, this content will be (as a minimum) the verbatim equivalent of the image without précis or summarization. However, the author MAY include extra information to the text equivalent string in cases where styling is applied to the text image with a deliberate connotation, as a functional replacement for the applied style.

For instance, in subtitling and captioning, italics can be used to indicate an off screen speaker context (for example a voice from a radio). An author can choose to include this functional information in the text equivalent; for example, by including the word "Radio: " before the image equivalent text. Note that images in an Image Profile Document Instance that are intended for use as captions , i.e. intended for a hard of hearing audience, might already include this functional information in the rendered text.

Guideline 1.1 of [ WCAG20 ] also recommends that accessible Text Alternatives must be "programmatically determinable." This means that the text must be able to be read and used by the assistive technologies (and the accessibility features in browsers) that people with disabilities use. It also means that the user must be able to use their assistive technology to find the alternative text (that they can use) when they land on the non-text content (that they can't use).

E. Sample Document Instance (non-normative)

The following sample Document Instances conforms to the Text Profile and Image Profile , respectively. These samples are for illustration only, and are neither intended to capture current or future practice, nor exercise all normative prose contained in this specification.

Example 12 13
?> </ tt >

Example 13 14
<?xml version="1.0" encoding="UTF-8"?> </ tt >

F. Extensions

F.1 General

The following sections define extension designations, expressed as relative URIs (fragment identifiers) relative to the IMSC 1.0 Extension Namespace base URI.

F.2 #progressivelyDecodable

A transformation processor supports the #progressivelyDecodable feature if it recognizes and is capable of transforming values of the ittp:progressivelyDecodable .

A presentation processor supports the #progressivelyDecodable feature if it implements presentation semantic support for values of the ittp:progressivelyDecodable attribute.

F.3 #aspectRatio

A transformation processor supports the #aspectRatio feature if it recognizes and is capable of transforming values of the ittp:aspectRatio .

A presentation processor supports the #aspectRatio feature if it implements presentation semantic support for values of the ittp:aspectRatio attribute.

F.4 #forcedDisplay

A transformation processor supports the #forcedDisplay feature if it recognizes and is capable of transforming values of the itts:forcedDisplay .

A presentation processor supports the #forcedDisplay feature if it implements presentation semantic support for values of the itts:forcedDisplay attribute.

F.5 #altText

A transformation processor supports the #altText feature if it recognizes and is capable of transforming values of the ittm:altText element.

A presentation processor supports the #altText feature if it implements presentation semantic support for values of the ittm:altText element.

F.6 #linePadding

A transformation processor supports the #linePadding feature if it recognizes and is capable of transforming values of the ebutts:linePadding attribute specified in [ EBU-TT-D ].

A presentation processor supports the #linePadding feature if it implements presentation semantic support for values of the ebutts:linePadding attribute specified in [ EBU-TT-D ].

F.7 #multiRowAlign

A transformation processor supports the #multiRowAlign feature if it recognizes and is capable of transforming values of the ebutts:multiRowAlign attribute specified in [ EBU-TT-D ].

A presentation processor supports the #multiRowAlign feature if it implements presentation semantic support for values of the ebutts:multiRowAlign attribute specified in [ EBU-TT-D ].

F.8 #activeArea

A transformation processor supports the #activeArea feature if it recognizes and is capable of transforming values of the ittp:activeArea attribute.

A presentation processor supports the #activeArea feature if it implements presentation semantic support for values of the ittp:activeArea attribute.

F.9 #fillLineGap

A transformation processor supports the #fillLineGap feature if it recognizes and is capable of transforming values of the itts:fillLineGap attribute.

A presentation processor supports the #fillLineGap feature if it implements presentation semantic support for values of the itts:fillLineGap attribute.

G. XML Schema Definitions (non-normative)

XML Schema definitions (see [ xmlschema-1 ]) for extension vocabulary defined by this specification are provided here for convenience.

These definitions are non-normative and are not sufficient to validate conformance of a Document Instance .

In any case where a definition specified by this appendix diverge from the prose of the specification, then the latter takes precedence.

H. Extensibility Objectives (non-normative)

This section documents extensibility objectives for this specification.

This specification is intended to allow:

I. Compatibility with other TTML-based specifications (non-normative)

I.1 Overview

This specification is designed to be compatible with [ ST2052-1 ], [ EBU-TT-D ] and [ ttml10-sdp-us ]. Specifically, it is possible to create a document that:

This specification is also intended to allow straightforward conversion of a document that conforms to the text or image profiles of [ CFF ] to the Text Profile or Image Profile, respectively.

I.2 EBU-TT-D

The Text Profile is a strict syntactic superset of [ EBU-TT-D ].

A document that conforms to [ EBU-TT-D ] therefore generally also conforms to the Text Profile, with a few exceptions, including:

The ttp:profile attribute and element are not allowed by [ EBU-TT-D ]. The ebuttm:conformsToStandard element is used instead, as discussed at 6.9 Profile Signaling .

It is not possible for a document that conforms to [ EBU-TT-D ] to also conform to Image Profile, and vice-versa, notwithstanding the special case where the document also conforms to Text Profile as noted at 5. Profiles .

The following is an example of a document that conforms to both Text Profile and [ EBU-TT-D ]. Note the presence of two ebuttm:conformsToStandard elements, one of which equals the Text Profile designator:

Example 14 15
<?xml version="1.0" encoding="UTF-8"?> multiRowAlign="end"textAlign="start" multiRowAlign="start"textAlign="center" </ tt >

I.3 SDP-US

The Text Profile is a strict syntactic superset of [ ttml10-sdp-us ].

A document that conforms to [ ttml10-sdp-us ] therefore also generally conforms to the Text Profile, with a few exceptions, including:

[ ttml10-sdp-us ] requires a specific value of the use attribute of the ttp:profile . As a result, Text Profile is not signaled using the ttp:profile attribute. Instead, as specified in 5.4 Profile Resolution Semantics , the Text Profile can be signaled by the Document Interchange Context and/or the Document Processing Context. Alternatively, a processor can choose to process a document as a Text Profile document if the ttp:profile element signals [ ttml10-sdp-us ], since [ ttml10-sdp-us ] is feasibly interoperable with Text Profile.

It is not possible for a document that conforms to [ ttml10-sdp-us ] to also conform to Image Profile, and vice-versa, notwithstanding the special case where the document also conforms to Text Profile as noted at 5. Profiles .

As an illustration, Example 3 at [ ttml10-sdp-us ] conforms to both Text Profile and [ ttml10-sdp-us ].

I.4 SMPTE-TT (SMPTE ST 2052-1)

[ ST2052-1 ] specifies the use of the DFXP Full Profile (see Appendix F.3 at [ TTML1 ]) supplemented by a number of extensions, including http://www.smpte-ra.org/schemas/2052-1/2010/smpte-tt#image .

This specification defines practical constraints on [ ST2052-1 ], supplemented by a few extensions defined at F. Extensions . These constraints and extensions are intended to reflect industry practice.

As a result, particular care is required when creating a document intended to be processed according to both [ ST2052-1 ] and Text Profile or Image Profile. In particular:

The following is an example of a document that conforms to both Text Profile and [ ST2052-1 ]:

Example 15 16
?> </ tt >

I.5 CFF-TT

This specification was derived from the text and image profiles specified in Section 6 at [ CFF ], and is intended to be a superset in terms of capabilities. Additional processing is however generally necessary to convert a document from [ CFF ] to this specification. In particular:

J. Acknowledgements (non-normative)

The editor acknowledges the current and former members of the Timed Text Working Group, the members of other W3C Working Groups, and industry experts in other forums who have contributed directly or indirectly to the process or content of this document.

The editor wishes to especially acknowledge the following contributions by members: Glenn Adams, Skynav; John Birch, Invited expert; Mike Dolan, Invited expert; Nigel Megitt, British Broadcasting Corporation; Thierry Michel, W3C ; Andreas Tai, Institut für Rundfunktechnik.

The editor also wishes to acknowledge Digital Entertainment Content Ecosystem (DECE) for contributing to the initial document for the Member Submission.

K. Privacy and Security Considerations (non-normative)

TTML security

The security and privacy considerations of [ rfc3023 ] and [ TTML1 ] apply, particularly in relation to document parsing. XML Entities are excluded from the Reduced XML Infoset of TTML and are therefore not considered part of Document Instances ; nevertheless implementations are encouraged to provide protection against recursive entity expansion or prevent entity expansion altogether in processors.

Privacy of preference

A user agent that selects, and causes to download or interpret a Document Instance , might indicate to the origin server that the user has a need for captions or subtitles, and also the language preference of the user for captions or subtitles. That is a small piece of information about the user. However, the offering of a Document Instance , and the choice whether to retrieve and consume it, are characteristics of the application that makes the offer (e.g. a web application based on [ HTML ]), rather than of the Document Instance itself.

The Image Profile includes a mechanism for referencing external images. A user agent that downloads external images during media playback indicates to the origin server of the images the progress of the user's media consumption. In many cases such media progress information is available to the origin server of the media via other mechanisms, for example by scripting or by monitoring streaming media requests.

User agents that do not enforce cross origin policies when downloading external images expose such media progress information and potentially other user tracking information to other origins without the consent of the web site serving the media and without the consent of the user. This specification defines no APIs and makes no statement on how implementations are expected to obtain referenced images.

L. References

L.1 Normative references

[CLDR]
Unicode Consortium. The Common Locale Data Repository Project
[EBU-TT-D]
European Broadcasting Union (EBU). Tech 3380, EBU-TT-D Subtitling Distribution Format Version 1.0
[PNG]
Portable Network Graphics (PNG) Specification (Second Edition) . Tom Lane. W3C. 10 November 2003. W3C Recommendation. URL: https://www.w3.org/TR/PNG https://www.w3.org/TR/PNG/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels . S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[ST2052-1]
SMPTE ST 2052-1, Timed Text Format (SMPTE-TT) URL: https://www.smpte.org/standards
[TTML1]
Timed Text Markup Language 1 (TTML1) (Second Edition) . Glenn Adams. W3C. 24 September 2013. W3C Recommendation. URL: https://www.w3.org/TR/ttml1/
[UNICODE]
The Unicode Standard . Unicode Consortium. URL: http://www.unicode.org/versions/latest/ https://www.unicode.org/versions/latest/
[WCAG20]
Web Content Accessibility Guidelines (WCAG) 2.0 . Ben Caldwell; Michael Cooper; Loretta Guarino Reid; Gregg Vanderheiden et al. W3C. 11 December 2008. W3C Recommendation. URL: https://www.w3.org/TR/WCAG20/
[xml-names]
Namespaces in XML 1.0 (Third Edition) . Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin; Henry Thompson et al. W3C. 8 December 2009. W3C Recommendation. URL: https://www.w3.org/TR/xml-names https://www.w3.org/TR/xml-names/

L.2 Informative references

[CEA-608]
Consumer Technology Association. CTA 608-E, Line-21 Data Services .
[CEA-708]
Consumer Technology Association. CTA 708-D, Digital Television (DTV) Closed Captioning .
[CFF]
Digital Entertainment Content Ecosystem (DECE). Common File Format & Media Formats Specification (CFF) Version 2.2 .
[css3-background]
CSS Backgrounds and Borders Module Level 3 . Bert Bos; Elika Etemad; Brad Kemper. W3C. 17 October 2017. W3C Candidate Recommendation. URL: https://www.w3.org/TR/css-backgrounds-3/
[HTML]
HTML Standard . Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[HTML5]
HTML5 . Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. W3C. 28 October 2014. W3C Recommendation. URL: https://www.w3.org/TR/html5/
[IMSC1]
World Wide Web Consortium (W3C) Recommendation. TTML Profiles for Internet Media Subtitles and Captions 1.0 (IMSC1) (21 April 2016). [SUBM] World Wide Web Consortium (W3C). TTML Text and Image Profiles for Internet Media Subtitles and Captions (Member Submission, 07 June 2013) [XSL11] Extensible Stylesheet Language (XSL) Version 1.1 . Anders Berglund. W3C. 5 December 2006. W3C Recommendation. URL: https://www.w3.org/TR/xsl11/ [css3-background] CSS Backgrounds and Borders Module Level 3 . Bert Bos; Elika Etemad; Brad Kemper. W3C. 9 September 2014. W3C Candidate Recommendation. URL: https://www.w3.org/TR/css3-background/
[namespaceState]
The Disposition of Names in an XML Namespace . Norman Walsh. W3C. 29 March 2006. W3C Working Draft. URL: https://www.w3.org/TR/namespaceState/
[rfc3023]
XML Media Types . M. Murata; S. St. Laurent; D. Kohn. IETF. January 2001. Proposed Standard. URL: https://tools.ietf.org/html/rfc3023
[SUBM]
World Wide Web Consortium (W3C). TTML Text and Image Profiles for Internet Media Subtitles and Captions (Member Submission, 07 June 2013)
[ttml10-sdp-us]
TTML Simple Delivery Profile for Closed Captions (US) . Glenn Adams; Monica Martin; Sean Hayes. W3C. 5 February 2013. W3C Note. URL: https://www.w3.org/TR/ttml10-sdp-us/
[xmlschema-1]
XML Schema Part 1: Structures Second Edition . Henry Thompson; David Beech; Murray Maloney; Noah Mendelsohn et al. W3C. 28 October 2004. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema-1/
[XSL11]
Extensible Stylesheet Language (XSL) Version 1.1 . Anders Berglund. W3C. 5 December 2006. W3C Recommendation. URL: https://www.w3.org/TR/xsl11/