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

W3C Recommendation 21 April 2016

Note: On 26 January 2017, this specification was modified in place to replace the broken link to the editor's draft.
On 23 June 2017, this specification was modified in place to update the IMSC1 schema for a broken link to the SMPTE-TT schemas.

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].

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 http://www.w3.org/TR/.

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

1. Scope

This document specifies 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].

2. Documentation Conventions

This specification uses the same conventions as [TTML1] for the specification of parameter attributes, styling attributes and metadata elements. In particular, Section 2.3 of [TTML1] specifies conventions used in the XML representation of elements.

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]:

when making reference to content conformance,
these designations refer to the syntactic expression or the semantic
capability associated with each designated Feature or
Extension; and

when making reference to processor
conformance, these designations refer to processing
requirements associated with each designated Feature or
Extension.

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

MAY include any vocabulary, syntax or attribute value associated with a Feature or
Extension whose disposition is permitted in the profile;

SHALL NOT include any vocabulary, syntax or attribute value associated with a Feature or Extension
whose disposition is prohibited in the profile.

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.

SHALL implement presentation semantic support for every Feature and Extension designated as permitted by the profile, subject to
any additional constraints on each Feature and Extension as specified by the profile.

SHALL implement transformation semantic support for every Feature and Extension designated as permitted by the profile, subject to
any additional constraints on each Feature and Extension as specified by the profile.

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 ProfileDocument InstanceSHOULD be associated with the Image ProfileDocument 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.4ittm: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.

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.

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.

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

the ratio of the width to the height of the rectangular area is equal to ittp:aspectRatio,

the center of the rectangular area is collocated with the center of the image frame,

the rectangular area is entirely within the image frame, and

the rectangular area has a height or width equal to that of the image frame.

Otherwise, the root container of a Document InstanceSHALL 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.

Example 2

Region with xml:id="A" in the following document would be positioned 20% from the left edge of an image frame with an aspect ratio of 16:9,
or 10% from the left edge of an image frame with an aspect ratio of 4:3.

In other words, tts:extent, when present on the tt element, determines the size of "px" units relative to the root container. ttp:aspectRatio is independently used to map the root container to each image frame of the Related Video Object.

Note

The ittp:aspectRatio parameter effectively defines the intended display aspect ratio (DAR) of the root container, while
the tts:extent style property on the root element effectively defines the intended storage aspect ratio (SAR) of the root container.

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 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 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 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 to the video frame, maintaining relative positioning
between caption/subtitles and video elements but at the risk of clipping subtitles/captions.

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 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 processorSHALL 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
displayForcedOnlyModeSHALL 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.

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.

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.8 Region

6.8.1 Presented Region

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

the computed value of tts:opacity is not equal to "0.0"; and

the computed value of tts:display is not "none"; and

the computed value of tts:visibility is not "hidden"; and

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, i.e. the intersection of the sets of coordinates belonging to a
region and the sets of coordinates belonging to the root container is the
set of coordinates belonging to the region.

6.8.3 Maximum number

6.9 Profile Signaling

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

the Document Instance also conforms to [EBU-TT-D], in which case the ttp:profile attribute
and the ttp:profile element SHOULD NOT be present, and instead the designator of the IMSC1 profile to which the Document Instance conforms and
the URI "urn:ebu:tt:distribution:2014-01"SHOULD each be carried in an ebuttm:conformsToStandard element as specified in
[EBU-TT-D]; or

the Document Instance also conforms to [ttml10-sdp-us], in which case the ttp:profile attribute SHOULD NOT be present. [ttml10-sdp-us] requires that the ttp:profile element be present and that its use attribute be set to a specified value.

If the Document Instance includes any length value that uses the c expression,
ttp:cellResolutionSHOULD 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:extentSHALL 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.

ttp:tickRateSHALL 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 InstanceSHOULD 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, the begin and end attributes SHOULD
be specified on the content element or at least one of its ancestors.

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.11Features 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.2 Recommended Character Sets

7.3 Reference Fonts

The flow of text within a region depends the dimensions and spacing (kerning) between individual glyphs.
The following allows, for instance, region extents to be set such that text flows without clipping.

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

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.

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:fontFamilySHALL be "monospaceSerif".

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

The processorSHALL 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:lineHeightSHOULD 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:linePaddingMAY be specified on elements region, body,
div and p in addition to style.

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.11Features 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.3 Intermediate Synchronic Document Construction

8.3 smpte:backgroundImage Constraints

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

the width and height (in pixels) of the image source referenced by smpte:backgroundImageSHALL be equal
to the width and height (as specified by the tts:extent attribute using px units) of the region in which the
div element is presented;

the div element SHOULD contain a metadata element containing an ittm:altText element that is a Text Alternative of the image referenced by the smpte:backgroundImage attribute; and

The smpte:backgroundImage attribute SHALL reference a PNG datastream as specified in [PNG]. If a pHYs chunk is present, it SHALL indicate square pixels. Note that if no pixel aspect ratio is carried, the default of square pixels is assumed.

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.

9. Hypothetical Render Model

9.1 Overview (non-normative)

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.

The contents of the Presentation Buffer PnSHALL be transferred instantaneously to Presentation Buffer
Pn-1 at the presentation time of intermediate synchronic document En, making the latter
available for display.

Note

It is possible for the contents of Presentation Buffer Pn-1 to never be displayed. This can
happen if Presentation Buffer Pn is copied twice to Presentation Buffer Pn-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 En before the
presentation time of En.

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 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×220pixels s-1.

For a region Ri in with tts:extent="250px 50px" within a root container with
tts:extent="1920px 1080px", NSIZE(Ri) = 0.603.

NBG(Ri) SHALL be the total number of tts:backgroundColor attributes associated with the given
region Ri 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:

it is specified on the region layout element that defines the region; or

it is specified on a div, p, span or br content element that is
to be flowed into the region for presentation in the intermediate synchronic document (see [TTML1] for more
details on when a content element is followed into a region); or

it is specified on a set animation element that is to be applied to content elements that are to be
flowed into the region for presentation in the intermediate synchronic document (see [TTML1] for more details
on when a set animation element is applied to content elements).

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

if an identical image is present in Decoded Image Buffer Dn, copy the image from Decoded Image Buffer
Dn to the Presentation Buffer Pn using the Image Copier; or

if an identical image is present in Decoded Image Buffer Dn-1, i.e. an identical image was present in
intermediate synchronic document En-1, copy using the Image Copier the image from Decoded Image Buffer
Dn-1 to both the Decoded Image Buffer Dn and the Presentation Buffer Pn; or

otherwise, decode the image using the Image Decoder the image into the Presentation Buffer Pn and Decoded
Image Buffer Dn.

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

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:

tts:color

tts:fontFamily

tts:fontSize

tts:fontStyle

tts:fontWeight

tts:textDecoration

tts:textOutline

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).

if an identical glyph is present in Glyph Buffer Gn, copy the glyph from Glyph Buffer Gn to the
Presentation Buffer Pn using the Glyph Copier; or

if an identical glyph is present in Glyph Buffer Gn-1, i.e. an identical glyph was present in intermediate
synchronic document En-1, copy using the Glyph Copier the glyph from Glyph Buffer Gn-1 to both the
Glyph Buffer Gn and the Presentation Buffer Pn; or

otherwise render using the Glyph Renderer the glyph into the Presentation Buffer Pn and Glyph Buffer
Gn.

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.

Example 7

Setting a Normalized Glyph Buffer Size effectively sets a limit on the total number of distinct glyphs present in any
given intermediate synchronic document En. For example, assuming a maximum Normalized Glyph Buffer Size
of 1 and the default tts:fontSize of 1c are used, the font size relative to the root container height is 1/15 , and
the maximum number of distinct glyphs that can be buffered is 1÷(1÷15)2=225 glyphs.

Example 8

GCpy effectively sets a limit on animating text. For example, assuming that the root container is ultimately rendered
at 1920×1080 resolution and no regions need to have background color painted (so only a CLEAR(En) operation
is required for the normalized drawing area for the intermediate synchronic document), a GCpy and BDraw of 12 s-1
would mean that a group of 160 glyphs with a tts:fontSize equal to 5% of the root container height could be moved at most
approximately 12 s-1 ÷ (1 + ( 160 × 0.052 )) = 8.6 times per second.

Example 9

Ren(Gi) effectively sets a limit on the text rendering rate. For example, assuming that the root container is
ultimately rendered at a 1920×1080 resolution, a Ren(Gi) of 1.2 s-1 would mean that at most 120 glyphs with a
fontSize of 108 px (10% of 1080 px and NRGA(Gi) = 0.01) could be rendered every second.

B. Recommended Character Sets

When authoring textual content, authors are encouraged to select from sets of characters based on the language indicated
using xml:lang. The idea is to increase the confidence that the text will be presented correctly by
implementations targeting specific locales.

Specifically, for a given language, an author SHOULD choose characters from the set resulting from the union of the
following sets:

the main exemplar character set specified for the language in [CLDR] as well as any corresponding uppercase characters as specified in [UNICODE]; and

the punctuation exemplar character set specified for the language in [CLDR];

the digits and symbols included in all numberSystems specified for the language in [CLDR];

the common character set specified in Table 1; and

supplementary characters specified for the language in Table 2, if any.

Some of these sets overlap.

Table 1 captures the set of characters intended to be available to authors across all languages. The terms used in the table
are defined in [UNICODE].

Table 1. Common Character Set.

(Basic Latin)

U+0020 - U+007E

(Latin-1 Supplement)

U+00A0 - U+00FF

(Latin Extended-A)

U+0152 : LATIN CAPITAL LIGATURE OE

U+0153 : LATIN SMALL LIGATURE OE

U+0160 : LATIN CAPITAL LETTER S WITH CARON

U+0161 : LATIN SMALL LETTER S WITH CARON

U+0178 : LATIN CAPITAL LETTER Y WITH DIAERESIS

U+017D : LATIN CAPITAL LETTER Z WITH CARON

U+017E : LATIN SMALL LETTER Z WITH CARON

(Latin Extended-B)

U+0192 : LATIN SMALL LETTER F WITH HOOK

(Spacing Modifier Letters)

U+02DC : SMALL TILDE

(Combining Diacritical Marks)

U+0301 : COMBINING ACUTE ACCENT

(General Punctuation)

U+2010 - U+2015 : Dashes

U+2016 - U+2027 : General punctuation

U+2030 - U+203A : General punctuation

(Currency symbols)

U+20AC : EURO SIGN

(Letterlike Symbols)

U+2103 : DEGREES CELSIUS

U+2109 : DEGREES FAHRENHEIT

U+2120 : SERVICE MARK SIGN

U+2122 : TRADE MARK SIGN

(Number Forms)

U+2153 - U+215F : Fractions

(Mathematical Operators)

U+2212 : MINUS SIGN

U+221E : INFINITY

(Box Drawing)

U+2500 : BOX DRAWINGS LIGHT HORIZONTAL

U+2502 : BOX DRAWINGS LIGHT VERTICAL

U+250C : BOX DRAWINGS LIGHT DOWN AND RIGHT

U+2510 : BOX DRAWINGS LIGHT DOWN AND LEFT

U+2514 : BOX DRAWINGS LIGHT UP AND RIGHT

U+2518 : BOX DRAWINGS LIGHT UP AND LEFT

(Block Elements)

U+2588 : FULL BLOCK

(Geometric Shapes)

U+25A1 : WHITE SQUARE

(Musical Symbols)

U+2669 : QUARTER NOTE

U+266A : EIGHTH NOTE

U+266B : BEAMED EIGHTH NOTES

Table 2 specifies supplementary character set that have proven useful in captioning and subtitling applications for a number
of selected languages. Table 2 is non-exhaustive, and will be extended as needs arise.

C. Forced content (non-normative)

Fig. 3
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.

Fig. 3
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 ProfileDocument 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 ProfileDocument Instance, a text equivalent content in a Text ProfileDocument InstanceSHOULD 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 ProfileDocument 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.

G. XML Schema Definitions (non-normative)

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:

other profiles of TTML and future revisions of this specification to specify support for documents and/or processors conforming to Text Profile or Image Profile, in addition to specifying additional extensions;

subject to the structural requirements of [TTML1], content from external namespaces to be present in a document that conforms to Text Profile or Image Profile (a) without affecting transformation or presentation, and (b) to be carried through by a transformation processor (see 6.2Foreign Element and Attributes);

a document that conforms to Text Profile or Image Profile to be embedded in other XML documents.

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:

Note that the ttp:profile attribute is not allowed by [EBU-TT-D], and the ebuttm:conformsToStandard element is used instead to signal Text Profile, as specified in 6.9Profile 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:

[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.4Profile 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.

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:

in contrast to Text Profile and Image Profile, [ST2052-1] allows documents to contain both smpte:backgroundImage attributes and any of p, span, or br elements;

Image Profile allows only a subset of the http://www.smpte-ra.org/schemas/2052-1/2010/smpte-tt#image extension;

[ST2052-1] does not support the #aspectRatio, #forcedDisplay,
#linePadding and #multiRowAlign extensions that impact presentation; and

when the designator "http://www.smpte-ra.org/schemas/2052-1/2010/profiles/smpte-tt-full" is used as a value for ttp:profile element or attribute (see Section 5.8 at [ST2052-1]), Text Profile or Image Profile is signaled by the Document Interchange Context and/or the Document Processing Context.

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

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:

the namespace of the progressivelyDecodable attribute is different;

the forcedDisplayMode attribute in [CFF] is renamed to
forcedDisplay in this specification;