Abstract

This document specifies the Timed Text Markup Language (TTML), Version 2, also known as TTML2,
in terms of a vocabulary and semantics thereof.

The Timed Text Markup Language is a content type that represents
timed text media for the purpose of interchange among authoring
systems. Timed text is textual information that is intrinsically or
extrinsically associated with timing information.

It is intended to be used
for the purpose of transcoding or exchanging timed text information
among legacy distribution content formats presently in use for
subtitling and captioning functions.

In addition to being used for interchange among legacy distribution content
formats, TTML Content may be used directly as a distribution format,
for example, providing a standard content format to reference from a <track>
element in an HTML5 document, or a <text> or
<textstream> media element in a [SMIL 3.0] document.

1 Introduction

Unless specified otherwise, this section and its sub-sections are non-normative.

The Timed Text Markup Language (TTML), Version 2, also referred to as TTML2,
provides a standardized representation of a particular subset of
textual information with which stylistic, layout, and timing semantics are associated by
an author or an authoring system for the purpose of interchange and processing.

TTML is expressly designed to meet only a limited set of requirements
established by [TTAF1-REQ], and summarized in L Requirements. In particular, only those requirements which service the
need of performing interchange with existing, legacy distribution systems are
satisfied.

In addition to being used for interchange among legacy distribution content
formats, TTML Content may be used directly as a distribution format, providing, for
example, a standard content format to reference from a <track>
element in an HTML5 document, or a <text> or
<textstream> media element in a [SMIL 3.0] document. Certain properties of TTML support
streamability of content, as described in O Streaming TTML Content.

Note:

While TTML is not expressly designed for direct (embedded) integration into an
HTML or a SMIL document instance, such integration is not precluded.

Note:

In some contexts of use, it may be appropriate to employ
animated content to depict sign language representations of the same content
as expressed by a Timed Text document instance. This use case is not
explicitly addressed by TTML mechanisms, but may be addressed by some
external multimedia integration technology, such as SMIL.

Note:

In previous drafts of this specification, TTML was referred to as DFXP (Distribution
Format Exchange Profile). This latter term is retained for historical reasons in
certain contexts, such as profile names and designators, and the short name
ttaf1-dfxp used in URLs to refer to this specification.

1.1 System Model

Use of TTML is intended to function in a wider context of Timed Text
Authoring and Distribution mechanisms that are based upon the system
model depicted in Figure 1 – System Model, wherein the Timed Text Markup Language
serves as a bidirectional interchange format among a heterogeneous collection of
authoring systems, and as a unidirectional interchange format to a
heterogeneous collection of distribution formats after undergoing transcoding
or compilation to the target distribution formats as required, and where one
particular distribution format is TTML (labeled as "DFXP" in the figure).

Figure 1 – System Model

Editorial note: Revise System Model

2014-11-27

Update system model diagram to reflect current and expected usage. Eliminate reference to DFXP.

1.2 Document Example

A TTML document instance consists of a tt document element that contains
a header and a body, where the header specifies document level metadata, styling
definitions and layout definitions, and the body specifies text content intermixed
with references to style and layout information and inline styling and timing information.

Layout information defines one or more regions into which content
is intended to be presented. A region definition may reference one or
more sets of style specifications in order to permit content flowed in the
region to inherit from these styles.
In Example Fragment – TTML Layout, the region definition makes
reference to style specification s1 augmented by specific inline
styles which, together, allow content flowed into the region to inherit
from the region's styles (in the case
that a style is not already explicitly specified on content or inherited
via the content hierarchy.)

The content of a document instance is expressed in its
body, which is organized in terms of block and inline text elements.
The hierarchical organization of content elements serves a primary role in
determining both spatial and temporal relationships. For example, in
Example Fragment – TTML Body, each paragraph (p element)
is flowed into its target region in the specified lexical order; furthermore,
the active time interval of each paragraph is timed in accordance to its
parent or sibling according to the applicable time containment semantics —
in this case, the division parent is interpreted (by default) as a parallel time
container.

Example Fragment – TTML Body

<body region="subtitleArea">
<div>
<p xml:id="subtitle1" begin="0.76s" end="3.45s">
It seems a paradox, does it not,
</p>
<p xml:id="subtitle2" begin="5.0s" end="10.0s">
that the image formed on<br/>
the Retina should be inverted?
</p>
<p xml:id="subtitle3" begin="10.0s" end="16.0s" style="s2">
It is puzzling, why is it<br/>
we do not see things upside-down?
</p>
<p xml:id="subtitle4" begin="17.2s" end="23.0s">
You have never heard the Theory,<br/>
then, that the Brain also is inverted?
</p>
<p xml:id="subtitle5" begin="23.0s" end="27.0s" style="s2">
No indeed! What a beautiful fact!
</p>
<p xml:id="subtitle6a" begin="28.0s" end="34.6s" style="s2Left">
But how is it proved?
</p>
<p xml:id="subtitle6b" begin="28.0s" end="34.6s" style="s1Right">
Thus: what we call
</p>
<p xml:id="subtitle7" begin="34.6s" end="45.0s" style="s1Right">
the vertex of the Brain<br/>
is really its base
</p>
<p xml:id="subtitle8" begin="45.0s" end="52.0s" style="s1Right">
and what we call its base<br/>
is really its vertex,
</p>
<p xml:id="subtitle9a" begin="53.5s" end="58.7s">
it is simply a question of nomenclature.
</p>
<p xml:id="subtitle9b" begin="53.5s" end="58.7s" style="s2">
How truly delightful!
</p>
</div>
</body>

The first subtitle Subtitle 1 – Time Interval [0.76, 3.45) is
presented during the time interval 0.76 to 3.45 seconds.
This
subtitle inherits its font family, font size,
foreground color, and text alignment from the region into which it is
presented. Since no region is explicitly specified on the paragraph,
the nearest ancestor that specifies a region determines the
targeted region. Note also that content is presented
at the bottom (after edge) of the containing region due to the tts:displayAlign="after"
being specified on the region definition.

Note:

The notation "[X,Y]" denotes a closed
interval from X to Y, including
X and Y;
"[X,Y)" denotes a right half-open
interval from X to Y, including
X but not including Y;
"(X,Y]" denotes a left half-open
interval from X to Y, not including
X but including Y;
"(X,Y)" denotes an open
interval from X to Y, not including
X or Y.

Note:

In this example, the p element is used as a presentational
element rather than as a semantic element, i.e., as a linguistic paragraph.
It is up to an author to determine which TTML elements are used to convey
the intended meaning. For instance, this example could be written to use
timing on span elements in order to preserve the integrity of
semantic paragraphs.

Subtitle 1 – Time Interval [0.76, 3.45)

The second subtitle continues with the default style, except that it contains
two lines of text with an intervening author-specified line break. Note the effects of
the use of tts:textAlign="center" to specify the paragraph's alignment
in the inline progression direction.

Subtitle 2 – Time Interval [5.0, 10.0)

The third subtitle continues, using a variant style which overrides the default style's
foreground color with a different color.

Subtitle 3 – Time Interval [10.0, 16.0)

The fourth subtitle reverts to the default style.

Subtitle 4 – Time Interval [17.2, 23.0)

The fifth subtitle continues, again using a variant style which
overrides the default style's foreground color with a different color.

Subtitle 5 – Time Interval [23.0, 27.0)

During the next active time interval, two distinct subtitles are simultaneously active, with
the paragraphs expressing each subtitle using different styles that override color and paragraph
text alignment of the default style. Note that the flow order is determined by the lexical
order of elements as they appear in the content hierarchy.

Subtitles 6a and 6b – Time Interval [28.0, 34.6)

The next subtitle is specified in a similar manner using
a style override to give the paragraph right (end) justification in the
inline progression direction.

Subtitle 7 – Time Interval [34.6, 45.0)

The eighth subtitle uses the same style override as the previous
subtitle in order to maintain the right (end) justification of the
paragraph.

Subtitle 8 – Time Interval [47.3, 49.0)

During the final (ninth) active time interval, two distinct
subtitles are again simultaneously active, but with a different
style applied to the second paragraph to override the default color.
Note that the flow order is determined by the lexical order of
elements as they appear in the content hierarchy.

Subtitles 9a and 9b – Time Interval [53.5, 58.7)

The examples shown above demonstrate the primary types of information that may
be authored using TTML: metadata, styling, layout, timing, and content. In typical cases,
styling and layout information are separately specified in a document instance. Content information
is expressed in a hierarchical fashion that embodies the organization of both spatial (flow) and
timing information. Content makes direct or indirect references to styling and layout information
and may specify inline overrides to styling.

The context in which an audio element is specified for the
purpose of being presented (rendered). Such an audio element
may specify the audio data inline by using a data element within
a source element child, or it may reference another
audio element specified in a
audio defining context, or it may do both.

A profile referenced by the use attribute of a ttp:profile element,
which serves as a baseline (initial) set of specifications with which to populate the referencing profile.

[block display]

Block display is a set of layout semantics that may be applied to a content element in
certain contexts, wherein child areas are composed sequentially in the block progression direction. In [CSS2],
block display is indicated when a CSS display property with the value block is applied to a
content element during presentation processing. In [XSL 1.1], a block display
occurs when composing a fo:block element.

[character information item]

Each data character appearing in an XML document corresponds with a character information
item as defined by [XML InfoSet], §2.6.

The size (extent) of a cell computed by dividing the width of the root container region
by the column count, i.e., the number of cells in the horizontal axis, and by dividing
the height of the root container region by the row count, i.e., the number of cells in the vertical
axis, where the column and row counts are determined by the ttp:cellResolution parameter attribute.

The context in which an data element is specified for the
purpose of semantic binding (association). Such a data element
may specify the data inline by using a data element within
a source element child, or it may reference another
data element specified in a
data defining context, or it may do both. No presentation (rendering)
semantics are implied by the mere presence of a data element in this (or any) context.

The context in which an data element is specified to serve as
a sharable definition to be referenced by another data element
in an data binding context, namely, a
data element the parent of which is a
resources element.

An arbitrary data resource represented or referenced using a data element. For example,
a data resource may be used to embed or refer to an audio clip, a font, an image, or arbitrary application data in a
timed text content document instance.

A default out-of-line region that is implied in the absence of
an explicitly specified out-of-line region element, i.e.,
when no region element is specified as a child of
a layout element.

[designated profile]

A profile that is associated with a profile designator by
means of a designator attribute or prose text in a specification of profile.

[display aspect ratio]

The ratio between the horizontal dimension and vertical dimension of a displayed image, video frame,
viewport or region, display device, etc. Equal to the product of storage aspect ratio
and pixel aspect ratio.

[display region target]

A viewport targeted to a rectangular region of a display device, i.e., not in full-screen mode.

[display target]

A viewport targeted to a display device as a whole, i.e., in full-screen mode.

The implied context or environment external to a content processor in
which document interchange occurs, and in which out-of-band protocols or specifications
may define certain behavioral defaults, such as an implied profile.

[document processing context]

The implied context or environment internal to a content processor in
which document processing occurs, and in which out-of-band protocols or specifications
may define certain behavioral defaults, such as the establishment or creation of a
synthetic document syncbase.

[dot pitch]

Depending upon display device technology, the distance between holes in the shadow mask, the distance between wires in the aperture grill,
the distance between sub-pixels of the same color, etc.

A syntactic or semantic expression or capability that is defined and
labeled (using a feature designation) in this specification (or a past or
future revision of this specification).

[feature specification]

A specification of a constraint or requirement that relates to an
feature, typically expressed by
an ttp:feature element.

[forced subtitle]

A subtitle (or caption) that is intended to always be displayed even if subtitles (captions) are not enabled. Forced subtitles (captions)
are used to prevent open captioning of, i.e., burning in, subtitles (captions) related to foreign or alien language or translation of text
that appears in media, such as in a sign.

[font defining context]

The context in which a font element is specified to serve as
a sharable definition to be referenced indirectly by a font selection process.

[font selection process]

An internal process used by a presentation processor which purpose is to select
a set of author defined fonts and platform fonts for use during layout and presentation processing, where input parameters to this
process include the computed values of font related properties, the capabilities of individual fonts, and the text content being presented.

[font resource]

A data resource that contains font information, such as character to glyph mapping data, glyph outlines or images,
glyph metrics, and other data used in the character to glyph mapping and rendering process.

[fragment identifier]

A syntactic expression that adheres to the fragment identifer syntax defined by [URI],
Section 4.1.

The context in which an image element is specified for the
purpose of being presented (rendered). Such an image element
may specify the image data inline by using a data element within
a source element child, or it may reference another
image element specified in a
image defining context, or it may do both.

Inline block display is a set of layout semantics that may be applied to a content element in
certain contexts, wherein a generated block area is treated as an an atomic area to be composed in an inline layout context, i.e., the block
area is treated as if it were itself an inline area when considered externally, but as a block area which considered internally. In [CSS2],
inline block display is indicated when a CSS display property with the value inline-block is applied to a
content element during presentation processing. In [XSL 1.1], an inline block display
occurs when block content appears in an inline content context, e.g., when a fo:block appears as a child of fo:inline.

[inline display]

Inline display is a set of layout semantics that may be applied to a content element in
certain contexts, wherein child areas are composed sequentially in the inline progression direction. In [CSS2],
inline display is indicated when a CSS display property with the value inline is applied to a
content element during presentation processing. In [XSL 1.1], an inline display
occurs when composing a fo:inline element.

[inline region]

A region that is defined in an inline manner with respect to some
content element to be selected into (targeted to) the region.
An inline region is specified either explicitly by a region element child of
a content element or implicitly by specifying a tts:extent
or tts:origin style attribute on a content element.
There is a one-to-one relation between an inline region element and its
parent content element. An inline region is assigned its parent element's time interval as its active
time interval. No region attribute makes reference to an inline region.

A profile defined by making reference to one or more child ttp:profile element(s), wherein a
profile combination method determines how profile specifications from the multiple child ttp:profile element(s) are combined.

An image resource that does not contain semantically significant content, e.g., a raster image
representing a background design, which, if not presented, would not affect the presentation of semntically significant content.

A profile defined without making reference to one or more child ttp:profile element(s); that is,
by including only child ttp:features and ttp:extensions element(s).

[out-of-line animation]

An animate or set element that is defined out-of-line from
the content element or region element associated with the animation.
An out-of-line animation appears as a child of an animation element in the header
(head element)
of a document instance, and specifies an xml:id attribute
which value is referenced by an animate attribute
on the associated element to be animated. There is a one-to-many relation between
a referenced out-of-line animation element and referencing content elements and
region elements.

The ratio between the horizontal dimension and vertical dimension of a displayed pixel. Note that the dimensions of a display pixel may or may not
correspond to the dot pitch of the display device on which it is rendered.

A logical construct that models authorial intention regarding
desired or potential presentation processing, and which is represented as
a rectangular area of a presentation surface into which content
is composed and rendered during presentation processing.

A (possibly null) media object associated with or otherwise related
to a document instance. For example, an aggregate audio/video media
object for which a document instance provides caption or subtitle
information, and with which that document instance is associated.

[related media object region]

When a non-null related media object exists, the region of this media object,
expressed in the coordinate system that applies to the document instance that is associated with the
related media object.

A syntactic or semantic feature, e.g., an element or the presentation of an element, is
temporally active when the current time of selected time base intersects with the
active time interval of the feature.

A profile defined by a ttp:profile element that appears as a child
of the head element.

[transformation processor]

A content processor which purpose is to transform or otherwise rewrite
Timed Text Markup Language content to either Timed Text Markup Language
or to another (arbitrary) content format. An example of the first is a processor that removes
or rewrites TTML features so as to conform to a profile of TTML. An example of the latter is
a processor that translates TTML into a completely different timed text format. Because this
specification does not otherwise define a target profile or format for transformation processing,
no further transformation semantics are defined by this specification.

[undesignated profile]

A profile that is not associated with a profile designator, and which is
referred to implicitly in the context of the profile's definition. Also referred to as an anonymous profile.

A logical, rectangular area with respect to which content is encoded or decoded for the purpose of presentation, where such area
may be employed by or for the authoring or presentation of a related media object or
the root container region and its constituent regions.

Conforming documents and/or TTML processors are required
to behave as described; otherwise, they are in error.

If normative specification language takes an imperative form,
then it is to be treated as if the term must
applies. Furthermore, if normative language takes a declarative form,
and this language is governed by must,
then it is also to be treated as if the term must
applies.

Note:

For example, the phrases "treat X as an error" and "consider X
as an error" are to be read as mandatory requirements in the context of use. Similarly, if the specification
prose is "X must apply", "X applies", or "X is mandatory", and "X" is further defined as "X is Y and Z",
then, by transitive closure, this last declarative phrase is to be read as "Y is mandatory" and
"Z is mandatory" in the context of use.

All normative syntactic definitions of XML representations and
other related terms are depicted with a light yellow-orange background color
and labeled as "XML Representation" or "Syntax Representation", such
as in the following:

In an XML representation, bold-face attribute names (e.g. count above) indicate a required attribute
information item, and the rest are optional. Where an attribute
information item has an enumerated type definition, the values are
shown separated by vertical bars, as for size above; if
there is a default value, it is shown following a colon. Where an
attribute information item has a built-in simple type definition
defined in [XML Schema Part 2], a hyperlink to its definition
therein is given.

In an XML representation, the expression {any attribute not in default or any TT namespace} applies
only to namespace qualified attributes; unqualified attributes are not permitted unless explicitly defined in this specification.

An information item depicted with a light yellow orange background color is deprecated (e.g.,
the tiny value of the size attribute shown above).
An information item that is deprecated may but should not appear in a TTML document instance,
and a validating processor should report a warning if it does appear.
An information item depicted with a light magenta red background color is obsoleted (e.g.,
the micro value of the size attribute shown above).
An information item that is obsoleted must not appear in a TTML document instance,
and a validating processor should report an error if it does appear.
These designations of an item
are also explicitly called out in specification text.

The allowed content of the information item is shown as a grammar
fragment, using the Kleene operators ?, *
and +. Each element name therein is a hyperlink to its
own illustration.

The term linear white-space (LWSP) is to be interpreted as a non-empty sequence of
SPACE (U+0020), TAB (U+0009), CARRIAGE RETURN (U+000D), or LINE FEED (U+000A),
which corresponds to production [3] S as defined by [XML 1.0].

Unless stated to the contrary, the terms horizontal and vertical are interpreted in an absolute sense, not relative to writing mode, while
width refers to a dimension along the horizontal axis and
height refers to a dimension along the vertical axis. All exceptions are explicitly noted in the text.

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.

All paragraphs marked as a Note are considered non-normative.

Example code fragments are depicted with a light blue-green
background color and labeled as "Example Fragment", such as in
the following:

The reduced xml infoset satisfies all additional mandatory syntactic and
semantic constraints defined by this specification. In addition, this infoset
should satisfy the web content accessibility guidelines specified by
[WCAG].

The processor does not a priori reject or abort the
processing of a conformant document instance
unless the processor does not support some required
(mandatory) feature specified or implied by a TTML profile
declared to apply to the document instance.

The processor supports all mandatory processing semantics defined by this specification.

Note:

The phrase mandatory semantics refers to all explicit use of the conformance
key phrases must and must not as well as any
declarative statement that can be reasonably inferred from such key phrases. For example, these
mandatory semantics include support for all features marked as mandatory in E.2 Feature Support.

If the processor supports some optional processing semantics defined by this specification,
then it does so in a manner consistent with the defined semantics.

Note:

The phrase optional semantics refers to all explicit use of the conformance
key phrases should, should not,
may, and may not,
as well as any declarative statement that can be reasonably inferred from such key phrases. For example, these
optional semantics include support for all features marked as optional in E.2 Feature Support.

3.3 Claims

Any claim of compliance with respect to the conformance of a TTML document instance or
content processor must make
reference to an implementation compliance statement (ICS).

An implementation compliance statement must identify all mandatory
and optional features of this specification that are satisfied by the
document instance or the content processor implementation. In particular, the statement must
identify the utilized or supported TTML vocabulary profile(s) as
defined by 5.2 Profiling, and, if a subset or
superset profile is used or supported, then what features are excluded
or included in the subset or superset profile.

A document instance for which a compliance claim is made
must specify
either (1)
a ttp:profile attribute on its root
tt
element
as defined by 6.2.7 ttp:profile
or (2)
a ttp:profile element as a child of the
head element as defined by
6.1.1 ttp:profile. In addition, it must specify a
ttp:version attribute on its root tt element if it requires
support for a feature not defined by [TTML1].

pruning all element information
items whose names are not members of the collection of element types defined
by the associated abstract document type, then

pruning character
information item children from any remaining element in case that all
character children of the element denote XML whitespace characters and the element's type
is defined as empty in the associated abstract document type, and then

pruning all attribute
information items having expanded names such that the namespace URI of the
expanded names are not listed in Table 5-1 – Namespaces,

then the document element is one of the document
element types permitted by the associated abstract document type,
the descendants of the document
element satisfy their respective element type's content
specifications, all required attributes are present, and the declared
value of each attribute satisfies the type declared by the
associated abstract document type.

While a conformant processor may not a priori reject a
conformant document instance, a given document instance may be
constrained by the author or authoring tool to satisfy a more
restrictive definition of validity.

4.1 TTML Content Document Type

The TTML Content Document Type is an abstract document type of a profile
of the Timed Text Markup Language intended to be used for interchange among distribution systems. This document type
is defined in terms of the element and attribute vocabulary specified in 5 Vocabulary.

The schemas referenced by this specification do not validate all syntactic constraints
defined by this specification, and, as such, represent a superset of conformant
TTML Content. In particular, performing validation with one of the above
referenced schemas may result in a false positive indication of validity.
For example, both the RNC and XSD schemas specify
that a tts:fontFamily attribute must
satisfy the xsd:string XSD data type; however, this data type is a superset
of the values permitted to be used with the tts:fontFamily attribute.

In addition, the RNC schema may produce a false negative
indication of validity when using the xml:id attribute with an element in
a foreign namespace, thus representing a subset of conformant TTML Content. This is
due to a specific limitation in expressing wildcard patterns involving xsd:ID
typed attributes in Relax NG schemas. Note that this specification defines the
formal validity of a document instance to be based on an abstract document instance from
which all foreign namespace elements and attributes have been removed. Therefore, the
exceptional reporting of this false negative does not impact the formal assessment
of document instance validity.

4.3 TTML Profile Document Type

The TTML Profile Document Type is an abstract document type intended
to be used for defining and communicating constraints on the support or use of TTML features or extensions. This document type
is defined in terms of the element and attribute vocabulary specified in 5 Vocabulary.

5 Vocabulary

5.1 Namespaces

The Timed Text Markup Language (TTML) employs a number of
XML Namespaces [XML Namespaces 1.0] for elements and certain
global attributes. The following table specifies this set of namespaces
and indicates the default prefix used within this specification and the
normative URI that denotes each namespace.

Note:

In a specific document instance, it is not required that the default
prefixes shown below are used. Any prefix or namespace binding that satisfies the constraints
of XML Namespaces [XML Namespaces 1.0] may be used that is associated with the specified namespace URI.

Table 5-1 – Namespaces

Name

Prefix

Value

TT

tt:

http://www.w3.org/ns/ttml

TT Parameter

ttp:

http://www.w3.org/ns/ttml#parameter

TT Style

tts:

http://www.w3.org/ns/ttml#styling

TT Metadata

ttm:

http://www.w3.org/ns/ttml#metadata

TT Intermediate Synchronic Document

isd:

http://www.w3.org/ns/ttml#isd

TT Profile

none

http://www.w3.org/ns/ttml/profile/

TT Feature

none

http://www.w3.org/ns/ttml/feature/

TT Extension

none

http://www.w3.org/ns/ttml/extension/

Note:

If a reference to an element type is used in this specification and the name
of the element type is not namespace qualified, then the TT Namespace applies.

If a reference to an attribute is used in this specification and the name
of the attribute is not namespace qualified, then the attribute is implicitly qualified by
the element type with which it is used. That is, the attribute resides in the so-called
per-element-type namespace partition[NSOriginal], the members of which are interpreted in accordance with the definition of the element type on which they appear.

For certain namespaces defined above, the default prefix
is specified as none if no XML vocabulary is defined in
the namespace by this specification (nor expected to be defined in a
future version of this specification). In such cases, the use of the
namespace URI is for purposes other than defining XML vocabulary,
e.g., for designating profiles, features, extensions and for
dereferencing standard profile definitions.

All TTML Namespaces are mutable[NSState]; all undefined names in these namespaces are reserved for future
standardization by the W3C.

5.2 Profiling

This section describes the TTML profiling sub-system and high level requirements that apply to this sub-system. At the end of this section
appears a sub-section containing examples of profile specifications and examples of how these specifications are referenced and used.

5.2.1 Introduction

This sub-section is non-normative.

A given profile may be used by a Timed Text Markup Language content author for one of two functions: (1) to declare that a
document instance adheres to a collection of constraints on what
vocabulary is used and how it is used, or (2) to declare that a processor must satisfy certain conditions on how
content is processed. The first of these functions is termed a content profile, while
the second is termed a processor profile.

A content profile is used to allow an author to declare, at authoring time,
what constraints the author intends to apply to a document instance. Such a
declaration permits downstream processors to perform content validation or verification, as well as to guide or limit subsequent
transformation or editing of content in order to maintain adherence to an author specified content profile. In addition, a
downstream processor may use a content profile declaration to perform an early determination of its ability to process the features
implied by the content profile.

Content profiles are declared by using (1) the ttp:contentProfiles
attribute on the root tt element, (2) one or more top-level ttp:profile
elements of type content, or (3) a combination of these two mechanisms. If not declared, no content profile is implied.

A processor profile is used to allow an author to declare, at authoring time,
what processing must be supported when processing a document instance, such that, if a
processor is not able to perform the indicated processing, then processing should be aborted. Such a declaration permits downstream
processors to avoid processing content that cannot be processed in a manner that meets the requirements of the content author.

Processor profiles are declared by using (1) the ttp:processorProfiles
attribute on the root tt element, (2) one or more ttp:profile
elements of type processor, or (3) a combination of these two mechanisms.
If not declared, a processor profile is inferred from a declared content profile or from a
default profile.

Note:

It is not a requirement on a conformant document instance that a processor profile be internally
declared by use of a ttp:profile element or internally referenced by a
ttp:processorProfiles attribute. More specifically, it is
permitted that the document
interchange context determines the applicable processor profile through private
agreement, out-of-band protocol, or common use (between sender and receiver) of a processor profile defined
by an external specification.

Note:

It is intended that the ttp:processorProfiles attribute be used when
the author wishes to reference one (or more) of the standard, predefined processor profiles of
TTML Content, and does not wish to modify (by supersetting or subsetting)
that profile. This attribute may also be used by an author to indicate the use
of a non-standard profile, in which case the specified profile designator expresses
a URI that denotes an externally defined profile definition document.
However, it is not required that a conformant TTML content processor be able
to dereference such an externally specified profile definition.

In contrast, it is intended that the ttp:profile element be
used when the author wishes to make use of a modified predefined profile or
wishes to include in the document instance a non-standard profile definition
not based upon one of the predefined profiles.

A predefined profile is supersetted by specifying some feature or extension to
be required (mandatory) that was either not specified in the underlying, baseline
profile or was specified as optional (voluntary) in the baseline profile.
A predefined profile is subsetted by specifying some feature or extension to
be optional (voluntary) that was specified as required (mandatory)
in the underlying, baseline profile.

When a baseline profile is modified by subsetting, the resulting, derived profile
is referred to as a subtractive profile; when modified by supersetting, the result
is referred to as an additive profile.
It is also possible to define a derived profile that is simultaneously subtractive
and additive.

A content author is not limited to using a single profile, but may make reference to multiple profiles of either type, i.e.,
multiple content profiles and/or multiple processor profiles. When multiple profiles are referenced, their respective specifications
are combined to form a single effective content profile that applies to the document and a single effective processor profile
that applies to a processor when processing the document. In addition, an author is not limited to making reference to externally
defined profiles, but may define one or more profiles inline within a document.

In the above example, the baseline profile is declared to be
the TTML Presentation profile, which is then additively modified by making the
#fontStyle-italic feature required (rather than
optional as it is defined
in G.2 TTML2 Presentation Profile). Note also the resetting of the
default XMLNS binding on the profile element to the TT Parameter Namespace.

5.2.3 Profile Designators

Handle case where a designator refers to an internally defined profile.

A profile is referenced in one of two ways according to whether the profile is defined externally to the referring document or
is defined inline within the referring document. When defined externally, a profile is referenced by means of a
profile designator. When defined internally (inline), a profile is referenced either implicitly
or by means of profile fragment identifier.

Editorial note: Profile Fragment Identifiers.

2014-05-26

Update following to account for use of profile fragment identifier as a profile designator.

A profile designator must adhere to the
xsd:anyURI data type defined by [XML Schema Part 2],
§3.2.17. If the profile designator is expressed as a relative URI,
then it must be absolutized by using the TT Profile Namespace value as
the base URI.

Note:

For example, if a profile designator is expressed as
ttml2-presentation, then the absolutized profile designator
would be
http://www.w3.org/ns/ttml/profile/ttml2-presentation.

All profile designators which have the TT Profile Namespace as a prefix but are otherwise not listed in
Table 5-2 – Profiles are reserved for future standardization, and must not appear in a conformant
document instance. Nothwithstanding this constraint, a profile designator is not restricted to the set of designators enumerated
in Table 5-2 – Profiles, but may be any URI that feasibly dereferences a TTML profile definition document
provided it does not use the TT Profile Namespace as a prefix.

5.2.3.1 Standard Designators

The Timed Text Markup Language (TTML) employs a number of
standard, predefined profiles of its
vocabulary and associated semantics.

The following table specifies this set of
profiles, indicating
a normative name
and designator for each
predefined profile,
and where each of these profiles is formally elaborated in
G Standard Profiles, in [TTML1],
or in another TTWG specification.

Table 5-2 – Profiles

Name

Designator

DFXP Full

http://www.w3.org/ns/ttml/profile/dfxp-full

DFXP Presentation

http://www.w3.org/ns/ttml/profile/dfxp-presentation

DFXP Transformation

http://www.w3.org/ns/ttml/profile/dfxp-transformation

SDP US

http://www.w3.org/ns/ttml/profile/sdp-us

TTML2 Full

http://www.w3.org/ns/ttml/profile/ttml2-full

TTML2 Presentation

http://www.w3.org/ns/ttml/profile/ttml2-presentation

TTML2 Transformation

http://www.w3.org/ns/ttml/profile/ttml2-transformation

Note:

For definitions of the DFXP profiles, see [TTML1]. For definition of the SDP US profile, see [SDP US].

5.2.4 Profile Semantics

5.2.4.1 Profile State Object Concepts

This section defines a number of conceptual state objects used by subsequently defined algorithms (procedures and functions). It is not required that an
implementation create such objects in the form specified here, but may use any convenient, internal representation that represents equivalent information.

if a ttp:contentProfiles attribute is specified on the root tt element, then

if the ttp:contentProfiles attribute is specified using the all(...) function syntax or
using no function syntax, i.e., as only a list of designators, then the
effective content profile is the combined profile specification set
produced by combining the combined profile specification sets of the designated profiles, where the mostRestrictive
content profile combination method applies;

otherwise, if the ttp:contentProfiles attribute is specified using the any(...) function syntax, then the
effective content profile is the combined profile specification set
produced by combining the combined profile specification sets of the designated profiles, where the leastRestrictive
content profile combination method applies;

otherwise, if one or more top-levelcontent profiles
are defined, then the
effective content profile is the combined profile specification set
produced by combining the combined profile specification sets of all such
top-levelcontent profiles, where the
content profile combination method specified by (or the default value of) the ttp:contentProfileCombination
attribute on the root tt element applies;

5.2.4.3 Processor Profile Semantics

for each profile specification S in the combined profile specification set of EPP, perform the following steps:

if the value field of S is required, and the content processor
does not support S, then abort processing of the document instance unless overridden
by the end-user or some implementation specific parameter traceable to an end-user or to a user or system configuration setting;

if a ttp:processorProfiles attribute is specified on the root tt element, then

if the ttp:processorProfiles attribute is specified using the all(...) function syntax or
using no function syntax, i.e., as only a list of designators, then the
effective processor profile is the combined profile specification set
produced by combining the combined profile specification sets of the designated profiles, where the mostRestrictive
processor profile combination method applies;

otherwise, if the ttp:processorProfiles attribute is specified using the any(...) function syntax,
then, for each designated profile, the
effective processor profile is the combined profile specification set
of the first profile in the list of designated profiles that is supported by the
content processor;

otherwise, if one or more top-levelprocessor profiles
are defined, then the
effective processor profile is the combined profile specification set
produced by combining the combined profile specification sets of all such
top-levelprocessor profiles, where the
processor profile combination method specified by (or the default value of) the ttp:processorProfileCombination
attribute on the root tt element applies;

otherwise, if a ttp:profile attribute is specified on the root tt element, then the
effective processor profile is the combined profile specification set
of the profile designated by this attribute;

otherwise, if the computed value of the ttp:inferProcessorProfileSource parameter is first, then
the inferred processor profile is the first inferred processor profile, IPP, produced by applying the
infer processor profile function
to the combined profile specification set of each constituent of ECP such that
IPP is supported by the content processor;

if the ttp:version attribute is not specified on the root tt element or
if the computed value of its parameter property is 1 (one), then the default processor profile is
the profile constructed by interning the DFXP Presentation profile
(http://www.w3.org/ns/ttml/profile/dfxp-presentation);

otherwise,
if the computed value of the ttp:version parameter property is 2 (two),
the default processor profile is
the profile constructed by interning the TTML2 Presentation profile
(http://www.w3.org/ns/ttml/profile/ttml2-presentation);

otherwise,
the default processor profile is
the profile constructed by interning a TTML presentation profile
associated with the computed value of ttp:version,
if one is known, or, if not known, then the most recently defined presentation profile;

if the ttp:version attribute is not specified on the root tt element or
if the computed value of its parameter property is 1 (one), then the default processor profile is
the profile constructed by interning the DFXP Transformation profile
(http://www.w3.org/ns/ttml/profile/dfxp-transformation);

otherwise,
if the computed value of the ttp:version parameter property is 2 (two),
the default processor profile is
the profile constructed by interning the TTML2 Transformation profile
(http://www.w3.org/ns/ttml/profile/ttml2-transformation);

otherwise,
the default processor profile is
the profile constructed by interning a TTML transformation profile
associated with the computed value of ttp:version,
if one is known, or, if not known, then the most recently defined TTML transformation profile;

Note:

A content processor intended to be used with
one or more distinct versions of TTML greater than version 2 (TTML2) may choose a
default processor profile based upon
a future version of a TTML presentation or transformation profile.

5.3 Catalog

The vocabulary of the Timed Text Markup Language (TTML) is
defined in the following major catalogs (divisions of vocabulary):

The core catalog defines the baseline, core vocabulary of TTML,
and, in particular, the vocabulary of TTML Content. The extension catalog
serves as a placeholder for extensions to the core vocabulary defined
by TTML.

5.3.1 Core Catalog

The core vocabulary catalog is intended to satisfy the needs of
TTML while providing a baseline vocabulary for future profiles. This vocabulary
is divided into distinct categories, specified in detail
in the following sections:

All vocabulary defined by TTML consistently makes use of
the so-called lowerCamelCase naming convention. In some cases, this results in the
change of a name when the name was based upon another specification
that used a different naming convention.

5.3.2 Extension Catalog

The extension vocabulary catalog is intended for use by future
profiles of TTML, and is not further defined
by this version of this specification.

In addition to standardized extension vocabulary, a conforming
document instance may contain arbitrary namespace qualified
elements that reside in any namespace other than those namespaces
defined for use with this specification. Furthermore, a conforming
document instance may contain arbitrary namespace qualified
attributes on TTML defined vocabulary where such attributes reside in
any namespace other than those defined for use with this
specification.

6 Profile

This section specifies the profile matter of the
core vocabulary catalog, where profile matter is to be understood as information that expresses requirements or optionality related to authoring or processing
a timed text content document.

The sub-sections of this section are ordered logically (from highest to lowest level construct).

6.1.1 ttp:profile

The ttp:profile element is used to specify a
processor profile or a
content profile.
A processor profile specifies a
collection of required (mandatory) and optional (voluntary) features and extensions that must or
may be supported by a content processor in order to process a
document instance that makes (or may make) use of such features and
extensions.
A content profile specifies a
collection of prohibited, required, and optional features and extensions that, respectively,
must not, must, and may be present in a document instance that declares its
adherence to the profile.

Note:

The difference between a feature and an
extension is where it is defined and how it is labeled:
if defined in this specification (or a future revision thereof) and
labeled with a feature designation in E Features, then
it is considered to be a feature; if defined in another specification
and labeled there with an extension designation, then it is considered
to be an extension. In general, features are expected to be defined by
the W3C standards process, while extensions are expected to be defined by
third parties.

This specification defines two distinct contexts of use for the ttp:profile element:

as a child of the head element or a ttp:profile element within a TTML document instance;

When a ttp:profile element appears within a TTML document instance,
its purpose is to express authorial intentions about (1) which
features and extensions must or may be supported by a recipient
content processor in order to process that document or (2) which features and extensions must not, must, or may be
included or otherwise used in that document instance.

The ttp:profile element accepts as its children zero or more
elements in the Metadata.class element group, followed by either (1)
zero or more ttp:features elements followed by
zero or more ttp:extensions elements or (2)
zero or more ttp:profile elements.
When a ttp:profile element contains a child ttp:profile element, then the child is referred to as
a nested profile and the parent is referred to as a nesting profile;
otherwise it is referred to as a non-nesting profile.

The combine attribute is used to specify how
feature or extension specifications are combined in the case that
multiple specifications apply to the same feature or extension, respectively.

If the value of the combine attribute is replace, then a
lexically subsequent feature or extension specification replaces a lexically prior
specification, where specification elements are ordered as follows:

If the value is leastRestrictive, then the least restrictive specification value applies;
if the value is mostRestrictive, then the most restrictive specification value
applies. The order of restrictiveness is as follows (from least to most):
optional, required, prohibited.

If the combine attribute is not specified, then replacement semantics apply.

If specified, the designator attribute must (1) adhere to the
xsd:anyURI data type defined by [XML Schema Part 2],
§3.2.17 and (2) express an absolute URI that denotes a profile designator in
accordance with 5.2 Profiling. A designator attribute may
be specified on a ttp:profile element that appears in a TTML
document instance, and, if not specified,
the defined profile is considered to be an undesignated profile.
A designator attribute should
be specified on a ttp:profile element that appears in a TTML
profile definition document instance,
and, if not specified, the defining context (e.g., an external specification) must specify
a designator in its accompanying definition text.

If specified, the use attribute must adhere to the
xsd:anyURI data type defined by [XML Schema Part 2],
§3.2.17, and, furthermore, must denote a profile designator in
accordance with 5.2 Profiling. In this case,
the profile designator must refer to (1) a standard, predefined
profile definition document as defined by 6 Profile,
or (2) a feasibly dereferenceable resource representing a valid Profile Definition
Document instance. In either case, the referenced profile serves as the
baseline profile of the specifying ttp:profile element.

If the use attribute is not specified, then the baseline profile
of the ttp:profile element must be considered to be
the empty (null) profile, i.e., a profile definition containing no
feature or extension specifications.

The combined specification set CSS of features and extensions of a profile P
is determined according to the following ordered rules, where merging a specification S
into CSS entails applying a combination method in accordance with the specified
(or default) value of the combine attribute, and where merging a combined specification set CSS' into
CSS entails merging each ordered specification of CSS' into CSS:

initialize CSS to the empty set;

if a use attribute is present, then merge
the combined specification set of the referenced baseline profile into CSS;

for each ttp:profile child of the P,
using a post-order traversal, merge the combined specification set of the child profile
into CSS;

for each ttp:feature and ttp:extension child of the ttp:profile element,
using a post-order traversal, merge the feature or extension specification
into CSS.

A conformant TTML processor is not required to be able to
dereference a profile definition document that is not one of the
standard, predefined profiles defined by G Standard Profiles. Furthermore,
a conformant TTML processor may make use of a built-in, static
form of each standard, predefined profile so as not to require
dereferencing a network resource.

If a TTML processor is unable to dereference a non-standard
profile definition document, then it must not further process the
document without the presence of an explicit override from an end-user
or some implementation specific parameter traceable to an end-user or
to a user or system configuration setting. If a TTML processor aborts
processing of a document instance due to the inability to
reference a non-standard profile definition document, then some
end-user notification should be given unless the end-user or system
has disabled such a notification, or if the processor does not permit
or entail the intervention of an end-user.

In the above example, the TTML presentation profile is used as the
baseline profile. This baseline profile is then supersetted (thus
creating an additive derived profile) by requiring support for
#text-outline feature.

6.1.2 ttp:features

The ttp:features element is a container element used to group
infomation about feature support and usage requirements.

The ttp:features element accepts as its children zero or more
elements in the Metadata.class element group, followed by
zero or more ttp:feature elements.

If specified, the xml:base
attribute must (1) adhere to the
xsd:anyURI data type defined by [XML Schema Part 2],
§3.2.17, (2) express an absolute URI that
adheres to [XML Base] and,
(3) express a feature namespace as defined by
E.1 Feature Designations. If not specified, the
xml:base attribute's default
value applies, which is the TT Feature Namespace.

The xml:base attribute is
used to permit the abbreviation of feature designation URIs expressed
by child ttp:feature elements.

6.1.3 ttp:feature

The ttp:feature element is used to specify
infomation about support and usage requirements for a particular feature.

If specified, the extends attribute and/or the restricts
attribute must (1) adhere to the
xsd:anyURI data type defined by [XML Schema Part 2],
§3.2.17, and
(2) express a feature designation as defined by
E.1 Feature Designations.

The extends attribute may be used to indicate that the feature being defined
is, from either (or both) a syntactic or (and) semantic perspective, a proper superset of the
feature referenced by the extends attribute.
The restricts attribute may be used to indicate that the feature being defined
is, from either (or both) a syntactic or (and) semantic perspective, a proper subset of the
feature referenced by the restricts attribute.
If an extends attribute is specified, then a restricts attribute must
not be specified on a ttp:feature element; likewise, if a restricts attribute
is specified, then an extends attribute must not be specified.

If the URI expressed by (1) the content of the ttp:feature
element, (2) the extends attribute, or (3) the restricts attribute
is a relative URI, then, when combined with the
feature namespace value expressed by the
xml:base attribute of the
nearest ancestor ttp:features element, it must express an
absolute URI. In either case (original absolute URI or resulting
absolutized URI), the URI expressed by the ttp:feature
element must further adhere to the syntax of a feature designation as
defined by E.1 Feature Designations, and, furthermore,
the specific designation that appears in this URI, i.e., the portion of the feature designation
that starts with the fragment identifier separator '#', must
be defined by this specification or some published version thereof (that
has achieved REC status).

If the URI expressed by the content of the ttp:feature element,
by the extends attribute, or by the restricts attribute
is a relative URI, then an xml:base attribute should be
specified on the nearest ancestor ttp:features element.

The value attribute specifies constraints on support for or use of
the designated feature according to the profile type.

if the value of the value attribute
is optional, then a processor may but need
not implement or otherwise support the feature in order to process the document;

if the value is required, then perform the following steps:

if the feature is implemented or otherwise supported by a processor, then continue processing
the document;

otherwise, if
(1) the extends attribute is specified on the root tt element,
(2) the value of the extends attribute designates a feature that is implemented or otherwise supported by
a processor, and
(3) the computed value of the ttp:permitFeatureNarrowing
profile property of the root tt element is not false,
then continue processing the document;

otherwise, if
(1) the restricts attribute is specified on the root tt element,
(2) the value of the restricts attribute designates a feature that is implemented or otherwise supported by
a processor, and
(3) the computed value of the ttp:permitFeatureWidening
profile property of the root tt element is not false,
then continue processing the document;

otherwise, abort processing the document unless overridden by the end-user or some implementation specific parameter
traceable to an end-user or to a user or system configuration setting.

if the value attribute is not specified, then the feature specification
must be interpreted as if the value required were specified;

if the value of the value attribute
is optional, then the feature may but need not appear in a document that
claims conformance with that profile;

if the value of the value attribute
is required, then the feature must appear in a document that
claims conformance with that profile;

if the value of the value attribute
is prohibited, then the feature must not appear in a document that
claims conformance with that profile;

if the value attribute is not specified, then the feature specification
must be interpreted as if the value optional were specified;

The value use of the value attribute is obsoleted. If it
appears in a profile specification, then it must be interpreted as if required
had been specified.

If some defined (i.e., standardized) or otherwise well known feature is not specified by
a ttp:feature element in a content profile, then it must be interpreted as if the feature were specified
with the value attribute equal to optional. However, if not specified in a processor profile, no claim
about support or absence of support for the feature is implied.

Note:

In particular, if some feature is not present in a content profile definition, then
it is not to be interpreted as meaning the use of that feature (in a document instance)
is disallowed or otherwise prohibited. If a feature is intended to be disallowed by a content profile, then
it should be specified using the prohibited value.

If a document instance makes use of a feature defined by
E.1 Feature Designations and if the intended use of the
document requires the recognition and processing of that feature, then
the document must include a required feature specification in one of its declared or
referenced profiles.

In the above example, the TTML presentation profile is used as the
baseline profile. This baseline profile is then modified by three
ttp:feature elements in order to (1)
superset the baseline profile (since neither
#fontStyle-italic nor #textDecoration-under
are required by the TTML presentation profile), and
(2) prohibit use of the #textOutline-blurred feature
(which is optional in the TTML presentation profile).

The effect of this example is to express authorial intentions that
italic font style and text underlining must be
supported, and that text outline blurring must not be used by a document.

6.1.4 ttp:extensions

The ttp:extensions element is a container element used to group
infomation about extension support and usage requirements.

The ttp:extensions element accepts as its children zero or more
elements in the Metadata.class element group, followed by
zero or more ttp:extension elements.

If specified, the xml:base
attribute must (1) adhere to the
xsd:anyURI data type defined by [XML Schema Part 2],
§3.2.17, (2) express an absolute URI that
adheres to [XML Base] and,
(3) express an extension namespace as defined by
F.1 Extension Designations. If not specified, the
xml:base attribute's default
value applies, which is the TT Extension Namespace.

The xml:base attribute is
used to permit the abbreviation of feature designation URIs expressed
by child ttp:extension elements.

6.1.5 ttp:extension

The ttp:extension element is used to specify
infomation about support and usage requirements for a particular extension.

The extends attribute may be used to indicate that the extension being defined
is, from either (or both) a syntactic or (and) semantic perspective, a proper superset of the
feature or extension referenced by the extends attribute.
The restricts attribute may be used to indicate that the extension being defined
is, from either (or both) a syntactic or (and) semantic perspective, a proper subset of the
feature or extension referenced by the restricts attribute.
If an extends attribute is specified, then a restricts attribute must
not be specified on a ttp:extension element; likewise, if a restricts attribute
is specified, then an extends attribute must not be specified.

If the URI expressed by (1) the content of the ttp:extension
element, (2) the extends attribute, or (3) the restricts attribute
is a relative URI, then, when combined with the
extension namespace value expressed by the
xml:base attribute of the
nearest ancestor ttp:extensions element, it must express an
absolute URI. In either case (original absolute URI or resulting
absolutized URI), the URI expressed by the ttp:extension
element must further adhere to the syntax of an extension designation as
defined by F.1 Extension Designations,
while the URI expressed by the extends attribute and/or the
restricts attribute must adhere to the syntax of a feature designation
or an extension designation as defined by E.1 Feature Designations or
F.1 Extension Designations, respectively.

If the URI expressed by the content of the ttp:extension element,
by the extends attribute, or by the restricts attribute
is a relative URI, then an xml:base attribute should be
specified on the nearest ancestor ttp:extensions element.

The value attribute specifies constraints on support for or use of
the designated extension according to the profile type.

if the value of the value attribute
is optional, then a processor may but need
not implement or otherwise support the extension in order to process the document;

if the value is required, then perform the following steps:

if the extension is implemented or otherwise supported by a processor, then continue processing
the document;

otherwise, if
(1) the extends attribute is specified on the root tt element,
(2) the value of the extends attribute designates an extension that is implemented or otherwise supported by
a processor, and
(3) the computed value of the ttp:permitFeatureNarrowing
profile property of the root tt element is not false,
then continue processing the document;

otherwise, if
(1) the restricts attribute is specified on the root tt element,
(2) the value of the restricts attribute designates an extension that is implemented or otherwise supported by
a processor, and
(3) the computed value of the ttp:permitFeatureWidening
profile property of the root tt element is not false,
then continue processing the document;

otherwise, abort processing the document unless overridden by the end-user or some implementation specific parameter
traceable to an end-user or to a user or system configuration setting.

if the value attribute is not specified, then the extension specification
must be interpreted as if the value required were specified;

if the value of the value attribute
is optional, then the extension may but need not appear in a document that
claims conformance with that profile;

if the value of the value attribute
is required, then the extension must appear in a document that
claims conformance with that profile;

if the value of the value attribute
is prohibited, then the extension must not appear in a document that
claims conformance with that profile;

if the value attribute is not specified, then the extension specification
must be interpreted as if the value optional were specified;

The value use of the value attribute is obsoleted. If it
appears in a profile specification, then it must be interpreted as if required
had been specified.

If some well known extension is not specified by
a ttp:extension element in a content profile, then it must be interpreted as if the extension were specified
with the value attribute equal to optional. However, if not specified in a processor profile, no claim
about support or absence of support for the extension is implied.

Note:

In particular, if some extension is not present in a content profile definition, then
it is not to be interpreted as meaning the use of that extension (in a document instance)
is disallowed or otherwise prohibited. If an extension is intended to be disallowed by a content profile, then
it should be specified using the prohibited value.

If a document instance makes use
of an extension designatable by F.1 Extension Designations and if the intended use of the document
requires the recognition and processing of that extension, then the
document must include a required extension specification
in one of its declared or referenced profiles.

In the above example, the TTML transformation profile is used as
the baseline profile. This baseline profile is then supersetted by
specifying that support and use is required for a private extension
defined in a third party namespace.

The effect of this example is to express authorial intentions that
a recipient processor must support the TTML transformation profile and
must also support and enable an extension defined by a third party.

If specified, the value of this attribute must adhere to the following syntax,
where each profile-designator item adheres to the xsd:anyURI data type defined by [XML Schema Part 2],
§3.2.17, and, further, adheres to constraints defined on a profile designator in accordance with
5.2 Profiling.

If the list of designators is enclosed in the function syntax all(...) or no function syntax is used,
then conformance is claimed with all designated content profiles. If the list
of designators is enclosed in the function syntax any(...), then conformance is claimed with at least one
of the designated content profiles.

A ttp:contentProfiles
attribute is considered to be significant only when specified on the
tt element.

6.2.2 ttp:contentProfileCombination

The ttp:contentProfileCombination attribute is used to specify the
method for combining multiple content profiles.

If specified, the value of this attribute must adhere to the following syntax:

A ttp:inferProcessorProfileMethod attribute is considered to be significant only
when specified on the tt element.

6.2.4 ttp:inferProcessorProfileSource

The ttp:inferProcessorProfileSource attribute is used to specify the
source for mapping a content profile specification value to a corresponding processor
profile specification value.

If specified, the value of this attribute must adhere to the following syntax:

Syntax Representation – ttp:inferProcessorProfileSource

ttp:inferProcessorProfileSource
: "combined"
| "first"

If this parameter's value is combined, then, when inferring a processor profile, the combined profile specification
set of the effective content profile is used as the source of inference.

If this parameter's value is first, then, when inferring a processor profile, the first constituent profile of
the effective content profile, where the processor profile inferred from that
constituent profile is supported by the content processor, is used as the source of inference.

If not specified, the value of this parameter must be considered
to be combined.

A ttp:inferProcessorProfileSource attribute is considered to be significant only
when specified on the tt element.

6.2.5 ttp:permitFeatureNarrowing

The ttp:permitFeatureNarrowing attribute is used to specify whether
requirements related to a feature or extension may be satisfied by a (syntactically or semantically) narrower interpretation
of the feature or extension.

If specified, the value of this attribute must adhere to the following syntax:

If this parameter's value is true, then, a requirement for support of a feature or extension may be satisfied
if the definition of the feature or extension specifies an extends attribute, and the feature or extension referenced
by that attribute is supported by a processor.

If this parameter's value is false, then, a requirement for support of a feature or extension can not be satisfied
by a more narrowly defined feature or extension specified by an extends attribute.

If not specified, the value of this parameter must be considered
to be false.

A ttp:permitFeatureNarrowing attribute is considered to be significant only
when specified on the tt element.

6.2.6 ttp:permitFeatureWidening

The ttp:permitFeatureWidening attribute is used to specify whether
requirements related to a feature or extension may be satisfied by a (syntactically or semantically) wider interpretation
of the feature or extension.

If specified, the value of this attribute must adhere to the following syntax:

If this parameter's value is true, then, a requirement for support of a feature or extension may be satisfied
if the definition of the feature or extension specifies an restricts attribute, and the feature or extension referenced
by that attribute is supported by a processor.

If this parameter's value is false, then, a requirement for support of a feature or extension can not be satisfied
by a more widely defined feature or extension specified by an restricts attribute.

If not specified, the value of this parameter must be considered
to be false.

A ttp:permitFeatureWidening attribute is considered to be significant only
when specified on the tt element.

6.2.7 ttp:profile

The ttp:profile attribute is deprecated. If creating a TTML document instance for TTML2 (or later versions),
then the ttp:profile attribute should not be used; instead, the content author should use the ttp:processorProfiles
attribute, specified at 6.2.8 ttp:processorProfiles.

If specified, the value of this attribute must adhere to the following syntax
where the designator adheres to the
xsd:anyURI data type defined by [XML Schema Part 2],
§3.2.17, and, further, must specify a
profile designator in accordance with
5.2 Profiling.

Syntax Representation – ttp:profile

ttp:profile
: designator
designator
: xsd:anyURI

A ttp:profile
attribute is considered to be significant only when specified on the
tt element.

If specified, the value of this attribute must adhere to the following syntax,
where each profile-designator item adheres to the xsd:anyURI data type defined by [XML Schema Part 2],
§3.2.17, and, further, adheres to constraints defined on a profile designator in accordance with
5.2 Profiling.

If the list of designators is enclosed in the function syntax all(...) or no function syntax is used,
then support is required for all designated processor profiles. If the list
of designators is enclosed in the function syntax any(...), then support is required for at least one
of the designated processor profiles.

A ttp:processorProfiles
attribute is considered to be significant only when specified on the
tt element.

6.2.9 ttp:processorProfileCombination

The ttp:processorProfileCombination attribute is used to specify the
method for combining multiple processor profiles.

If specified, the value of this attribute must adhere to the following syntax:

6.2.10 ttp:validation

If specified, the value of this attribute must adhere to the following syntax:

Syntax Representation – ttp:validation

ttp:validation
: "required"
| "optional"
| "prohibited"

If this parameter's value is required, then, a validating content processor
must perform validation processing on a TTML document instance prior to performing
other types of processing, e.g., presentation or transformation processing.

If this parameter's value is optional, then, a validating content processor
may, but need not, perform validation processing on a TTML document instance prior to performing
other types of processing, e.g., presentation or transformation processing.

If this parameter's value is prohibited, then, a validating content processor
must not perform validation processing on a TTML document instance prior to performing
other types of processing, e.g., presentation or transformation processing, unless the end-user or application overrides this prohibition.

If validation processing is performed on a TTML document instance and validation fails, then the computed value of
the ttp:validationAction parameter property is used to determine what action to take before performing further processing.

If not specified, the value of this parameter must be considered
to be optional.

A ttp:validation attribute is considered to be significant only
when specified on the tt element.

If this parameter's value is warn, then, a validating content processor
should warn the end-user when validation processing fails, and, give the end-user the option to continue or abort processing.

If this parameter's value is ignore, then, a validating content processor
should not abort and should not warn the end-user when validation processing fails.

If not specified, the value of this parameter is determined as follows:
if the computed value of the ttp:validation parameter property is required,
then the value must be considered to be abort;
if it is optional,
then the value must be considered to be warn;
otherwise, if it is prohibited,
then the value must be considered to be ignore.

A ttp:validationAction attribute is considered to be significant only
when specified on the tt element.

If not specified, the version must be considered to be
equal to one (1). If specified, then the version must be greater than zero (0). The version associated
with this version of the Timed Text Markup Language
specification is two (2).

A ttp:version attribute is considered to be significant only
when specified on the tt element.

7 Parameter

This section specifies the parameter matter of the
core vocabulary catalog, where
parameters are to be understood as information that is either (1)
essential or (2) of significant importance for the purpose of
interpreting the semantics of other types of information expressed by
core vocabulary items or for establishing a document processing context by means
of which TTML Content can be related to an external environment.

Unless explicitly stated otherwise, linear white-space (LWSP) must
appear between adjacent non-terminal components of a TT Parameter value
unless some other delimiter is permitted and used.

7.2.1 ttp:cellResolution

The ttp:cellResolution attribute may be used by an author
to express the number of horizontal and vertical cells into which the root container region
area is divided for the purpose of expressing presentation semantics in terms of
a uniform grid.

If specified, the value of this attribute must adhere to the following syntax:

If not specified, the number of columns and rows must be considered
to be 32 and 15, respectively. If specified, then columns or rows must not be zero (0).

Note:

The choice of values 32 and 15 are based on this being the
maximum number of columns and rows defined by [CEA-608-E].

A ttp:cellResolution attribute is considered to be significant only
when specified on the tt element.

Note:

The use of a uniform grid is employed only for the purpose of
measuring lengths and expressing coordinates. In particular, it is not
assumed that the presentation of text or the alignment of individual
glyph areas is
coordinated with this grid. Such alignment is possible, but
requires the use of a monospaced font and a font size whose EM square exactly
matches the cell size.

Except where indicated otherwise, when a <length> expressed in
cells denotes a dimension parallel to the inline or block progression dimension,
the cell's dimension in the inline or block progression dimension applies, respectively.

Note:

For example, if padding (on all four edges) is specified as 0.1c, the cell resolution
is 20 by 10, and the extent of the root container region is 640 by 480, then, assuming top to bottom,
left to right writing mode, the start and end padding will be (640 / 20) * 0.1 pixels and the
before and after padding will be (480 / 10) * 0.1 pixels.

7.2.2 ttp:clockMode

The ttp:clockMode attribute is used to specify the
interpretation of time expressions as real-time time coordinates when
operating with time base of clock as defined by 7.2.13 ttp:timeBase.

If specified, the value of this attribute must adhere to the following syntax:

Syntax Representation – ttp:clockMode

ttp:clockMode
: "local"
| "gps"
| "utc"

If the time base, defined by 7.2.13 ttp:timeBase, is designated as
clock, then this parameter applies as follows: if the
parameter's value is local, then time expressions are
interpreted as local wall-clock time coordinates;
if utc, then time expressions are
interpreted as UTC time coordinates
[UTC];
if gps, then time expressions are
interpreted as GPS time coordinates
[GPS].

Note:

The primary difference between GPS time and UTC time is that GPS
time is not adjusted for leap seconds, while UTC time is adjusted as
follows: UTC = TAI (Temp Atomique International) + leap seconds
accumulated since 1972. TAI is maintained by the Bureau
International des Poids et Mesures (BIPM) in Sevres, France.
The GPS system time is steered to a Master Clock (MC) at the US Naval
Observatory which is kept within a close but unspecified
tolerance of TAI.

If not specified, the value of this parameter must be considered
to be utc.

A ttp:clockMode attribute is considered to be significant only
when specified on the tt element.

7.2.3 ttp:dropMode

The ttp:dropMode attribute is used to specify
constraints on the interpretation and use of frame counts
that correspond with [SMPTE 12M] time coordinates when operating
with time base of smpte as defined by
7.2.13 ttp:timeBase.

If specified, the value of this attribute must adhere to the following syntax:

Syntax Representation – ttp:dropMode

ttp:dropMode
: "dropNTSC"
| "dropPAL"
| "nonDrop"

If the time base, defined by 7.2.13 ttp:timeBase, is designated as
smpte, then this parameter applies as follows: if the
parameter's value is nonDrop, then, within any given
second of a time expression, frames count from 0 to
N−1, where N is the value specified by
the ttp:frameRate parameter, but while ignoring any value
specified by the ttp:frameRateMultiplier parameter.

Note:

When operating in nonDrop
mode, a second of a time expression may or may not be equal to a
second of real time during normal (1x speed) forward playback. If the
ttp:frameRateMultiplier parameter is specified and is not
equal to 1:1, then a second of a time expression will either be
shorter or longer than a second of elapsed play in real
time.

If this parameter's value is dropNTSC, then, within any
given second of a time expression except the second 00,
frames count from 0 to N−1, where N is
the value specified by the ttp:frameRate parameter, but
while ignoring any value specified by the
ttp:frameRateMultiplier parameter. If the second of a time
expression is 00 and the minute of the time expression is
not 00, 10, 20, 30,
40, or 50, then frame codes 00
and 01 are dropped during that second; otherwise, these
frame codes are not dropped.

Note:

For example, when operating in dropNTSC
mode with ttp:frameRate of 30, a discontinuity
in frame count occurs between consecutive frames as shown in the
following sequence of time expressions: 01:08:59:28,
01:08:59:29, 01:09:00:02,
01:09:00:03.

If this parameter's value is dropPAL, then, within any
given second of a time expression except the second 00,
frames count from 0 to N−1, where N is
the value specified by the ttp:frameRate parameter, but
while ignoring any value specified by the
ttp:frameRateMultiplier parameter. If the second of a time
expression is 00 and the minute of the time expression is
even but not 00, 20, or 40,
then frame codes 00 through 03 are dropped
during that second; otherwise, these frame codes are not dropped.

Note:

For example, when operating in dropPAL
mode with ttp:frameRate of 30, a discontinuity
in frame count occurs between consecutive frames as shown in the
following sequence of time expressions: 01:09:59:28,
01:09:59:29, 01:10:00:04,
01:10:00:05.

Note:

The dropPAL mode is also known as the
M/PAL or PAL (M) drop-frame
code, which uses PAL modulation with the NTSC frame rate of ~29.97
frames/second. The M/PAL system is used primarily in Brazil.

If not specified, then nonDrop must be assumed to apply.

A ttp:dropMode attribute is considered to be significant only
when specified on the tt element.

7.2.4 ttp:frameRate

The ttp:frameRate attribute is used to specify the frame rate of a related
media object or the intrinsic frame rate of a document instance in case it is intended
to function as an independent media object.

If the media time base applies and the effective frame rate is
integral, then a frame is interpreted as a division of a second of media
time, such that if the frame rate is specified as F, then
a second of media time is divided into F intervals of
equal duration, where each interval is labeled as frame f,
with f ∈ [0…F−1].

Note:

See H.2 Media Time Base for further details
on the interpretation of time expressions for the media time base.

If not specified, the frame rate must be considered to be equal to some
application defined frame rate, or if no application defined frame rate applies,
then thirty (30) frames per second. If specified, then the frame rate must
be greater than zero (0).

A ttp:frameRate attribute is considered to be significant only
when specified on the tt element.

7.2.5 ttp:frameRateMultiplier

The ttp:frameRateMultiplier attribute is used to
specify a multiplier to be applied to the frame rate specified by a
ttp:frameRate attribute in order to compute the effective
frame rate.

If specified, the value of this attribute must adhere to the following syntax:

A frame rate multiplier is used when the desired frame rate cannot
be expressed as an integral number of frames per second.

If not specified, the frame rate multiplier must be considered to be equal to one (1:1).
Both numerator and denominator must be non-zero.

A ttp:frameRateMultiplier attribute is considered to be significant only
when specified on the tt element.

Note:

The frame rate multiplier used for synchronizing with NTSC [SMPTE 170M]
formatted video objects at 30 frames per second is nominally
1000:1001. The nominal frame rate of NTSC video is defined as the chrominance
sub-carrier frequency of 3,579,545.45…Hz (= 5.0MHz × 63/88) times the ratio 2/455 divided by
the number of horizontal lines per frame of 525, which yields a frame
rate of 29.970029970029… (= 30 × 1000/1001) frames per
second. Other frame rate multipliers apply to different regions of
usage and video format standards.

Note:

Except in the case of PAL/M, the frame rate multiplier used for synchronizing with PAL
formatted video objects at 25 frames per second is nominally 1:1.

7.2.6 ttp:markerMode

The ttp:markerMode attribute is used to specify
constraints on the interpretation and use of time expressions
that correspond with [SMPTE 12M] time coordinates when operating
with time base of smpte as defined by
7.2.13 ttp:timeBase.

If specified, the value of this attribute must adhere to the following syntax:

Syntax Representation – ttp:markerMode

ttp:markerMode
: "continuous"
| "discontinuous"

If the time base, defined by 7.2.13 ttp:timeBase, is designated as
smpte, then this parameter applies as follows: if the
parameter's value is continuous, then [SMPTE 12M] time coordinates
may be assumed to be linear and either monotonically increasing or
decreasing; however, if discontinuous, then any assumption
must not be made regarding linearity or monotonicity of time coordinates.

If not specified, the value of this parameter must be considered
to be discontinuous.

Note:

The default value for this parameter was originally specified
(in TTML 1.0 First Edition)
as continuous; however, further evaluation of the state of the industry indicated this
choice was incorrect, and that the most common default is discontinuous.

A ttp:markerMode attribute is considered to be significant only
when specified on the tt element.

If a value of continuous applies, then time
expressions may be converted to real time
coordinates by taking into account the computed frame rate
and drop mode as expressed by the ttp:dropMode parameter.
In this case, the content processor must create and maintain a
synthetic smpte document syncbase within which these time
expressions are interpreted as further described in
12.4 Timing Semantics.

Note:

When operating with smpte time base and
continuous marker mode, there is an implied time coordinate
space, the synthetic smpte document syncbase,
defined by the monotonically increasing (or decreasing)
[SMPTE 12M] time coordinates, while taking into account
the computed frame rate and drop mode. All time expressions are interpreted
in relationship to this time coordinate space based upon
smpte time code synchronization events (markers),
where the document processing context emits these events with implied constraints
regarding time coordinate monoticity and resynchronization in
the presence of dropped frames.

Use of continuous marker mode with the smpte
time base is different from using the media time base
because (1) the semantics of the ttp:dropMode parameter
apply to the former, but not the latter, and (2) [SMPTE 12M]
time coordinates may be applied monotonically to media which has been
subjected to dilation in time, constriction in time, or reversal in
time.

If a value of discontinuous applies, then time
expressions must not be converted to real time
coordinates, arithmetical operators (addition, multiplication) are not
defined on time expressions, and, consequently, any (well-formed)
expression of a duration must be considered to be invalid.

Note:

When operating with smpte time base and
discontinuous marker mode, there is no effective time coordinate
space; rather, all time expressions are interpreted as labeled
synchronization events (markers), where the document processing context
emits these events, which, when they correspond with time
expressions that denote the same label, cause a temporal interval to
begin or end accordingly.

An additional side-effect of operating in discontinuous
mode is that time expressions of children have no necessary
relationship with time expressions of their temporal container; that
is, temporal containers and children of these containers are
temporally activated and inactivated independently based on the
occurrence of a labeled synchronization (marker) event.

Note:

The notion of marker discontinuity as captured by this parameter
is logically independent from the method used to count frames as
expressed by the ttp:dropMode parameter. In particular,
even if the ttp:dropMode parameter is specified as
dropNTSC or dropPAL, the marker mode may be
specified as continuous, even in the presence of frame count
discontinuities induced by the frame counting method, unless there
were some other non-linearity or discontinuity in marker labeling, for
example, two consecutive frames labeled as 10:00:00:00
and 10:00:01:00.

7.2.7 ttp:mediaDuration

The ttp:mediaDuration attribute is used to specify the
temporal extent (simple duration) of a related media object.

If the temporal extent (simple duration) of the related media object is known at authoring time, then this
attribute should be specified; otherwise, if no related media object applies or its
temporal extent is unknown, then this attribute should not be specified.

If specified, the value of this attribute must adhere to the following syntax:

If specified, the value of this parameter must adhere to the offset-time form of
a <time-expression> optionally expressed with a sign.
If not specified, the value of this parameter must be considered
to be 0s.

If specified, then both numerator and demoninator must be non-zero.
If not specified, then the storage aspect ratio of the authoring viewport is undefined.

A ttp:storageAspectRatio attribute is considered to be significant only
when specified on the tt element.

7.2.11 ttp:subFrameRate

The ttp:subFrameRate attribute is used to specify the sub-frame rate of a related
media object or the intrinsic sub-frame rate of a document instance in case it is intended
to function as an independent media object.

If specified, the value of this attribute must adhere to the following syntax:

If the media time base applies and the effective frame rate is
integral, a sub-frame is interpreted as a division of a frame of media
time, such that if the sub-frame rate is specified as S, then
a frame of media time is divided into S intervals of
equal duration, where each interval is labeled as sub-frame s,
with s ∈ [0…S−1].

Note:

See H.2 Media Time Base for further details
on the interpretation of time expressions for the media time base.

If not specified, the sub-frame rate must be considered to be
equal to one (1). If specified, then the sub-frame rate must be greater than zero (0).

A ttp:subFrameRate attribute is considered to be significant only
when specified on the tt element.

Note:

The sub-frame is sometimes referred to as a field in
the context of synchronization with an interlaced video media object.

7.2.12 ttp:tickRate

The ttp:tickRate attribute is used to specify the tick rate of a related
media object or the intrinsic tick rate of content of a document instance in case it is intended
to function as an independent media object.

If specified, the value of this attribute must adhere to the following syntax:

If the media time base applies,
a tick is interpreted as an integral division of a second of media
time, such that if the tick rate is specified as T, then
a second of media time is divided into T intervals of
equal duration, where each interval is labeled as tick t,
with t ∈ [0…T−1].

Note:

See H.2 Media Time Base for further details
on the interpretation of time expressions for the media time base.

If not specified, then if a frame rate is specified, the tick rate
must be considered to be the effective frame rate multiplied by the
sub-frame rate (i.e., ticks are interpreted as sub-frames); or, if no
frame rate is specified, the tick rate must be considered to be one (1)
tick per second of media time. If specified, then the tick rate
must not be zero (0).

Note:

There is no predefined relationship between ticks and frames or
sub-frames. Ticks are an arbitrary division of seconds that permit
use of fixed point arithmetic rather than fractional (and potentially
inexact) expressions of seconds.

A ttp:tickRate attribute is considered to be significant only
when specified on the tt element.

7.2.13 ttp:timeBase

The ttp:timeBase attribute is used to specify the
temporal coordinate system by means of which time expressions are
interpreted in a document instance.

If specified, the value of this attribute must adhere to the following syntax:

Syntax Representation – ttp:timeBase

ttp:timeBase
: "media"
| "smpte"
| "clock"

If the time base is designated as media, then a time
expression denotes a coordinate in some media object's time line,
where the media object may be an external media object with which the
content of a document instance is to be synchronized, or it may
be the content of a document instance itself in a case where
the timed text content is intended to establish an independent time
line.

Note:

When using a media time base, if that time base is paused or
scaled positively or negatively, i.e., the media play rate is
not unity, then it is expected that the
presentation of associated Timed Text content will be similarly
paused, accelerated, or decelerated, respectively. The means for
controlling an external
media time base is outside the scope of this specification.

When the time base is designated as smpte,
every time expression denotes a media marker value akin to that
defined by [SMIL 3.0], § 5.4.3, except instead
of using an opaque marker name, a structured [SMPTE 12M]
time coordinate serves as the marker name.

If the time base is designated as clock, then the time
expression denotes a coordinate in some real-world time line as
established by some real-time clock, such as the local wall-clock time
or UTC (Coordinated Universal Time) or GPS (Global Positioning System)
time lines.

If not specified, the default time base must be considered to be
media.

A ttp:timeBase attribute is considered to be significant only
when specified on the tt element.

When operating with either media or smpte
time bases, a diachronic presentation of a document instance may
be subject to transformations of the controlling time line, such as
temporal reversal, dilation (expansion), or constriction
(compression); however, when operating with the clock
time base, no transformations are permitted, and diachronic
presentation proceeds on a linear, monotonically increasing time line
based on the passage of real time.

Note:

Due to there being only one time base parameter that applies to a
given document instance, the interpretation of time expressions
is uniform throughout the document instance.

The root temporal extent, i.e., the time interval over which a document instance is active, has an implicit duration that is equal to the
implicit duration of the body element of the document, if the body element is present, or zero, if the body element is absent.

If an author desires to signal the (storage or image) aspect ratio of the root container region
without specifying its resolution, then this may be accomplished by using metadata specified
in an external namespace, such as m708:aspectRatio as defined in [SMPTE 2052-11], §5.4.4.
This would permit, for example, the interchange of information that reflects the
the semantics of [CEA-708-E] , §4.5 “Caption Service Metadata”, “ASPECT RATIO”.

Except for the tts:extent and tts:position attributes described above, an attribute in the TT Style Namespace should not
be specified on the tt element unless it denotes an inheritable style property, in which case such inheritable style property is available
for root style inheritance. If a non-inheritable style property is specified, then
it must be ignored for the purpose of non-validation processing. In the case of validation
processing, such usage should be reported as a warning, or, if strict validation is performed, as an error.

An xml:lang attribute must be specified on the tt element.
If the attribute value is empty, it signifies that there is no default language that applies
to the text contained within the document instance.

If no xml:space attribute is specified upon the tt element, then it must
be considered as if the attribute had been specified with a value of default.

8.1.2 head

The head element is a container element used to group header matter, including metadata,
profile, embedded content resources, styling, and layout information.

The head element accepts as its children zero or more
elements in the Metadata.class element group,
followed by zero or more elements in the
Profile.class element group,
followed by zero or one resources element,
followed by zero or one styling element,
followed by zero or one layout element,
followed by zero or one animation element.

Any metadata specified by children in the Metadata.class
element group applies semantically to the document instance as a
whole, and not just the head element.

Any parameters specified by children in the Parameters.class
element group applies semantically to the document instance as a
whole, and not just the head element.

A resources child element is used to specify embedded content constructs
that are referenced from certain style constructs and
embedded content elements.

A styling child element is used to specify style constructs
that are referenced from other style constructs, by layout constructs, and by
content elements.

A layout child element is used to specify layout constructs that
are referenced by content elements.

An animation child element is used to specify animation constructs that
target animatable content element
or Layout elements.

To the extent that time semantics apply to the content of the
head element, the implied time interval of this element is
defined to be coterminous with the root temporal extent.

8.1.3 body

The body element functions as a logical container and a temporal
structuring element for a sequence of textual content units represented as
logical divisions.

The body element accepts as its children zero or more
elements in the Metadata.class element group,
followed by zero or more
elements in the Animation.class element group,
followed by
zero or more div elements.

Any metadata specified by children in the Metadata.class
element group applies semantically to the body element and its descendants as a whole.

Any animation elements specified by children in the Animation.class
element group apply semantically to the body element.

An author may specify a temporal interval for a body element using
the begin, dur, and end attributes. If the begin point
of this interval remains unspecified, then the begin point is interpreted as the beginning
point of the root temporal extent. Similarly, if the end point of this interval remains unspecified, then the
end point is interpreted as the ending point of the root temporal extent.

Note:

A document instance referenced from a SMIL presentation
is expected to follow the same timing rules as apply to other SMIL media
objects.

If relative begin or end times are specified on the body
element, then these times are resolved by reference to the beginning and
ending time of the root temporal extent.

If the root temporal extent is shorter than the computed duration of the
body element, then the active time interval of a body element is
truncated to the active end point of the root temporal extent.

An author may associate a set of style properties with a
body element by means of either the style
attribute or inline style attributes or a combination thereof.

Note:

Style properties that are associated with a body element
in a document instance are available for style inheritance by
descendant content elements such as div, p,
span
and br.

If no timeContainer attribute is specified on a
body element, then it must be interpreted as having
parallel
time containment semantics.

8.1.4 div

The div element functions as a logical container and a temporal
structuring element for a sequence of textual content units represented as
logical sub-divisions or paragraphs.

Note:

When rendered on a continuous (non-paged) visual presentation medium,
a div element is expected to generate
one or more block
areas
that contain zero or more child block areas
generated by the div element's
descendant
p elements.

If some
block area generated by a div element does
not contain any child areas, then it is not expected to be presented.

If no timeContainer attribute is specified on
a p element, then it must be interpreted as having
parallel time containment semantics.

If a sequence of children of a p element
consists solely of character information items, then that sequence must
be considered to be an anonymous span for the purpose of
applying style properties that apply to span elements.

Note:

The presentation semantics of TTML effectively
implies that a p element constitutes a line break. In particular,
it is associated with a block-stacking constraint both before the first
generated line area and after the last generated line area. See
11.3.1.4 Synchronic Flow Processing for further details.

8.1.6 span

The span element functions as a logical container and a temporal
structuring element for a sequence of textual content units having inline
level formatting semantics.

When presented on a visual medium, a span element is intended to
generate a sequence of inline areas, each containing one or more glyph areas.

An author may associate a set of style properties with a
span element by means of either the style
attribute or inline style attributes or a combination thereof.

Note:

Style properties that are associated with a span element
in a document instance are available for style inheritance by
descendant content elements such as span and
br.

If no timeContainer attribute is specified on
a span element, then it must be interpreted as having
parallel time containment semantics.

The linking attributes xlink:* may be used to link a span element with related content, using the
specified location (href), roles, and title. The behavior of link activation is affected by the xlink:show attribute,
the precise meaning of which is determined by the document processing context.

If a span element specifies an xlink:href attribute, then a nested span element descendant must not specify
an xlink:href attribute, and, if it does, then the latter must be ignored for the purpose of presentation or activation processing.

8.1.7 br

The br element denotes an explicit line break.

Any metadata specified by children in the Metadata.class
element group applies semantically to the br element and its descendants as a whole.

Any animation elements specified by children in the Animation.class
element group apply semantically to the br element.

When presented on a visual medium, the presence of a br element must be
interpreted as a forced line break.

Note:

The visual presentation of a br element is
intended to produce the same effect as the control character
CR (U+000D)
followed by the control code LF (U+000A) when presented on a teletype device.
Therefore, two br elements in sequence will produce a
different effect than a single br element.

If no timeContainer attribute is specified on
a br element, then it must be interpreted as having
parallel time containment semantics.

8.2 Content Attribute Vocabulary

This section defines the following common attributes used with many or all element types
in the core vocabulary catalog:

8.2.1 condition

The condition attribute is used to conditionally exclude an element from semantic processing.

The condition attribute may be used with any element in the core vocabulary catalog
except profile matter, i.e., elements of the Profile Module.

The value of a condition attribute must adhere to a
<condition> expression.

For the purpose of presentation processing, if an element specifies a condition attribute, and the
its <condition> expression value evaluates to false,
then the semantics of the element and its descendant elements must be ignored.

Note:

For example, if a p element specifies a condition
attribute that evaluates to false, then the content of that element is ignored for presentation purposes.

8.2.6 xlink:title

8.2.7 xml:id

The xml:id attribute may be used with any element in the core vocabulary catalog.

8.2.8 xml:lang

The xml:lang attribute is used as defined by
[XML 1.0], §2.12, Language Identification.

The xml:lang attribute must be specified on the tt
element and may be specified by an instance of any other element type
in the core vocabulary catalog except parameter vocabulary.

8.2.9 xml:space

The xml:space attribute is used as defined by
[XML 1.0], §2.10, White Space Handling.

The xml:space attribute may be used with any element in
the core vocabulary catalog except parameter vocabulary.

The semantics of the value default are fixed to mean that
when performing presentation processing of a document instance as
described by 11.3.1.4 Synchronic Flow Processing,
processing must occur as
if the following properties were specified on the affected
elements of an equivalent intermediate XSL-FO document:

suppress-at-line-break="auto"

linefeed-treatment="treat-as-space"

white-space-collapse="true"

white-space-treatment="ignore-if-surrounding-linefeed"

Similarly, the semantics of the value preserve are fixed to mean that
when performing presentation processing, processing must occur as
if the following properties were specified on the affected
elements of an equivalent intermediate XSL-FO document:

suppress-at-line-break="retain"

linefeed-treatment="preserve"

white-space-collapse="false"

white-space-treatment="preserve"

When performing other types of processing intended to eventually
result in a visual presentation by means other than those described
in this specification, the semantics of space collapsing and
preservation as described above should be respected. For other types
of processing, the treatment of the xml:space attribute
is processor dependent, but should respect the semantics described
above if possible.

Note:

The semantics of the above four cited XSL-FO properties are defined by
by [XSL 1.1], § 7.17.3, 7.16.7, 7.16.12, and 7.16.8, respectively.

Evaluates to a boolean value that denotes whether the content processor is processing the
left image of a stereo presentation.
If used in a document instance, then a usesStereo
named metadata item should be specified as a child of the head element.

stereoRight

Evaluates to a boolean value that denotes whether the content processor is processing the
right image of a stereo presentation.
If used in a document instance, then a usesStereo
named metadata item should be specified as a child of the head element.

8.3.3 <condition>

A <condition> value is used to specify an expression that evaluates to a binary value
which is used to determine if the semantics of a
conditionalized element is respected or ignored during content processing.

When de-quoted, the parameter-name argument of a <parameter-function> value expression must adhere to an
xsd:token, which must, in turn, be one of the values enumerated
by <bound-parameter>.

A <parameter-function> value expression evaluates to the value associated with (bound to) the
specified paramater name.

8.3.9 <supports-function>

A <supports-function> value is a sub-expression that may be used in a <condition> value expression
in order to obtain a boolean value that denotes whether a specified feature or extension
is supported or not.

The feature-or-extension-designator argument of a <supports-function> value expression must express
a feature designation or an extension designation as defined by
E.1 Feature Designations and F.1 Extension Designations, respectively, and where the
feature-namespace or extension-namespace component of the designation is optional, and, if
not specified, is considered to be equal to the TT Feature Namespace or TT Extension Namespace,
respectively.

A <supports-function> value expression evaluates to true if the specified feature or extension
designator is (semantically) supported by the content processor.

9 Embedded Content

This section specifies the embedded content matter of the core
vocabulary catalog, where, in this context,
content is to be understood as data of an arbitrary content type (format)
and embedded refers to the embedding (inlining) of this data or the embedding
of a reference to external data.

9.1 Embedded Content Element Vocabulary

The 9.1.3 data element serves as
a generic container element for an embedded data resource, which may or may not be fragmented into chunks,
in which case a data fragment is represented using the 9.1.2 chunk element.
The 9.1.1 audio,
9.1.4 font, and
9.1.5 image elements are specialized elements used to
to reference specific types of embedded content.
The 9.1.6 resources element is used to
group definitions of embedded content for reference by subsequent elements.
The 9.1.7 source element may be used to
express the source of embedded content.

9.1.1 audio

The audio element is used to define an author supplied audio resource.

When an audio element appears in an audio presentation context, it
serves as a non-sharable definition of an audio resource that implies presentation (rendering) semantics, i.e., that it is intended to be played.
In this case, the active time interval of the audio element is the same as the active time interval of its parent
content element.

Note:

A non-sharable definition of an audio resource may or may not specify an xml:id attribute, but this
identifier is not referenced by other audio elements, or, if it is, the reference is ignored.

The audio element accepts as its children
zero or more elements in the Metadata.class element group followed by zero or more
source elements.

If an audio element specifies a src attribute, then it must not specify a
child source element. Conversely,
if an audio element does not specify a src attribute, then it must specify one or more
child source elements.

If an audio element specifies a src attribute and its value does not refer to a fragment of the
enclosing document instance, then it should specify a
a type attribute, in which case the value of the
type attribute must correspond with the media (content) type
of the referenced resource. Otherwise, a type attribute must not be specified.

If a type attribute is not specified or is specified as a generic type, such as application/octet-stream,
and additional format information is known about a referenced audio resource, then a format attribute should be specified as a hint to the
content processor.

If an audio element includes a child source element, then
the format attribute of the source child, if specified, must adhere to the <audio-format>
value expression.

If an encoding attribute is specified, then it must denote the actual encoding of the byte sequence represented by the
chunk element. If no encoding attribute is specified, then the encoding must be considered to be base64.

If a length attribute is specified, then it must denote the number of decoded bytes in the byte sequence represented by the
chunk element. When decoding, if a specified length value does not match the number of decoded bytes, then the chunk and its container data
element must return a zero length byte sequence.
If no length attribute is specified, then the chunk is considered to have a length equal to the actual number of decoded bytes.

When a data element appears in a data defining context, it
serves as a sharable definition of a data resource that may be referenced by the src attribute of
(1) another data element,
(2) an embedded content element, or
(3) a source element.
In this case, the contextualized active time interval of the data element is the intersection of
the active time interval of its parent resources element and
the active time interval of its referring element.

Note:

A sharable definition of a data resource specifies an xml:id attribute in order to be referenced
by a fragment identifier used in a data binding context.

When a data element appears in a data binding context, it
serves as a non-sharable definition of a data resource that implies binding semantics, i.e., that it is intended to bound to (associated with) its immediate context
of reference. In this case, the active time interval of the data element is the same as the active time interval of its closest ancestor timed element.

Note:

A non-sharable definition of a data resource may or may not specify an xml:id attribute, but this
identifier is not referenced in other data binding contexts, or, if it is, has no binding semantics.

If simple data embedding is used, i.e., the content of the data element is one or more text nodes, then an
encoding attribute
may be specified, and, if not specified, must be considered to be base64.
If chunked or sourced data embedding is used, i.e., the content of the data element contains any child
chunk or source element, then
an encoding attribute must not be specified, and, if specified, must be ignored
for the purpose of content processing.

If a length attribute is specified, then it must denote the number of decoded bytes in the byte sequence represented by the
data element. When decoding, if a specified length value does not match the number of decoded bytes, then a zero length byte sequence must be returned.
If no length attribute is specified, then the data resource is considered to have a length equal to the actual number of decoded bytes.
A length attribute must not be specified when using sourced data embedding.

Note:

The intention of the length attribute is to provide a means to perform a simple integrity check on decoded data. Note that this check does not guarantee
data integrity during transport, i.e., the data could be modified without modifying the length.

If simple or chunked data embedding is used, a type attribute must be specified,
and must correspond with the media (content) type of the data resource. In these cases, if there is no defined type, the type application/octet-stream
should be used. In the case of sourced data embedding, the media (content) type of the resolved source element
is used as the type.

If a type attribute is not specified or resolved or is specified as a generic type,
such as application/octet-stream, and additional format information is known about a referenced data resource,
then a format attribute should be specified as a hint to the content processor.

The use of simple data embedding is illustrated by the following examples.

If a font element specifies a src attribute, then it must not specify a
child source element. Conversely,
if a font element does not specify a src attribute, then it must specify one or more
child source elements.

If a font element specifies a src attribute and its value does not refer to a fragment of the
enclosing document instance, then it should specify a
a type attribute, in which case the value of the
type attribute must correspond with the media (content) type
of the referenced resource. Otherwise, a type attribute must not be specified.

If a type attribute is not specified or is specified as a generic type, such as application/octet-stream,
and additional format information is known about a referenced font resource, then a format attribute should be specified as a hint to the
content processor.

Note:

A font format hint might be useful to a content processor to avoid accessing a font resource it knows it cannot decode.

If a font element includes a child source element, then
the format attribute of the source child, if specified, must adhere to the <font-format>
value expression.

If any of the family, range, style, or weight attributes are specified, then
they override the family name, supported character ranges, style, and weight of the actual font resource. In particular,
if the specified attribute value(s) differ from the value(s) of these font characteristics as encoded in the font resource, then
the specified attribute value(s) are to be used instead of the font characteristics encoded in the font resource.

If any of the family, range, style, or weight attributes are not specified, then their values
must be considered to be equal to the value(s) of the same named font characteristics encoded in the font resource.

Note:

Authors are advised to use subset fonts wherever possible. A subset font is a syntactically valid font resource that
removes unreferenced glyphs and unreferenced glyph metrics. In general, a subset font is tied to a specific document, since it may have been generated
based on the actual character content of that document.

When an image element appears in an image presentation context, it
serves as a non-sharable definition of an image resource that implies presentation (rendering) semantics.
In this case, the active time interval of the image element is the same as the active time interval of its parent
content element.

Note:

A non-sharable definition of an image resource may or may not specify an xml:id attribute, but this
identifier is not referenced by other image elements, or, if it is, the reference is ignored.

When an image element appears as a child of a div element, then its presentation
produces a block area in which the image is rendered; i.e., a block boundary is implied before and after the image element. In contrast,
when an image element appears as a child of a p or span
element, then its presentation produces an inline area in which the image is rendered; i.e., no block boundary is implied before and after the image element.

Note:

In [CSS2], these semantics would correspond to an image element being associated with a display style property with a
value of block or inline, respectively.

If an image element specifies a src attribute, then it must not specify a
child source element. Conversely,
if an image element does not specify a src attribute, then it must specify one or more
child source elements.

If an image element specifies a src attribute and its value does not refer to a fragment of the
enclosing document instance, then it should specify a
a type attribute, in which case the value of the
type attribute must correspond with the media (content) type
of the referenced resource. Otherwise, a type attribute must not be specified.

If a type attribute is not specified or is specified as a generic type, such as application/octet-stream,
and additional format information is known about a referenced image resource, then a format attribute should be specified as a hint to the
content processor.

If an image element includes a child source element, then
the format attribute of the source child, if specified, must adhere to the <image-format>
value expression.

An image element may specify an tts:extent
style attribute in order to specify the presentation width or height of the image
when intrinsic width or height information is not available or is intended to be overridden. If this attribute is specified on both an
image element in an image presentation context and on the
image element in an image defining context to which the former refers, then
the attribute specified on the former takes precedence over the one specified on the latter.

The linking attributes xlink:* may be used to link an image element with related content, using the
specified location (href), roles, and title. The behavior of link activation is affected by the xlink:show attribute,
the precise meaning of which is determined by the document processing context.

The use of the image element is illustrated by the following examples.

Example Fragment – External Image Resources

<div>
<p>This division has a content image that appears as a block area after this paragraph.</p>
<image src="http://example.com/images/caption.png" type="image/png"/>
<div>
...
<div tts:backgroundImage="http://example.com/images/background.png">
<p>This division has a background image that appears under this paragraph.</p>
<div>
...

If a format attribute is specified, then it provides additional hint information about the format (i.e., formal syntax) of the
embedded content. Such information may be useful in cases where no standard media (content) type label has been defined. Depending on the
context of use of a source element, the values of this attribute may be further constrained.

If a src attribute is specified and its value refers to a fragment of the enclosing document instance,
then there must be a data element child of a resources
element which is identified by that fragment, i.e., has an xml:id attribute the value of which matches the fragment identifier.

If a src attribute is specified and its value does not refer to a fragment of the
enclosing document instance, then
a type attribute should be specified, in which case it must correspond with the media (content) type
of the referenced resource.

If a src attribute is specified and its value does refer to a fragment of the
enclosing document instance, then
a type attribute must not be specified; rather, the content type of the embedded resource is determined by
the value of the type attribute on the referenced or embedded
data element.

The use of the source element is illustrated by the following examples.

If specified, the value of a type attribute must adhere to the value syntax of the Content-Type
MIME header defined by [MIME], §5.1.

If not specified, then the media (content) type is unknown or deliberately unspecified.

When decoding a data resource for which a type attribute is specified, then content processing
must respect the specified type whether it is correct or not. That is, if a type attribute mis-specifies the
type of a data resource, then content processing must not attempt to override that type by performing content
sniffing.

9.3 Embedded Content Value Expressions

Embedded content elements as well as certain style property values make use of the following expressions:

If a format expression takes the form of an xsd:anyURI,
then it must express an absolute URI.

Note:

This specification does not standardize the set of format tokens for use with audio content. Authors are encouraged to
use tokens in common use, or absent that, to add a prefix "x-" to form a private use token.

9.3.3 <data>

A <data> value expression is used to specify a data resource by reference.

If a format expression takes the form of an xsd:anyURI,
then it must express an absolute URI.

Note:

This specification does not standardize the set of format tokens for use with data content. Authors are encouraged to
use tokens in common use, or absent that, to add a prefix "x-" to form a private use token.

If a format expression takes the form of an xsd:anyURI,
then it must express an absolute URI.

Note:

This specification standardizes a limited set of format tokens for use with font content. In case none of
these tokens are appropriate, authors are encouraged to use tokens in common use, or absent that, to add a
prefix "x-" to form a private use token.

9.3.7 <image>

An <image> expression is used to specify an image resource by reference.

If a format expression takes the form of a xsd:anyURI,
then it must express an absolute URI.

Note:

This specification does not standardize the set of format tokens for use with image content. Authors are encouraged to
use tokens in common use, or absent that, to add a prefix "x-" to form a private use token.

9.3.9 <unicode-range>

A <unicode-range> expression is used to specify a collection of Unicode codepoints by enumerating singleton codepoints or ranges of codepoints.

10 Styling

This section specifies the styling matter of the core
vocabulary catalog, where
styling is to be understood as a separable layer of information that applies to
content and that denotes authorial intentions about the presentation of
that content.

Styling attributes are included in TTML to enable authorial intent of presentation
to be included within a self-contained document. This section describes
the semantics of style presentation in terms of a standard processing
model. TTML Processors are not required to present document instances in any particular way;
but an implementation of this model by a TTML presentation processor
that provides externally observable results that are consistent with this model is
likely to lead to a user experience that closely resembles the experience intended by
the documents' authors.

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

No normative use of an
<?xml-stylesheet ... ?> processing instruction is defined
by this specification.

10.1 Styling Element Vocabulary

The following elements specify the structure and principal styling aspects of a
document instance:

That is to say, when referential styling is used by an element to
refer to a style element, then the referenced style
element must appear as a descendant of the styling element, and
not in any other context.

10.1.3 styling

The styling element is a container element used to group
styling matter, including metadata that applies to styling matter.

The styling element accepts as its children zero or more
elements in the Metadata.class element group,
followed by zero or more initial elements,
followed by zero or more style elements.

10.2 Styling Attribute Vocabulary

In addition, this section specifies the following attributes in the TT Style Namespace
for use with style definition elements, certain layout elements, and content elements
that support inline style specifications:

Consider adding support for tts:backgroundClip,
tts:backgroundOrigin, and
tts:backgroundSize.

Unless explicitly permitted by an element type definition, an attribute in the TT Style Namespace should not be specified on an element
unless it either applies to that element or denotes an inheritable style property. If it does not apply to that element
and does not denote an inheritable style property, then it must be ignored for the purpose of non-validation processing.
In the case of validation processing, such usage should be reported as a warning, or, if strict validation is performed,
as an error.

Unless explicitly stated otherwise, linear white-space (LWSP) must
appear between adjacent non-terminal components of a value of a TT
Style property value unless some other delimiter is permitted and used.

Note:

This specification makes use of lowerCamelCased local
names for style attributes that
are based upon like-named properties defined by [XSL 1.1].
This convention is likewise extended to token values of such
properties.

Note:

An inheritable style property may be expressed as a specified attribute on the
root tt element or on a
content element type
independently of whether the property applies to that
element type. This capability permits the expression of an inheritable
style property on ancestor elements to which the property
does not apply.

Note:

Due to the general syntax of this specification (and the schemas it references) with respect
to how style attributes are specified, particularly for the purpose of supporting inheritance,
it is possible for an author to inadvertently specify a non-inheritable style attribute on
an element that applies neither to that element or any of its descendants while still remaining
conformant from a content validity perspective. Content authors may wish to make use of TTML
content verification tools that detect and warn about such usage.

10.2.1 style

The style attribute is used by referential style association
to reference one or more style elements each of which define a style (property) set.

The style attribute may be specified by an instance of the following
element types:

If specified, the value of a style attribute must
adhere to the IDREFS data type defined by [XML Schema Part 2],
§ 3.3.10, and, furthermore, each IDREF must reference a style element
which has a styling element as an ancestor.

If the same IDREF, ID1, appears more than one time in the value of a style
attribute, then there should be an intervening IDREF, ID2, where
ID2 is not equal to ID1.

Note:

This constraint is intended to discourage the use of redundant referential styling while still
allowing the same style to be referenced multiple times in order to potentially override prior
referenced styles, e.g., when an intervening, distinct style is referenced in the IDREFS list.

Fix definition of block progression dimension of background area of a line area. Neither XSL-FO nor CSS are sufficiently precise.

Resolution:

None recorded.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

The semantics of the style property represented by this attribute are based upon
that defined by [XSL 1.1], § 7.8.2.

10.2.3 tts:backgroundImage

The tts:backgroundImage attribute is used to specify a style property that
designates a background non-content image to be rendered as
the background image of a region or an area generated by content flowed into a region.

A tts:backgroundImage attribute should not make reference to a content image
used to represent actual content, such as a raster image rendering of a caption. Rather, the use of tts:backgroundImage
should be limited to styling the background of an element where the content is represented by other means. If it is necessary
to represent content using a raster image, then it should be expressed by means of an image
element in a block or inline context.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

An <image> expression used with this style property may directly reference an external image resource;
however, authors should refrain from doing so, and instead, constrain their usage to only refer to image
children of a resources element.

Note:

Referring indirectly to an image by means of an image element makes it possible to
specify an image as an embedded data resource, and specify
additional information about the image, such as its content type, etc. Furthermore, by exploiting the use of multiple
source children in an image element,
it becomes possible to specify resolution specific images and fallback image resources.

The tts:backgroundImage style is illustrated by the following example.

The semantics of the style property represented by this attribute are based upon
that defined by [XSL 1.1], § 7.8.3.

10.2.4 tts:backgroundPosition

The tts:backgroundPosition attribute is used to specify a style property that
defines whether and how a background image is positioned in a region or an area generated by content flowed into a region.

This attribute may be specified by any element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

A percentage value component for a horizontal position offset is relative to the width of the
positioning area minus the width of the background image.
A percentage value component for a vertical position offset is relative to the height of the
positioning area minus the height of the background image.
The positioning area corresponds with the padding rectangle (padding box) of each area generated
by applicable element.

The tts:backgroundPosition style is illustrated by the following example.

The semantics of the style property represented by this attribute are based upon
that defined by [CSS2], § 14.2.

10.2.5 tts:backgroundRepeat

The tts:backgroundRepeat attribute is used to specify a style property that
defines whether and how a background image is repeated (tiled) into a region or an area generated by content flowed into a region.

This attribute may be specified by any element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

The semantics of the style property represented by this attribute are based upon
that defined by [XSL 1.1], § 7.8.4.

10.2.6 tts:border

The tts:border attribute is used to specify a style property that
defines the border of a region or an area generated by content flowed into a region.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

If no border thickness is specified in the value of the tts:border property,
then the border thickness must be interpreted as if a thickness of
medium were specified.

If a computed value of the border thickness associated with this attribute is not supported,
then a presentation processor must use the closest supported value.

Note:

In this context, the phrase closest supported value means the value for which the one-dimensional Euclidean distance between
the computed border thickness and the supported border thickness is minimized on a per-edge basis. If there are multiple closest supported values equally distant from
the computed value for a given edge, then the value least distant from 0, i.e., the least border thickness, is used.

If no border style is specified in the value of the tts:border property,
then the border style must be interpreted as if a style of
none were specified.

If a computed value of the border style associated with this attribute is not supported,
then a presentation processor must use the value solid.

If no border color is specified in the value of the tts:border property,
then the border color must be interpreted as if a color equal
to the computed value of the element's tts:color style property were specified.

The semantics of the style property represented by this attribute are based upon
that defined by [XSL 1.1], § 7.31.3.

10.2.7 tts:bpd

The tts:bpd attribute is used to specify the
block progression dimension, or, more succinctly, the bpd of an area generated by content flowed into a region.

Note:

The term block progression dimension is interpreted in a writing mode relative manner
such that bpd always corresponds to a measure in the block
progression direction. Therefore, in horizontal writing modes, bpd expresses a vertical measure,
while, in vertical writing mode, bpd expresses a horizontal measure,
where horizontal and vertical are always interpreted in an absolute sense.

If a tts:bpd attribute is specified on a span element,
then that span element must be processed using
inline block display semantics for the purpose of presentation processing.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

The semantics of the style property
represented by this attribute are based upon the height property defined by [XSL 1.1],
§ 7.15.6 and [CSS Box Model], § 9

10.2.8 tts:color

The tts:color attribute is used to specify a style property that
defines the foreground color of marks associated with an area generated by content flowed into a region.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

The initial value of the tts:color property
is considered to be implementation dependent. In the absence of
end-user preference information, a conformant presentation processor
should use an initial value that is highly contrastive to the
background color of the root container region.

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.18.1.

10.2.9 tts:direction

The tts:direction attribute is used to specify a style property that
defines the directionality of an embedding or override according to
the Unicode bidirectional algorithm.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.29.1.

10.2.10 tts:disparity

The tts:disparity attribute is used to specify the binocular disparity to be applied
in order to simulate stereopsis (stereoscopic depth).

This attribute may be specified by any element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

If specified, the value of this attribute consists of a <length> specification, the computed value
of which is evenly divided along the horizontal axis between left and right stereoscopic images.

If a tts:disparity attribute is specified on a div or p element, then that specification must be considered to be
equivalent to specifying an anonymous inline region child of the div or p element, where the
disparity of the corresponding region, also referred to as an implied inline region, is equal to the
value of this attribute.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the closest supported value.

Note:

In this context, the phrase closest supported value means the value for which the Euclidean distance between
the computed disparity and the supported disparity is minimized. If there are multiple closest supported values equally distant from
the computed value, then the value least distant from 0 is used.

10.2.11 tts:display

The tts:display attribute is used to specify a style property that
defines whether an element is a candidate for layout and composition
in a region.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

If the value of this attribute is auto,
then the affected element is a candidate for region layout and
presentation; however, if the value is none, then the
affected element and its descendants must be considered ineligible for region
layout and presentation.

The semantics of the style property
represented by this attribute are based upon that defined by [CSS2], § 9.2.4.

10.2.12 tts:displayAlign

The tts:displayAlign attribute is used to specify a style property that
defines the alignment of block areas in the block progression direction.

Editorial note: Justification in Block Progression Dimension

2015-01-14

Add justify value to support justification in block progression dimension.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

to specify or override the width and (or) height of an image's intrinsic extent.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

If the value of this attribute consists of two <measure>
specifications, then they must be interpreted as width
and height, where the first specification is the
width, and the second specification is the height.

Define semantics of new contain and cover values. Exclude these values from use with an image element.

The extent of the root container region is determined either by a
tts:extent specified on the tt element, if
present, or as described by 8.1.1 tt if not present.
If tts:extent is specified on the tt element, then
the width and height must be expressed in terms of two <length> specifications,
and these specifications must be expressed as non-percentage, definite lengths using pixel units.

If a tts:extent attribute is specified on a div or p element, then that specification must be considered to be
equivalent to specifying an anonymous inline region child of the div or p element, where the
extent of the corresponding region, also referred to as an implied inline region, is equal to the
value of this attribute.

If a tts:extent attribute is specified on an image element, then its computed value determines or overrides the image's intrinsic
width and (or) height.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the closest supported value.

Note:

In this context, the phrase closest supported value means the value for which the Euclidean distance between
the computed extent and the supported extent is minimized. If there are multiple closest supported values equally distant from
the computed value, then the value most distant from [0,0], i.e., of greatest extent, is used.

This rule for resolving closest supported value makes use of the nearest larger rather than nearest smaller supported distance.
The rationale for this difference in treatment is
that use of a larger extent ensures that the affected content will be contained in the region area without causing region overflow,
while use of a smaller extent makes region overflow more likely.

10.2.14 tts:fontFamily

The tts:fontFamily attribute is used to specify a style property that
defines the font family from which glyphs are selected for glyph areas generated
by content flowed into a region.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

If a computed value of the property associated with this attribute is not supported, then a
presentation processor must attempt to map the computed font family
to a supported font family that has similar typographic
characteristics, or, in the absence of such a mapping, it must
use the value default.

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.9.2.

10.2.15 tts:fontKerning

The tts:fontKerning attribute is used to specify a style property that
determines whether font kerning is applied when positioning glyph areas.

This attribute may be specified by any element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

If the value of this attribute is normal, then kerning should be applied if kerning data is available.
If the value of this attribute is none, then kerning should not be applied whether or not kerning data is available.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the value normal.

The tts:fontKerning style is illustrated by the following
example.

Editorial note: Font Kerning Example

2015-01-05

Insert example fragment and image of tts:fontKerning.

Note:

The semantics of the style property
represented by this attribute are based upon that defined by [CSS Fonts],
§ 6.3.

10.2.17 tts:fontShear

The tts:fontShear attribute is used to specify a style property that
determines whether and how a shear transformation is applied to glyph areas.

This attribute may be specified by any element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

If the value of this attribute is 0%, then no shear transformation is applied; if the value is 100%, then a 2D shear transformation
of 90 degrees is applied in the axis associated with the inline progression direction; if the value is -100%, then a shear transformation
of -90 degrees is applied. If the absolute value of the specified percentage is greater than 100%, then it must be interpreted as if 100% were specified with
the appropriate sign.

If the inline progression direction corresponds to the X axis, then the 2D shear transformation is described by the following matrix:

| 1 a 0 |
| 0 1 0 |
| 0 0 1 |

where a is equal to the tangent of the shear angle.

If the inline progression direction corresponds to the Y axis, then the 2D shear transformation is described by the following matrix:

| 1 0 0 |
| a 1 0 |
| 0 0 1 |

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

The tts:fontShear style is illustrated by the following
example.

Editorial note: Font Shear Example

2015-01-07

Insert example fragment and image of tts:fontShear.

10.2.18 tts:fontSize

The tts:fontSize attribute is used to specify a style property
that defines the font size for glyphs that are selected for glyph areas
generated by content flowed into a region.

This attribute may be specified by any element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

If a single <length> value is specified, then this length applies
equally to horizontal and vertical scaling of a glyph's EM square; if two
<length> values are specified, then the first expresses the horizontal
scaling and the second expresses vertical scaling.

Note:

Use of independent horizontal and vertical font sizes is expected to be used
with cell based units in order to denote fonts that are two rows in height and
one column in width.

Note:

A glyph's EM square is conventionally defined as the EM square of the font that contains the glyph. That is,
glyphs do not have an EM square that is distinct from their font's EM square.

If horizontal and vertical sizes are expressed independently, then the
units of the <length> values must be the same.

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the closest supported value.

Note:

In this context, the phrase closest supported value means the value for which the Euclidean distance between
the computed font size and the supported font size is minimized. If there are multiple closest supported values equally distant from
the computed value, then the value most distant from 0 (single length specification) or [0,0] (two length specifications) is used,
i.e., the largest font size, is used.

Note:

The expression 1c means one cell, where 'c' expresses
the cell length unit as defined by 10.3.14 <length>.
When a single <length> is expressed using cell units, then it refers to the height of
the computed cell size.
When two <length> values are expressed using cell units, then the first refers to the width of
the computed cell size, and the second refers to the height of the
computed cell size.

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.9.4. The addition of a second length component to permit specifying font
width and height independently is an extension introduced by TTML.

10.2.19 tts:fontStyle

The tts:fontStyle attribute is used to specify a style property that
defines the font style to apply to glyphs that are selected for glyph areas generated
by content flowed into a region, where the mapping from font
style value to specific font face or style parameterization is not determined
by this specification.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.9.7.

10.2.20 tts:fontVariantPosition

The tts:fontVariantPosition attribute is used to enable the selection
of typographic subscript and superscript glyphs.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the value normal.

Editorial note: Font Position Variant Example

2014-09-24

Add example source and rendering of tts:fontVariantPosition.

Note:

The semantics of the style property
represented by this attribute are based upon that defined by [CSS Fonts],
§ 6.5.

10.2.21 tts:fontWeight

The tts:fontWeight attribute is used to specify a style property
that defines the font weight to apply to glyphs that are selected for glyph
areas generated by content flowed into a region, where the mapping from font
weight value to specific font face or weight parameterization is not determined
by this specification.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.9.9.

10.2.22 tts:ipd

The tts:ipd attribute is used to specify the
inline progression dimension, or, more succinctly, the ipd of an area generated by content flowed into a region.

Note:

The term inline progression dimension is interpreted in a writing mode relative manner
such that ipd always corresponds to a measure in the inline
progression direction. Therefore, in horizontal writing modes, ipd expresses a horizontal measure,
while, in vertical writing mode, ipd expresses a vertical measure,
where horizontal and vertical are always interpreted in an absolute sense.

If a tts:ipd attribute is specified on a span element,
then that span element must be processed using
inline block display semantics for the purpose of presentation processing.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

The semantics of the style property
represented by this attribute are based upon the width property defined by [XSL 1.1],
§ 7.15.14 and [CSS Box Model], § 9

10.2.23 tts:letterSpacing

The tts:letterSpacing attribute is used to specify a style property that
increases or decreases the nominal distance between glyph areas.

Letter spacing has no affect at the beginning or ending of a line area, and must not
be applied to zero-advance glyphs. Furthermore, letter spacing must not cause normally connected glyphs,
e.g., as used in cursive scripts or with cursive fonts, to become disconnected.

Letter spacing is applied independently from kerning and justification. Depending upon the font(s) in use,
the script(s) being presented, and the capabilities of a presentation processor, either or both kerning and
justification may be applied in addition to letter spacing.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

If a <length> value is expressed as a positive scalar,
then the spaces between adjacent glyphs are expanded by an additional amount equal to that scalar value.
If expressed as a negative scalar,
then the spaces between adjacent glyphs are compressed by an additional amount equal to that scalar value, possibly resulting
in overlapping glyph areas, up to a maximum amount that results an effective advance of zero (0).

If a computed value of the letter spacing associated with this attribute is not supported,
then a presentation processor must use the closest supported value.

Note:

In this context, the phrase closest supported value means the value for which the one-dimensional Euclidean distance between
the computed letter spacing and the supported letter spacing is minimized. If there are multiple closest supported values equally distant from
the computed value for a given edge, then the value least distant from 0 is used.

The tts:letterSpacing style is illustrated by the following
example.

Editorial note: Letter Spacing Example

2014-11-30

Insert example fragment and image of tts:letterSpacing.

Note:

The semantics of the style property
represented by this attribute are based upon that defined by [CSS Text],
§ 8.2.

10.2.24 tts:lineHeight

The tts:lineHeight attribute is used to specify a style property that
defines the inter-baseline separation between line areas generated by content flowed into a region.

Note:

Exceptionally, the term height in the token lineHeight or the phrase line height refers to
the axis that corresponds with the block progression dimension of an associated line area, which is the vertical axis in
horizontal writing modes, but is the horizontal axis in vertical writing modes.

Re-visit choice of 120% versus 125% for multiplier used in interpreting normal line height.

Resolution:

None recorded.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

If the value of this attribute is normal, then the
computed value of this style property is determined as follows:

Let P be the p element to which this style property applies.

Let FF be the computed value of the tts:fontFamily style property that applies to P.

Let FS be the computed value of the tts:fontSize style property that applies to P.

Let F0 be the first font obtained when sequentially mapping each font family in FF to a set of available fonts,
where this set of available fonts is constrained as needed to satisfy the computed values of the tts:fontStyle and tts:fontWeight
style properties that apply to P.

If F0 is associated with font metrics that specify altitude A, descent D, and line gap G,
then set LH to the sum of scaled(A), scaled(D), and scaled(G),
where scaled(X) denotes font metric X scaled according to font size FS.

Otherwise, set LH to 125% of FS.

Set the computed value of this style property to LH.

Note:

If a content author wishes to avoid the possibility of different interpretations of normal, for example, due to differences in
the set of available fonts, then it is recommended that a
<length> value expression be used to explicitly specify line height value.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the closest supported value.

Note:

In this context, the phrase closest supported value means the value for which the Euclidean distance between
the computed line height and the supported line height is minimized. If there are multiple closest supported values equally distant from
the computed value, then the value most distant from 0, i.e., the largest line height, is used.

The tts:lineHeight style is illustrated by the following example.

Example Fragment – Line Height

<region xml:id="r1">
<style tts:extent="255px 190px"/>
<style tts:backgroundColor="black"/>
<style tts:color="white"/>
<style tts:displayAlign="center"/>
<style tts:textAlign="start"/>
<style tts:fontFamily="proportionalSansSerif"/>
<style tts:fontSize="16px"/>
<style tts:lineHeight="32px"/>
</region>
...
<p region="r1">
He thought he saw an elephant,<br/>
That practised on a fife:<br/>
He looked again, and found it was<br/>
A letter from his wife.<br/>
"At length I realise," he said,<br/>
"The bitterness of Life.
"</p>

Example Rendition – Line Height

Note:

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.16.4. Furthermore, it is the intention of this specification that the
allocation rectangle of a line be consistent with the per-inline-height-rectangle
as defined by [XSL 1.1], § 4.5, i.e., that a CSS-style line box stacking strategy be used.

10.2.25 tts:opacity

The tts:opacity attribute is used to specify a style property that
defines the opacity (or conversely, the transparency)
of marks associated with a region or an area generated by content flowed into a region.

When presented onto a visual medium, the opacity of the region is applied uniformly and on a linear scale
to all marks produced by content targeted to the
region after having applied applied any content element specific opacity to areas generated by that content.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

The semantics of the style property
represented by this attribute are based upon that defined by [CSS3 Color],
§ 3.2.

10.2.26 tts:origin

The tts:origin attribute is used to specify the
x and y coordinates of the origin of a
region area with respect to the origin of the root container region.

If both tts:origin and tts:position attributes are
specified on an element and tts:position is a supported property,
then the tts:origin attribute must be ignored for the purpose of presentation processing.

This attribute may be specified by any element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

If the value of this attribute consists of two <length> specifications,
then they must be interpreted as x and y coordinates, where the first specification
is the x coordinate, and the second specification is the y coordinate.

If the value of this attribute is auto, then the computed value
of the style property must be considered to be the same as the origin of the root container region.

If a tts:origin attribute is specified on a div or p element, then that specification must be considered to be
equivalent to specifying an anonymous inline region child of the div or p element, where the
origin of the corresponding region, also referred to as an implied inline region, is equal to the
value of this attribute.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the closest supported value.

Note:

In this context, the phrase closest supported value means the value for which the Euclidean distance between
the computed origin and the supported origin is minimized. If there are multiple closest supported values equally distant from
the computed value, then the value least distant from [0,0], i.e., closest to the coordinate space origin, is used.

10.2.27 tts:overflow

The tts:overflow attribute is used to specify a style property that
defines whether a region area is clipped or not if the descendant areas of the region overflow
its extent.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

If the value of this attribute is visible, then content should
not be clipped outside of the affected region.
If the value is hidden, then content should
be clipped outside of the affected region.

Note:

Unless a manual line break element br is used by the content author,
a paragraph of a given region will generate no more than one line area in that
region if the computed values of the tts:overflow and tts:wrapOption
style properties of the region are visible and noWrap,
respectively.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the value hidden.

In the above example, the tts:noWrap is set to
noWrap to prevent automatic line wrapping (breaking);
if this were not specified, then overflow would occur in the block
progression direction as opposed to the inline progression direction.

Note:

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.21.2.

10.2.28 tts:padding

The tts:padding attribute is used to specify padding (or inset)
space on one or more sides of a region or an area generated by content flowed into a region.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

If the value of this attribute consists of one <length> specification,
then that length applies to all edges of the affected areas. If the value
consists of two <length> specifications, then the first applies to the
before and after edges, and the second applies to the start and end edges.
If three <length> specifications are provided, then the first applies to the
before edge, the second applies to the start and end edges, and the third applies
to the after edge.
If four <length> specifications are provided, then they apply to before, end,
after, and start edges, respectively.

If padding is applied to a span element, and content from that element
is divided across multiple line areas, then the specified padding must be applied at each line break boundary. In contrast,
within a single line area, if multiple inline areas are generated by the element, then the specified padding must be applied at
the first and/or last generated inline area within a line area the inline progression order of the containing block level element.

Note:

The behavior of padding on a span element corresponds with the use of
a CSS box-decoration-break property with the value clone at line breaks and the value slice
at non-terminal, i.e., non-first and non-last, inline area boundaries, as defined by [CSS Fragmentation], § 5.4.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the closest supported value.

Note:

In this context, the phrase closest supported value means the value for which the one-dimensional Euclidean distance between
the computed padding and the supported padding is minimized on a per-edge basis. If there are multiple closest supported values equally distant from
the computed value for a given edge, then the value least distant from 0, i.e., the least padding, is used.

The tts:padding style is illustrated by the following example.

Editorial note: Enhance Padding Example

2013-08-24

Enhance padding example to demonstrate padding on content elements.

Example Fragment – Padding

<region xml:id="r1">
<style tts:extent="446px 104px"/>
<style tts:backgroundColor="black"/>
<style tts:color="white"/>
<style tts:displayAlign="after"/>
<style tts:textAlign="center"/>
<style tts:padding="10px 40px"/>
</region>
...
<p region="r1" tts:backgroundColor="red">
Just the place for a Snark! I have said it twice:<br/>
That alone should encourage the crew.<br/>
Just the place for a Snark! I have said it thrice:<br/>
What I tell you three times is true.
</p>

When rendering an area to which padding applies, the background color that
applies to the area is rendered into the padded portion of the area.

Example Rendition – Padding

Note:

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.31.15, except that individual shorthand values map to writing
mode relative padding values as defined by [XSL 1.1],
§ 7.8.31, 7.8.32, 7.8.33, and 7.8.34.

10.2.29 tts:position

The tts:position attribute is used as an alternative way to specify the position
of a region area with respect the root container region.

If both tts:position and tts:origin attributes are
specified on an element and tts:position is a supported property,
then the tts:origin attribute must be ignored for the purpose of presentation processing.

This attribute may be specified by any element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

A percentage value component for a horizontal position offset is relative to the width of the
positioning area minus the width of the associated region.
A percentage value component for a vertical position offset is relative to the height of the
positioning area minus the height of the associated region.

The following image depicts a position value "75% 50%", where the rectangle with dashed line denotes the positioning area and the rectangle
with solid line denotes the region being positioned. In this case the region is positioned such that a vertical line located at 75% of its width coincides with
a vertical line located at 75% of the width of the positioning area, and a horizontal line located at 50% of its height coincides with
a vertical line located at 50% of the width of the posititoning area.

The root container region has no border or padding; consequently, its border, padding, and
content rectangles (boxes) are coterminous.

If a horizontal or vertical position offset is specified by a tts:position attribute in the form of a scalar value
on a tt element, then that value must be expressed using pixel (px) units,
in which case a pixel must be interpreted as a pixel in the presentation context coordinate space
(and not a pixel in the document coordinate space).

If a tts:position attribute is specified on a div or
p element, then that specification must be considered to be
equivalent to specifying an anonymous inline region child of the div or p element, where the
position of the corresponding region, also referred to as an implied inline region, is equal to the
value of this attribute.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the closest supported value.

Note:

In this context, the phrase closest supported value means the value for which the Euclidean distance between
the computed position and the supported position is minimized. If there are multiple closest supported values equally distant from
the computed value, then the value least distant from [0,0], i.e., closest to the coordinate space position, is used.

The tts:position style is illustrated by the following example, which positions a region so that it is
centered in the horizontal dimension and has a bottom edge 10% above the bottom of the positioning area in the vertical dimension.

The semantics of the style property represented by this attribute are based upon
the background-position property defined by [CSS Backgrounds and Borders], § 3.6.

10.2.30 tts:ruby

The tts:ruby attribute is used to specify the application of ruby
styling.

This attribute may be specified by any element type that permits use of attributes in the TT Style Namespace; however,
this attribute applies as a style property only to those element types indicated in the following table.

if the computed value of tts:ruby is container, then the
computed value of tts:ruby of all ancestor elements is none;

if the computed value of tts:ruby is container, then the
computed value of tts:ruby of its first child element is baseContainer
or base;

if the computed value of tts:ruby is baseContainer, then the
computed value of tts:ruby of its parent element is container;

if the computed value of tts:ruby is baseContainer, then the
computed value of tts:ruby of its first child element is base;

if the computed value of tts:ruby is baseContainer, then its
preceding sibling is null (i.e., no preceding sibling);

if the computed value of tts:ruby is textContainer, then the
computed value of tts:ruby of its parent element is container;

if the computed value of tts:ruby is textContainer, then the
computed value of tts:ruby of its first child element is either text or delimiter;

if the computed value of tts:ruby is textContainer, then the
computed value of tts:ruby of its preceding sibling is baseContainer or
textContainer;

if the computed value of tts:ruby is textContainer, then the
computed value of tts:ruby of no more than one sibling is textContainer;

if the computed value of tts:ruby is base, then the
computed value of tts:ruby of its parent element is either container or
baseContainer;

if the computed value of tts:ruby is base, then its
preceding sibling is either null (i.e., no preceding sibling) or the
computed value of tts:ruby of its preceding sibling is base;

if the computed value of tts:ruby is base and the
computed value of tts:ruby of its parent element is container,
then the computed value of tts:ruby of no sibling is base;

if the computed value of tts:ruby is base, then the
computed value of tts:ruby of no descendant element is not none;

if the computed value of tts:ruby is text, then the
computed value of tts:ruby of its parent element is either container or
textContainer;

if the computed value of tts:ruby is text, then the
computed value of tts:ruby of its preceding sibling is base,
text, or delimiter;

if the computed value of tts:ruby is text and the
computed value of tts:ruby of its parent element is container,
then the computed value of tts:ruby of no sibling is text;

if the computed value of tts:ruby is text, then the
computed value of tts:ruby of no descendant element is not none;

if the computed value of tts:ruby is delimiter, then the
computed value of tts:ruby of its parent element is either container or textContainer;

if the computed value of tts:ruby is delimiter, then the
computed value of tts:ruby of its preceding sibling is base or
text;

if the computed value of tts:ruby is delimiter, then the
computed value of tts:ruby of exactly one sibling is delimiter;

if the computed value of tts:ruby is delimiter, then the
computed value of tts:ruby of no descendant element is not none;

A validating processor must treat a violation of any of the above constraints as an error.
For the purpose of presentation processing, the violation of any of these constraints should result in fallback (inline)
presentation of ruby text annotations.

The semantics of the style property
represented by this attribute are based upon that defined by [Ruby] and [CSS Ruby]. See also
[JLREQ], §3.3, for further information.

10.2.31 tts:rubyAlign

The tts:rubyAlign attribute is used to specify the position of ruby text within the inline area generated by the ruby text container annotation.

This attribute may be specified by any element type that permits use of attributes in the TT Style Namespace; however,
this attribute applies as a style property only to those element types indicated in the following table.

If the value of this attribute is start, then the start edge of the first glyph area descendant of an inline area generated from a ruby text container
or ruby text annotation is aligned to the start edge of that inline area.
If the value is center, then excess whitespace
is equally distributed before and after the first and last glyphs, respectively.
If the value is spaceBetween, then excess whitespace
is equally distributed between each glyph area descendant.
If the value is spaceAround, then excess whitespace
is equally distributed before and after each glyph area descendant.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the value spaceAround.

Editorial note: Ruby Align Example

2014-09-20

Add example source and rendering of tts:rubyAlign.

Note:

The semantics of the style property
represented by this attribute are based upon that defined by [CSS Ruby], §4.3, and the examples and example
renderings shown there apply.

10.2.32 tts:rubyOffset

The tts:rubyOffset attribute is used to specify the offset (distance) of ruby text with respect to its associated ruby base
in the block progression dimension.

This attribute may be specified by any element type that permits use of attributes in the TT Style Namespace; however,
this attribute applies as a style property only to those element types indicated in the following table.

If specified, the value of tts:rubyOffset expresses the offset (distance) between padding edge E1 of the inline area
generated by a ruby text container (explicit or implied) and padding edge E2 of the inline area generated by a ruby base container (explicit or implied), where
E1 and E2 are perpendicular to the block progression direction and are (or would be) adjacent in the absence of
such an offset.

Negative length expressions are permitted.

Editorial note: Ruby Offset Example

2014-10-02

Add example source and rendering of tts:rubyOffset.

10.2.33 tts:rubyPosition

The tts:rubyPosition attribute is used to specify the position of ruby text in the block progression dimension
with respect to its associated ruby base.

Editorial note: Outside Annotations

2015-01-14

Add auto and outside values as defined by <emphasis-position> expressions.

This attribute may be specified by any element type that permits use of attributes in the TT Style Namespace; however,
this attribute applies as a style property only to those element types indicated in the following table.

If the value of this attribute is before, then an inline area generated from a ruby text container or ruby text annotation
is placed before (prior to) the first edge in the block progression dimension of the inline area generated from an associated ruby base container or ruby base annotation.
If the value is after, then an inline area generated from a ruby text container or ruby text annotation
is placed after (subsequent to) the second edge in the block progression dimension of the inline area generated from an associated ruby base container or ruby base
annotation.

The absolute position of the ruby text container or ruby text annotation is determined
in accordance to the computed value of the tts:writingMode style property of the region into which the affected content is placed; in particular, the
mappings defined enumerated by Table 8-2 – Ruby Position Semantics Mapping by Writing Mode apply as further defined by [CSS Ruby], §4.1.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the value before.

Table 8-2 – Ruby Position Semantics Mapping by Writing Mode

tts:rubyPosition

lrtb

rltb

tbrl

tblr

before

over

over

right

left

after

under

under

left

right

Editorial note: Ruby Position Example

2014-09-20

Add example source and rendering of tts:rubyPosition.

Note:

The semantics of the style property
represented by this attribute are based upon that defined by [CSS Ruby], §4.1, and the examples and example
renderings shown there apply modulo the mappings defined above.

10.2.34 tts:showBackground

The tts:showBackground attribute is used to specify
constraints on when the background color of a region is intended to be
presented.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

If the value of this attribute is always, then the
background color of a region is always rendered when performing presentation
processing on a visual medium; if the value is whenActive,
then the background color of a region is rendered only when some
content is flowed into the region.

The semantics of the style property
represented by this attribute are based upon that defined by [SMIL 3.0],
§ 7.4.2.

10.2.35 tts:textAlign

The tts:textAlign attribute is used to specify a style property that
defines how inline areas are aligned within a containing block area in the inline progression
direction.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

The tts:textAlign attribute is inheritable only on a p element. If not
specified on a span element, then the tts:textAlign style property does not apply to that
element, rather, normal inline composition and alignment apply.

If a tts:textAlign attribute is specified on a span element,
then that span element must be processed using
inline block display semantics for the purpose of presentation processing.

Note:

A tts:textAlign attribute may be used on a span element in order
to force composition using inline block display semantics and to apply a different alignment
to the resulting nested block area. For example, a paragraph may be composed using center text alignment, while the text content within the paragraph, if
wrapped in a span, may be composed using left text alignment.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the value start.

Insert example fragment and image of use of tts:textAlign on a span element.

Note:

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.16.9.

10.2.36 tts:textCombine

When a vertical writing mode applies, the tts:textCombine attribute is used to specify a style property that
determines whether and how multiple nominally non-combining characters are combined so that their glyph areas
consume the nominal bounding box of a single em square of the surrounding vertical text.
If a horizontal writing mode applies, then this property is ignored
for the purpose of presentation processing.

Combination processing may make use of one or more techniques to obtain the goal of visual combination into an em square of the surrounding vertical text.
For example, half-width variant forms may be selected, a ligature may be selected, a smaller font size may be applied, etc. At a minimum, an
implementation that supports this style property must be able to select half-width variant forms if available. If none of these techniques are
able to achieve the target dimension along the block progression dimension of the containing line area, then this dimension of the containing line area may be increased if
permitted by the line stacking strategy in effect.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

If the specified value of this attribute is none, then no combination processing applies.
If the specified value of this attribute is all, then all affected characters should be combined.
If the specified value of this attribute is digits, then all affected characters should be combined if they are a sequence of a digits which length is
equal to or less than a specified count, or two (2) if no count is specified.

Combination must not cross an element boundary, a bidirectional boundary, or a non-glyph area boundary.

This attribute has no impact on or interaction with the nominal layout of glyph areas that constitute a Unicode combining character sequence.

Editorial note: Text Combine Example

2015-01-05

Insert example fragment and image of tts:textCombine.

Note:

The semantics of the style property represented by this attribute are based upon
that defined by [CSS Writing Modes], § 9.1.

10.2.37 tts:textDecoration

The tts:textDecoration attribute is used to specify a style property that
defines a text decoration effect to apply to glyph areas or other inline
areas that are generated by content flowed into a region.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

For the purpose of determining applicability of this
style property, each character child of a p element is
considered to be enclosed in an anonymous span.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the value none.

Note:

The syntax used above in defining the value of this property is based on the
value component syntax defined in [CSS2], § 1.4.2.1. In essence,
one or more of the values separated by || may appear in the property
value in any order, such as "noUnderline overline lineThrough".

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.17.4.

10.2.38 tts:textEmphasis

The tts:textEmphasis attribute is used to specify a style property that
determines whether and how text emphasis marks are presented on affected content.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

If the specified value of this attribute is auto, then it must be interpreted as if
auto were specified for both emphasis style and emphasis position components.

If no emphasis style is specified,
then the emphasis style must be interpreted as if a style of auto were specified.
If no emphasis color is specified,
then the emphasis color must be interpreted as if a color of current were specified.
If no emphasis position is specified,
then the emphasis position must be interpreted as if a position of auto were specified.

Editorial note: Text Emphasis Example

2015-01-05

Insert example fragment and image of tts:textEmphasis.

Note:

The semantics of the style property represented by this attribute are based upon
that defined by [CSS Text Decoration], § 3.

10.2.39 tts:textOrientation

The tts:textOrientation attribute is used to specify a style property that
defines a text orientation to apply to glyphs that are selected for glyph areas generated
by content flowed into a region to which a vertical writing mode applies.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

If the value of this attribute is mixed, then, in vertical writing modes,
glyphs from horizontal scripts are set sideways, i.e., 90° clockwise from
their nominal orientation in horizontal text, while glyphs from vertical scripts are not
affected.

If the value of this attribute is sidewaysLeft, then, in vertical writing modes,
glyphs from horizontal scripts are set sideways with 90° counter-clockwise rotation.

If the value of this attribute is sidewaysRight, then, in vertical writing modes,
glyphs from horizontal scripts are set sideways with 90° clockwise rotation.

If the value of this attribute is sideways, then, in vertical writing modes,
glyphs from horizontal scripts are set sideways, either 90° clockwise or
90° counter-clockwise, according to whether the writing mode is
tbrl or tblr, respectively. Glyphs from vertical scripts are not
affected.

If the value of this attribute is upright, then, in vertical writing modes,
glyphs from horizontal scripts are set upright, i.e., using their
nominal orientation in horizontal text, while glyphs from vertical scripts are not
affected. In addition, for purposes of bidirectional processing, this value causes all
affected characters to be treated as strong left-to-right, i.e., to be treated as if
a tts:direction of ltr and tts:unicodeOverride of
override were applied.

If a vertical writing mode does not apply, then this style property has no effect.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the value mixed.

The tts:textOrientation style is illustrated by the following
example.

Editorial note: Text Orientation Example

2013-08-24

Insert example fragment and image of tts:textOrientation.

Note:

The semantics of the style property
represented by this attribute are based upon that defined by [CSS Writing Modes],
§ 5.1.

10.2.40 tts:textOutline

The tts:textOutline attribute is used to specify a style property that
defines a text outline effect to apply to glyphs that are selected for glyph areas generated
by content flowed into a region.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

The value of this attribute consists of an optional <color> term
followed by one or two <length> terms. If a color term is
present, then it denotes the outline color; if no color term is
present, the computed value of the tts:color applies. The first
length term denotes the outline thickness and the second length
term, if present, indicates the blur radius.

The <length> value(s) used to express thickness and blur radius must be non-negative.

Note:

When a <length> expressed in
cells is used in a tts:textOutline value,
the cell's dimension in the block progression dimension applies.
For example, if text outline thickness is specified as 0.1c, the cell resolution
is 20 by 10, and the extent of the root container region is 640 by 480, then the
outline thickness will be a nominal 480 / 10 * 0.1 pixels, i.e., 4.8px,
without taking into account rasterization effects.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the value none.

10.2.41 tts:textShadow

The tts:textShadow attribute is used to specify a style property that
defines one or more text shadow decorations to apply to glyphs that are selected for glyph areas generated
by content flowed into a region.

If both tts:textOutline and tts:textShadow attributes
are specified on an element and tts:textShadow is a supported property,
then the tts:textOutline attribute must be ignored for the purpose of presentation processing.

If multiple text shadows apply, then they are drawn in the specified order immediately prior to drawing the glyph area to which they apply.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

For the purpose of determining applicability of this style property,
each character child of a p element is considered to be enclosed in an anonymous
span.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the value none.

Editorial note: Text Shadow Example

2015-01-08

Insert example fragment and image of tts:textShadow.

Note:

The semantics of the style property represented by this attribute are based upon
that defined by [CSS Text Decoration], § 4.

10.2.42 tts:unicodeBidi

The tts:unicodeBidi attribute is used to specify a style property that
defines a directional embedding or override according to
the Unicode bidirectional algorithm.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.29.6.

10.2.43 tts:visibility

The tts:visibility attribute is used to specify a style property that
defines whether generated areas are visible or not when rendered on a visual
presentation medium.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.30.17.

10.2.44 tts:wrapOption

The tts:wrapOption attribute is used to specify a style property that
defines whether or not automatic line wrapping (breaking) applies within the context of
the affected element.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.16.13.

10.2.45 tts:writingMode

The tts:writingMode attribute is used to specify a style property that
defines the block and inline progression directions to be used for the purpose of
stacking block and inline areas within a region area.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

In the second paragraph in the above example that targets region
r2, the tts:unicodeBidi and
tts:direction properties are set to
bidiOverride and rtl, respectively, in order
to override the normally left-to-right directionality of characters in
the Latin script.

Note:

The semantics of the style property
represented by this attribute are based upon that defined by [XSL 1.1],
§ 7.29.7.

10.2.46 tts:zIndex

The tts:zIndex attribute is used to specify a style property that
defines the front-to-back ordering of region areas in the case that they overlap.

This attribute may be specified by any
element type
that permits use of attributes in the TT Style Namespace; however, this attribute applies
as a style property only to those element types indicated in the following table.

If two areas are associated with the same Z-index value, then, if those areas
overlap in space, the area(s) generated by lexically subsequent elements must be
rendered over area(s) generated by lexically prior elements, where lexical
order is defined as the postorder traversal of a document instance.

The semantics of the value auto are those defined by
[XSL 1.1], § 7.30.18, where the tt element
is considered to establish the root stacking context.

If a computed value of the property associated with this attribute is not supported,
then a presentation processor must use the closest supported value.

Note:

In this context, the phrase closest supported value means the value for which the Euclidean distance between
the computed z-index and the supported z-index is minimized. If there are multiple closest supported values equally distant from
the computed value, then the value least distant from 0, i.e., closest to the base stack level of the current stacking context, is used.

In the syntax representations defined in this section, no
linear whitespace (LWSP) is implied or permitted between tokens
unless explicitly specified.

10.3.1 <alpha>

An <alpha> expression is used to express an opacity value,
where 0 means fully transparent and 1 means fully opaque.

Syntax Representation – <alpha>

<alpha>
: float

In the above syntax representation, the syntactic element
float must adhere to the lexical
representation defined by [XML Schema Part 2] §
3.2.4.1. If the value represented is less than 0.0,
then it must be interpreted as equal to 0.0; similarly, if the value
represented is greater than 1.0, then it must be interpreted as
1.0. The value NaN must be interpreted as 0.0.

A specified value for <alpha> should not be NaN,
less than 0, or greater than 1.

If a presentation processor does not support a specific,
valid opacity value, then it must interpret it as being equal to the
closest supported value.

Note:

In this context, the phrase closest supported value means the value for which the Euclidean distance between
the computed opacity and the supported opacity is minimized. If there are multiple closest supported values equally distant from
the computed value, then the value most distant from 0, i.e., the greatest opacity, is used.

10.3.2 <border-color>

A <border-color> expression is used to express the color of one
or more borders.

10.3.3 <border-style>

A <border-style> expression is used to express the style of one
or more borders.

Syntax Representation – <border-style>

<border-style>
: none
| dotted
| dashed
| solid
| double

The interpretation of dotted, dashed, and double are considered
to be implementation dependent.

If an implementation does not recognize or otherwise distinguish one of these border style values, then
it must be interpreted as if a style of solid were specified; as such, an implementation that
supports borders must minimally support the solid value.

10.3.4 <border-thickness>

A <border-thickness> expression is used to express the thickness of one
or more borders.

The interpretation of thin, medium, and thick are considered
to be implementation dependent; however, the resolved lengths must adhere to the following
constraints: thickness(thin) < thickness(medium); thickness(medium) < thickness(thick).

If a border thickness is expressed as a <length>,
then it must not take the form of a percentage value; i.e., it must take the form of a scalar value.

10.3.5 <color>

A <color> expression is used to specify a named color, exact RGB color triple,
or exact RGBA color tuple, where the alpha component, if expressed,
is maximum (255) at 100% opacity
and minimum (0) at 0% opacity, and where the applicable color space is
defined by [SRGB].

When expressing RGB component values, these values are considered
to not be premultiplied by alpha.

For the purpose of performing presentation processing such that
non-opaque or non-transparent alpha or opacity values apply, then the
semantics of compositing functions are defined with respect to the use of
the [SRGB] color space for both inputs and outputs of
the composition function.

Note:

The use of [SRGB] for the stated semantics of
composition is not meant to prevent an actual processor from using some
other color space either for internal or external purposes. For
example, a presentation processor may ultimately convert the SRGB values
used here to the YUV color space for rendition on a television device.

If a presentation processor does not support a specific,
valid color or alpha value, then it must interpret it as being equal
to the closest supported value.

Note:

In this context, the phrase closest supported value means the value for which the Euclidean distance between
the computed color and alpha and the supported color and alpha in the RGB color space is minimized. If there are multiple closest supported values equally distant from
the computed value, then the value least distant from opaque black rgb(0,0,0,255), i.e., the closest to opaque black, is used.

10.3.6 <digit>

A <digit> is used to express integers and other types of numbers or tokens.

Syntax Representation – <digit>

<digit>
: "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

10.3.7 <emphasis-color>

An <emphasis-color> expression is used to express the color of text
emphasis marks.

If an implementation does not recognize or otherwise distinguish emphasis color value, then
it must be interpreted as if a style of current were specified; as such, an implementation that
supports text emphasis marks must minimally support the current value.

10.3.8 <emphasis-style>

An <emphasis-style> expression is used to express the style of text
emphasis marks.

Emphasis mark is the first grapheme cluster of string, with remainder of string ignored.

If only filled or open is specified, then it is equivalent to filled circle and open circle, respectively.

If only circle, dot, or sesame is specified, then it is equivalent to filled circle, filled dot, and
filled sesame, respectively.

If an implementation does not recognize or otherwise distinguish an emphasis style value, then
it must be interpreted as if a style of auto were specified; as such, an implementation that
supports text emphasis marks must minimally support the auto value.

10.3.9 <emphasis-position>

An <emphasis-position> expression is used to express the position of text
emphasis marks.

Syntax Representation – <emphasis-position>

<emphasis-position>
: auto
| before
| after
| outside

auto

If the containing block area consists of exactly two line areas, then equivalent to outside; otherwise,
equivalent to before.

before

Towards the before edge of the affected glyph areas. If a horizontal writing mode applies, then this is towards the
top of the glyph areas. If a vertical writing mode applies, then this is either towards the right or left of the glyph
areas, according to whether tts:writingMode resolves to
tbrl or tblr, respectively.

after

Towards the after edge of the affected glyph areas. If a horizontal writing mode applies, then this is towards the
bottom of the glyph areas. If a vertical writing mode applies, then this is either towards the left or right of the glyph
areas, according to whether tts:writingMode resolves to
tbrl or tblr, respectively.

outside

Equivalent to before for all but the last affected line area; otherwise, equivalent to after
for the last affected line area.

If an implementation does not recognize or otherwise distinguish an emphasis position value, then
it must be interpreted as if a position of auto were specified; as such, an implementation that
supports text emphasis marks must minimally support the auto value.

In addition to adhering to the syntax rules specified above, the following semantic rules apply:

the semantic value of a <family-name> expression is the semantic value of its unquoted-string or quoted-string
non-terminal, according to whichever applies;

the semantic value of an unquoted-string non-terminal is a pair <quoted, content>,
where quoted is a boolean false, and
where content is the result of appending the value of each identifier
non-terminal, in lexical order, where the value of each identifier is preceded by a single SPACE (U+0020) character if it is not the first
identifier;

the semantic value of a quoted-string non-terminal is a pair <quoted, content>,
where quoted is a boolean true, and
where content is the unquoted content of the quoted string, i.e., the sequence of characters between the delimiting quotes.

the semantic value of an escape non-terminal is the value of the escaped char;

a <family-name> that takes the form of an unquoted-string that contains an identifier that
starts with two - HYPHEN-MINUS (U+002D) characters must be considered to be invalid;

a <family-name> that takes the form of an unquoted-string that contains a single identifier that
matches (by case sensitive comparison) a <generic-family-name> must be interpreted as that <generic-family-name>;

a <family-name> that takes the form of a quoted-string whose content (unquoted value)
matches (by case sensitive comparison) a <generic-family-name> must not be interpreted as that <generic-family-name>, but as
the actual name of a non-generic font family.

The syntactic element char is to be interpreted according
to the Char production defined by [XML 1.0] §2.2.

Note:

The {unicode} escape mechanism defined by [CSS2] §4.1.1
is not supported by this syntax; rather, authors are expected to either (1) directly encode the character
using the document encoding or (2) use an XML character reference according to
[XML 1.0] §4.1. When a syntactically significant character needs to be used
without its normal syntactic interpretation, it may be be escaped using the backslash
(reverse solidus) escape non-terminal specified above.

When using the backslash (reverse solidus) escape non-terminal, the above syntax does
not place any restriction on what character may be escaped, e.g., \\[\n\r\f0-9a-f] are
permitted. If one of these latter escapes appears in a <family-name> expression, then it will
need to be converted to a {unicode} escape if it is to be used with a standard XSL-FO
or CSS parser. In particular, a backslash followed by a newline is ignored by CSS, while it is not
ignored by the above syntax. Such an unignored escaped newline would need to be represented using
an equivalent {unicode} escape, such as \a, to order to express in CSS.

10.3.11 <generic-family-name>

A <generic-family-name> expression specifies a font family using a general
token that indicates a class of font families.

The resolution of a generic family name to a concrete font instance is considered to
be implementation dependent, both in the case of content authoring and content interpretation.

The mapping between a generic (font) family name and an actual font is not
determined by this specification; however, the
distinction of monospace versus proportional and serif versus sans-serif
should be maintained if possible when performing presentation.

If a generic (font) family name of monospace is specified,
then it may be interpreted as equivalent to either monospaceSansSerif
or monospaceSerif. The generic family names sansSerif
and serif are to be interpreted as equivalent to proportionalSansSerif
and proportionalSerif, respectively.

If the generic family name default is specified (or implied by
an initial value), then its typographic characteristics are considered to be implementation
dependent; however, it is recommended that this default font family be mapped to
an monospaced, sans-serif font.

10.3.12 <hex-digit>

A <hex-digit> is used to express integers and other types of numbers or tokens
that employ base 16 arithmetic.

For the purpose of parsing, a distinction must not be made between lower and upper case.

Replace unworkable (and unadopted) definition of pixel with an appropriate definition based on units of some viewport coordinate space.

Resolution:

None recorded.

When specified relative to a font whose size is expressed as a single length
measure or as two length measures of equal length, the unit of measure em is considered to be
identical to that defined by [XSL 1.1], § 5.9.13;
however, when specified relative to a font whose size is expressed as
two length measures of non-equal lengths, then one em is
equal to the inline progression dimension of the anamorphically
scaled font when used to specify lengths in the inline progression
direction and equal to the block progression dimension of the scaled
font when used to specify lengths in the block progression direction.

The units of measure vw and vh are defined as
one percent (1%) of the width and height of the root container region, respectively.
For example, the length 25vw is interpreted as 25% of the width of
the root container region.

10.3.15 <measure>

A <measure> value expresses a distance used to measure an allocation
dimension in either the inline progression direction, the ipd, or the block progression direction, the bpd, where
the direction that applies is determined by the context of use.

Note:

The terms ipd and bpd are interpreted in a writing mode relative manner
such that ipd always corresponds to a measure in the inline
progression direction and bpd always corresponds to a measure in the block progression direction.
Therefore, in horizontal writing modes, ipd expresses a horizontal measure
and bpd expresses a vertical measure, while, in vertical writing mode, ipd expresses a vertical measure
and bpd expresses a horizontal measure, where horizontal and vertical are always interpreted in an absolute sense.

For ipd, the numeric value equal to the ipd of the parent containing block's ipd less
the current element's combined border and padding ipd.
For bpd, the numeric value equal to the bpd of the parent containing block's bpd less
the current element's combined border and padding bpd.

fitContent

A numeric value equal to the maximum of the values of (1) minContent and (2) the minimum of values of maxContent and available.

maxContent

For ipd, the maximum numeric value that encloses all of the element's content such that lines are broken only at
hard, i.e., mandatory, break points, even if that means overflowing the parent's ipd.

For bpd, the maximum numeric value that encloses all of the element's content such that lines are broken at
all possible line break positions, i.e., both hard (mandatory) and soft (optional) break points.

minContent

For ipd, the minimum numeric value that encloses all of the element's content such that lines are broken at
all possible line break positions, i.e., both hard (mandatory) and soft (optional) break points.

For bpd, the minimum numeric value that encloses all of the element's content such that lines are broken only at
hard, i.e., mandatory, break points, even if that means overflowing the parent's ipd.

If a <length> component is expressed as a percentage, then that percentage is interpreted in relation to
some reference dimension, where the reference dimension is defined by the context of use.

A <length> component of a <position> expression may be positive or negative. Positive lengths are interpreted as
insets from the referenced edge, while negative lengths are interpreted as outsets from the referenced edge. For example, an inset from the left
edge is located to the right of that edge (if non-zero), while an outset from the left edge is located to the left of that edge (if non-zero). In
contrast, an inset from the right edge is located to the left of that edge (if non-zero), while an outset from the right edge
is located to the right of that edge (if non-zero). A similar arrangement holds for top and bottom edges.

When performing four component equivalent conversion, the expression (100% - <length-h>)
is to be interpreted as the difference between 100% and the percentage equivalent of the <length-h>
expression. Similarly, the expression (100% - <length-v>)
is to be interpreted as the difference between 100% and the percentage equivalent of the <length-v> expression.
In both cases, the resulting difference may be a negative percentage.

10.3.21 <shadow>

A <shadow> value expresses a shadow decoration to be applied to a generated area. If
the generated area is a glyph area, then it applies to the outline of the glyph (not the glyph area bounding box). If the
generated area is not a glyph area, then it applies to the border rectangle of the area.

A shadow value expression consists of an optional inset token term,
two to four <length> terms, and
an optional <color> term.

The first <length> term denotes the offset in the inline progression direction of the associated area,
where positive denotes towards the end edge and negative towards the start edge,
the second <length> term denotes the offset in the block progression direction of the associated area,
where positive denotes towards the after edge and negative towards the before edge.
The third <length> term, if present, denotes the blur radius, and must be non-negative.
The fourth <length> term, if present, denotes the spread distance, where positive denotes expansion and negative denotes contraction.

If no <color> term is
present, then the computed value of the tts:color property applies.

If applied to a glyph area, then an inset token and a spread distance, if either or both are present, are ignored for purpose of presentation processing.

Editorial note: Shadow Inset

2015-01-08

Define semantics of inset term.

Note:

When a <length> expressed in
cells is used in a tts:textShadow value,
the cell's dimension in the block progression dimension applies.
For example, if text shadow thickness is specified as 0.1c, the cell resolution
is 20 by 10, and the extent of the root container region is 640 by 480, then the
shadow thickness will be a nominal 480 / 10 * 0.1 pixels, i.e., 4.8px,
without taking into account rasterization effects.

10.4 Styling Semantics

This section defines the semantics of style resolution in terms of
a standard processing model as follows:

10.4.1.1 Inline Styling

Style properties may be expressed in an inline manner by direct
specification of an attribute from the TT Style Namespace on the
affected element. When expressed in this manner, the association of
style information is referred to as inline styling.

Style properties associated by inline styling are afforded a higher priority than all other
forms of style association.

In the above example, the two text fragments "White 1 " and
" White 2", which are interpreted as anonymous spans, are not
associated with a color style property; rather, they inherit their color style
from their parent p element as described in 10.4.2.1 Content Style Inheritance below.

10.4.1.2 Referential Styling

Style properties may be expressed in an out-of-line manner and referenced by the
affected element using the style attribute. When expressed in this manner,
the association of style information is referred to as referential styling.

If a style attribute specifies multiple references, then those references are
evaluated in the specified order, and that order applies to resolution of the value of a
style property in the case that it is specified along multiple reference paths.

The use of referential styling is restricted to making
reference to style element descendants of a styling
element. It is considered an error to reference a style
element that is a descendant of a layout element.

Note:

The use of referential styling encourages the reuse of style specifications while
sacrificing locality of reference.

Note:

A single content element may be associated with style properties by a hybrid mixture of
inline and referential styling, in which case inline styling is given priority as described above
by 10.4.1.1 Inline Styling.

In the above example, the two text fragments "White 1 " and
" White 2", which are interpreted as anonymous spans, are not
associated with a color style property; rather, they inherit their color style
from their parent p element as described in 10.4.2.1 Content Style Inheritance below.

10.4.1.3 Chained Referential Styling

Style properties may be expressed in an out-of-line manner and may themselves reference
other out-of-line style properties, thus creating a chain of references starting at the
affected element. When expressed in this manner, the association of style information
is referred to as chained referential styling.

If the same style property is specified in more than one referenced
style set, then the last referenced style set applies, where the order of application starts from
the affected element and proceeds to referenced style sets, and, in turn, to subsequent referenced style sets.

A loop in a sequence of chained style references must be considered an error.

The use of referential styling is restricted to making
reference to style element descendants of a styling
element. It is considered an error to reference a style
element that is a descendant of a layout element.

Note:

The use of chained referential styling encourages the grouping of style specifications
into general and specific sets, which further aids in style specification reuse.

Note:

A single content element may be associated with style properties by a hybrid mixture of
inline, referential styling, and chained referential styling, in which case inline styling is
given priority as described above by 10.4.1.1 Inline Styling.

10.4.1.4 Nested Styling

Style properties may be expressed in a nested manner by direct specification of one or
more style element children of the affected element.
When expressed in this manner, the association of style information
is referred to as nested styling.

Style properties associated by nested styling are afforded a lower priority than inline
styling but with higher priority than referential styling.

The intermediate synchronic document form is utilized rather than
the original form in order to facilitate region inheritance
processing.

10.4.2.1 Content Style Inheritance

Style properties are inherited from ancestor content elements
within an intermediate synchronic document
if a style property is not associated with a content element (or
an anonymous span) and the style property is designated as
inheritable.

If a style property is determined to require inheritance, then the inherited value must
be the value of the same named style property in the computed
style set of the
element's nearest ancestor element that defines the property
within the applicable intermediate synchronic document.

In the above example, the span element that encloses the character items
Yellow Monospace is not associated with a tts:fontFamily style
property and this property is inheritable; therefore, the value of the
tts:fontFamily style
is inherited from the computed style
set of the ancestor p element,
and is added to the
specified
style
set of the span element.

10.4.2.2 Region Style Inheritance

Style properties are inherited from a region element in the following case:

if an inheritable style property P is not associated with
a content element
or an anonymous span E, and

if that style property P is in the computed style
set of region R, and

In the above example, the anonymous span that encloses the character
items Yellow Monospace effectively inherits the tts:color
and tts:fontFamily styles specified on the region
element into which the p element is flowed (presented).

10.4.2.3 Root Style Inheritance

Style properties are inherited from the root tt element in the following case:

if an inheritable style property P is not associated with
a region element, and

if that
style property P is in the computed style
set of the root tt element.

Note:

Root style inheritance provides a mechanism by means of which region elements
can inherit a common style rather than repeating the specification of the style on each
region element.

In the above example, the region element inherits the
tts:color style specified on the tt element, which,
along with the tts:fontFamily style specified on the region
element, are inherited by p element when selected into the region.

10.4.3 Style Resolution Value Categories

During style resolution, layout, and presentation processing,
three categories of style property values are distinguished as
follows:

10.4.3.1 Specified Values

Values of style properties that are associated with or inherited
by an element or anonymous span are referred to as specified values. The
set of all specified style properties of a given element is referred to
as the specified style set of that element.

10.4.3.2 Computed Values

When style properties are specified using relative value expressions,
such as a named color, a relative unit (e.g., cell), or a percentage, then
they need to be further resolved into absolute units, such as an RGB triple,
pixels, etc.

During the style resolution process, all specified style values are
reinterpreted (or recalculated) in absolute terms, and then recorded as
computed values. The
set of all computed style properties of a given element is referred to
as the computed style set of that element.

When a style value is inherited, either explicitly or implicitly, it
is the computed value of the style that is inherited from an ancestor
element. This is required since the resolution of certain relative units,
such as percentage, require evaluating the expression in the immediate
(local) context of reference, and not in a distant (remote) context of
reference where the related (resolving) expression is not available.

10.4.3.3 Actual Values

During the actual presentation process, other transformations occur
that map some value expressions to concrete, physical values. For example,
the colors of computed style values are further subjected to closest color
approximation and gamma correction
during the display process. In addition, length value expressions that use
pixels in computed style values are considered to express logical rather than
physical (device) pixels. Consequently, these logical pixels are subject to
being further transformed or mapped to physical (device) pixels during
presentation.

The final values that result from the logical to device mapping
process are referred to as actual values. The set of all
actual style properties of a given element is referred to as the
actual style set of that element.

Note:

More than one set of actual values may be produced during the
process of presentation. For example, a TTML presentation processor
device may output an RGBA component video signal which is then
further transformed by an NTSC or PAL television to produce a final
image. In this case, both color and dimensions may further be modified
prior to presentation.

Note:

In general, a TTML presentation processor will not have access
to actual style set values; as a consequence, no further use or reference
to actual values is made below when formally describing the style
resolution process.

10.4.4 Style Resolution Processing

The process of style resolution is defined herein as the procedure
(and results thereof) for resolving (determining) the computed values
of all style properties that apply to content and layout elements:

10.4.4.1 Conceptual Definitions

For the purpose of interpreting the style resolution processing
model specified below, the following conceptual definitions apply:

[style property]

a style property, P, is considered to consist of a
tuple [name, value], where the name of the
property is a tuple [namespace value,
unqualified name] and the value of the property is a
tuple [category, type, value expression]

a style (property) set consists of an unordered collection of style
properties, where no two style properties within the set have an
identical name, where by "identical name" is meant equality of
namespace value of name tuple and unqualified name of name tuple;

in a specified style (property) set, the category of each style
property is "specified"; a specified style (property) set of an
element E is referred to as SSS(E);

a style property Pnew is merged into a
style (property) set, SS, as follows: if a style property
Pold is already present in SS
where the name of Pnew is identical to the
name of Pold, then replace
Pold in SS with
Pnew; otherwise, add
Pnew to SS;

[style (property) set merging]

a style (property) set SSnew is merged into
an existing style (property) set SSold as
follows: for each style property Pnew in
SSnew, merge Pnew into
SSold;

10.4.4.2 Specified Style Set Processing

The specified style set SSS of an element or
anonymous span E,
SSS(E), is determined according to the following ordered
rules:

[initialization] initialize
the specified style set SSS of E to the
empty set;

[referential and chained referential
styling] for each style element SREF
referenced by a style attribute specified on
E, and in the order specified in the style
attribute, then, if SREF is a descendant
of a styling element,
merge the specified style set of
SREF, SSS(SREF), into
the specified style set of E,
SSS(E);

[nested styling] for each
nested style element child SNEST of
E, and in the specified order of child elements, merge
the specified style set of SNEST,
SSS(SNEST), into the specified style set of
E, SSS(E);

[inline styling] for each
style property P expressed as a specified styling
attribute of E,
merge P into the specified style
set of E, SSS(E);

[animation styling] if the
element type of E is not the animation element type
set, then for each
immediate animation (set) element child A of element E,
merge the specified style set of A,
SSS(A), into the specified style set of E, SSS(E);

[implicit inheritance and initial value fallback] if the
element type of E is not animation element type animate or set
and is not styling element type style,
then for each style property
P in the set of style properties defined
above in 10.2 Styling Attribute Vocabulary, perform the
following ordered sub-steps:

if P is present in the specified
style set of E, SSS(E), then continue to the
next style property;

if P is defined to be inheritable and E is
not the tt element, then perform the following:

set P′ to the result of
looking up the value of P in the computed style set of
the nearest ancestor element of E, NEAREST-ANCESTOR(E), such that
CSS(NEAREST-ANCESTOR(E)) contains a definition of P;

otherwise (P is not inheritable or E is
the tt element), perform the following:

set P′ to the initial value of
property P, where the initial value of a property is
determined as follows:

if an initial
element defines the initial value for P, then use that value;

[filter] if
E is an animate, set, or style element, then return
CSS(E) as the resulting computed style set without
further resolution; otherwise, continue with the next rule;

[relative value resolution] for each
style property P in CSS(E), where the value
type of P is relative, perform the following ordered
sub-steps:

replace the relative value of P with an
equivalent, non-relative (computed) value;

set the category of P to "computed";

Note:

As a result of the filtering rule above, the computed style set of
an animate, set, or style element includes only specified values, in which case
relative value expressions remain relative; consequently, the
resolution of relative value expressions (that may be assigned by
means of referential style association) always takes place in the
context of a layout or content element which has a presentation
context, and not in the non-presentation, declaration context
of an animate, set, or referable style element.

10.4.4.4 Style Resolution Process

The top-level style resolution process is defined as follows: using
a preorder traversal of each element and anonymous span,
E, of an intermediate synchronic document,
DOCinter, perform the following ordered
sub-steps:

[filter] if E
is not one of the following, then continue to the next element in the preorder traversal, i.e.,
do not perform the subsequent step below on E:

10.4.5 Automatic Measure Calculation

Define semantics for resolving the auto value as used with a <measure> expression,
the definition of which should be consistent with [CSS Box Model], § 15.

Editorial note: Automatic Measure Applied to Image

2015-01-25

Define semantics for resolving the auto value as used with a <measure> expression when
applied to the width or height of an image element.

11 Layout

This section specifies the layout matter of the core
vocabulary catalog, where
layout is to be understood as a separable layer of information that applies to
content and that denotes authorial intentions about the presentation of
that content.

Note:

The two layers of layout and style matter are considered to be independently
separable. Layout matter specifies one or more spaces or areas into
which content is intended to be presented, while style matter specifies the manner in
which presentation occurs within the layout.

In certain cases, a content author may choose to embed (inline) style matter directly
into layout or content matter. In such cases, an alternative
exists – use of referential styling –
in which the style
matter is not embedded (inlined).

11.1 Layout Element Vocabulary

The following elements specify the structure and principal layout aspects of a
document instance:

In addition, and in accordance with
10.4.2.2 Region Style Inheritance,
the region element may be used to specify inheritable style properties to be
inherited by content that is flowed into it.

The region element accepts as its children zero or more
elements in the Metadata.class element group,
followed by zero or more
elements in the Animation.class element group,
followed by
zero or more style elements.

Any metadata specified by children in the Metadata.class
element group applies semantically to the region element and its descendants as a whole.
Any animation elements specified by children in the Animation.class
element group apply semantically to the region element.
Any style child element must be considered a local style
definition that applies only to the containing region
element, i.e., does not apply for resolving referential styling (but does apply for region
style inheritance).

An out-of-lineregion element may specify one or more of the timing attributes:
begin, end, dur. An inlineregion element must not
specifiy a timing attribute, and, if specified, must be ignored for the purpose
of presentation processing.

If begin and (or) end attributes are specified on an out-of-line
region element, then they specify the beginning and (or) ending points
of a time interval during which the region is eligible for activation and with
respect to which animation child elements of the region are timed.
If specified, these begin and end points are relative to the time
interval of the nearest ancestor element associated with a time
interval, irregardless of whether that interval is explicit or implied.
The nearest ancestor element of an out-of-line region element that is associated
with a time interval is the layout element.
If a dur attribute is specified on an out-of-line region element, then it
specifies the simple duration of the region.

The active time interval of an inlineregion element is the
active time interval of its parent content element.

For the purpose of determining the semantics of presentation processing, a
region that is temporally inactive must not produce any visible marks when
presented on a visual medium.

Note:

An out-of-lineregion element may be associated with a time interval for two
purposes: (1) in order to temporally bound the presentation of the region and
its content, and (2) to provide a temporal context in which animations of region
styles may be effected.

For example, an author may wish to specify an out-of-lineregion element that is otherwise empty, but
may have a visible background color to be presented starting at some time and
continuing over the region's duration. The simple duration of the region serves
additionally to scope the presentation effects of content that is targeted to the
region. An author may also wish to move a region within the root container region
or change a region's background color by means of animation effects. In
both of these cases, it is necessary to posit an active time interval for a
region.

If no timeContainer attribute is specified on
a region element, then it must be interpreted as having
parallel time containment semantics.

If both tts:origin and tts:position attributes are present
on a region element, then the tts:origin must be ignored for the purpose of presentation processing.
If neither tts:origin nor tts:position attribute is present and
if the computed value of the the ttp:version attribute on the root tt element is two (2) or greater, then
the semantics of the initial value of the tts:position attribute apply for the purpose of presentation processing; otherwise, the semantics of the initial value of the tts:origin attribute apply.

If a ttm:role attribute is
specified on a region element, then it must adhere to the
value syntax defined by Syntax Representation – ttm:role, and where the roles identified
by this attribute express the semantic roles of the region
independently from the semantic roles of any content targeted to
(associated with) the region.

11.2 Layout Attribute Vocabulary

11.2.1 region

The region attribute is used to reference a region
element which defines a space or area into which a content element is intended to be flowed.

If specified, the value of a region attribute must
adhere to the IDREF data type defined by [XML Schema Part 2],
§ 3.3.9, and, furthermore, this IDREF must reference a region element
which has a layout element as an ancestor.

The region attribute may be specified by an instance of the following
element types:

If a default region is implied for a given document instance, then
the body element
is implicitly targeted to (associated with) the default region.

When implying a default region, the document instance is to be
treated as if a region element and its
parent layout
element were specified in a head
element, and a matching region attribute were
specified on the body element
as shown in the following example:

An inline region is declared in one of two ways:
(1) by specifying a tts:extent or
tts:origin style attribute on
a content element
in the Block.class element group, or
(2) by specifying an explicit region element
child of a content element
in the Block.class element group. The
former is referred to as an implied inline region specification,
the latter as an explicit inline region specification; furthermore, the former is considered
to be a syntactic shorthand for the latter, and is processed by converting it into the latter as
described below.

Inline regions are processed in accordance with the procedure
[process inline regions], which
entails first generating implied inline regions, and then generating out-of-line regions that correspond with implied
or explicit inline regions. This latter procedure additionally binds content elements associated with inline regions
to the corresponding generated out-of-line regions.

Note:

A content element can only be associated with a single
region. Consequently, if a content element
specifies a region attribute, then any implied inline region specification
or explicit inline region specification is ignored. If the content element does not specify a
region attribute, but it includes
both an implied inline region specification and an explicit inline region specification,
then the former is ignored in favor of the latter.

if the [attributes] information item property of B contains a
tts:extent attribute,
then copy that attribute to the [attributes] information item property of R;
otherwise, add a tts:extent attribute with value auto
to the [attributes] information item property of R;

if the [attributes] information item property of B contains a
tts:origin attribute,
then copy that attribute to the [attributes] information item property of R;
otherwise, add a tts:origin attribute with value auto
to the [attributes] information item property of R;

insert R into the [children] information item property of B
such that R immediately precedes the first content element
child of B, or, if none is present, then R is the last child element of B;

remove the tts:extent and
tts:origin style attributes, if present, from the
[attributes] information item property of B;

set the [children] information item property of R' to a deep copy of
the [children] information item property of R;

set the [attributes] information item property of R' to a deep copy of
the [attributes] information item property of R;

if the [attributes] information item property of R' does not include
an xml:id attribute, then add an implied xml:id attribute with a generated value
ID that is unique within the scope of the TTML document instance;
otherwise, let ID be the value of the xml:id attribute of R' ;

if present, remove the following attributes from the [attributes] information item property of R' :
begin,
dur, and
end;

add a begin attribute to the [attributes] information item property of R' with
a value equivalent to the computed begin time of B within the root temporal extent;

add a dur attribute to the [attributes] information item property of R' with
a value equivalent to the computed simple duration of B;

if the head element does not have
a layout child element, then insert an empty
layout element immediately after a
styling element, if present, and immediately before an
animation element, if present, or as the last child of
the head element if neither are present;

append R' to the [children] information item property of the
layout element child of the
head element;

add a region attribute with value ID to the [attributes] information
item property of B;

The use of an explicit inline region specification or a generated inline region that derives from
an implicit inline region specification
and the resulting generated out-of-line region is shown by the following two example documents.

11.3.1.3 Intermediate Synchronic Document Construction

Editorial note: Use Formalized ISD

2014-09-22

Revise in order to take into account new formalization of ISD structure and semantics (Appendix C).

For the purposes of performing presentation processing, the active time
duration of a document instance is divided into a sequence of time coordinates where at
each time coordinate, some element becomes temporally active or inactive,
then, at each such time coordinate, a document instance is mapped from its original, source
form, DOCsource ,
to an intermediate
synchronic document form,
DOCinter , according to the
[construct intermediate document] procedure:

for each temporally active region R, replicate the
sub-tree
of DOCsource
headed by the body element;

evaluating this sub-tree in a postorder traversal, prune elements if they
are not a content element, if they are temporally inactive, if they are empty,
or if they aren't associated with region R according to the
[associate region] procedure;

if the pruned sub-tree is non-empty, then reparent it to the R
element;

finally, after completing the above steps, prune the original body
element from the intermediate document, then prune all region,
begin, end, and dur attributes, which are no
longer semantically relevant;

Note:

In this section, the term prune, when used in reference to
an element, means that the element is to be removed from its parent's children,
which, in turn, implies that the descendants of the pruned element will no longer
be descendants of the element's parent. When prune is used in
reference to an attribute, it means that attribute is to be removed from its
associated (owning) element node.

Refine step (3) to resolve ambiguity when multiple regions are referenced by descendants.

Resolution:

None recorded.

Editorial note: Inline Region Association

2013-08-28

Define inline region association.

A content element is associated with a region according
to the following ordered rules, where the first rule satisfied
is used and remaining rules are skipped:

if the element specifies a region attribute,
then the element is associated with the region referenced by that
attribute;

if some ancestor of that element specifies a region attribute,
then the element is associated with the region referenced by the most
immediate ancestor that specifies this attribute;

if the element contains a descendant element that
specifies a region attribute,
then the element is associated with the region referenced by that
attribute;

if a default region was implied (due to the absence of any
region element),
then the element is associated with the default region;

the element is not associated with any region.

The result of performing the processing described above will be a sequence of
N intermediate synchronic
document instances,
DOCinter0 …
DOCinterN−1.

Note:

Where an implementation is able to detect significant similarity between two
adjacent synchronic document instances,
DOCinterNDOCinterN−1,
then it is preferred that the implementation make the transition between
presenting the two instances as smooth as possible, e.g., as described
by [CEA-608-E], § C.3, and [CC-DECODER-REQ].

11.3.1.4 Synchronic Flow Processing

Subsequent to performing a temporal (synchronic) slice and subsequent
remapping of regionally selected content hierarchy, the resulting intermediate
synchronic document is subjected to a flow transformation step that produces
a rooted flow object tree represented as an XSL FO document instance as defined by [XSL 1.1],
and semantically extended by TTML specific style properties that have no XSL
FO counterpart.

Note:

In this section, the use of XSL FO is intended to be conceptual only, employed
solely for the purpose of defining the normative presentation semantics of
TTML. An actual implementation of this algorithm is not required to create or process
XSL-FO representations. In particular, it is possible to implement these semantics
using alternative presentation models, such as Cascading Style Sheets (CSS).

for each significant text node in a content element,
synthesize an anonymous span to enclose the text node, substituting
the new anonymous span for the original text node child in its sibling
and parent hierarchy;

for each contiguous sequence of anonymous spans, replace the
sequence with a single anonymous span which contains a sequence of
text nodes representing the individual text node children of the
original sequence of anonymous spans;

for each span element whose child is a single anonymous span,
replace the anonymous span with its sequence of child text
nodes;

map the tt element to an fo:root element, populated
initially with an fo:layout-master-set element that contains a valid
fo:simple-page-master that, in turn, contains an
fo:region-body child, where the extent of the root container region expressed on the
tt element is mapped to page-width and
page-height attributes on the fo:simple-page-master
element;

map the layout element to an fo:page-sequence element and a
child fo:flow element that reference the page master and page region
defined by the simple page master produced above;

map each non-empty region element to an fo:block-container
element with an absolute-position attribute with value
absolute, with top, left, bottom, and right
attributes that express a rectangle equivalent to the region's origin and
extent, and with a line-stacking-strategy attribute with value line-height;

for each body, div, and p element that is not
associated with a tts:display style property with the value
none, map the element to a distinct fo:block element,
populating the style properties of fo:block by using the computed
style set associated with each original TTML content element;

for the resulting fo:block formatting object
produced in the previous step that corresponds to the body
element, perform the following ordered sub-steps:

if the display-align style property of this fo:block
has the value center or after,
then synthesize and insert as the first child of this fo:block
an empty fo:block with the following attributes:
space-after.optimum, space-after.maximum, and
space-after.conditionality, where the value of the former
two attributes is the height or width of the containing
fo:block-container element, whichever of these is designated
as the block progression dimension, and where the value of the last is
retain;

if the display-align style property of this fo:block
has the value center or before,
then synthesize and insert as the last child of this fo:block
an empty fo:block with the following attributes:
space-after.optimum, space-after.maximum, and
space-after.conditionality, where the value of the former
two attributes is the height or width of the containing
fo:block-container element, whichever of these is designated
as the block progression dimension, and where the value of the last is
retain;

for each span element that is not
associated with a tts:display style property with the value
none and for each anonymous
span that is a child of a p or span element,
map the element or
sequence of character items to a distinct fo:inline element,
populating the style properties of fo:inline by using the computed
style set associated with each original TTML content element
or anonymous span;

for each br element that is not
associated with a tts:display style property with the value
none, map the element to
a distinct fo:character element having the following
properties:

character="&#x000A;"

suppress-at-line-break="retain"

for each TTML style property attribute in some computed
style set that
has no counterpart in [XSL 1.1], map that attribute directly through
to the relevant formatting object produced by the input TTML content element to
which the style property applies;

optionally, synthesize a unique id attribute on each resulting
formatting object element that relates that element to the input element that
resulted in that formatting object element;

For each resulting document instance F, if processing requires presentation on a
visual medium, then apply formatting and rendering semantics consistent with that
prescribed by [XSL 1.1].

Note:

In an XSL FO area tree produced by formatting F using
an [XSL 1.1] formatting processor,
the page-viewport-area,
which is generated by fo:page-sequence element by
reference to the sole generated fo:simple-page-master
element, would correspond to the root container region defined
above in 2 Definitions.

Note:

When mapping a region element to fo:block-container, it may
be necessary to use a negative offset as a value for one or more of the
top, left, bottom, and right
XSL-FO properties in case the region extends outside of its containing block.

Note:

Due to the possible presence of TTML style properties or style property values
in a given document instance for which there is no [XSL 1.1] counterpart,
Implementors should recognize that it is the layout model of [XSL 1.1] that is being referenced
by this specification, not the requirement to use a compliant [XSL 1.1] formatting processor,
since such would not necessarily be sufficient to satisfy the full presentation semantics
defined by this specification, and would contain a large number of features not needed to
implement the presentation semantics of TTML.

Note:

The purpose of inserting additional, collapsible space in the block progression
dimension of the fo:block that corresponds with the body element
is to ensure that the before and after edges of this fo:block are coincident
with the before and after edges of the fo:block-container that corresponds
to the containing region, while simultaneously taking into account the needs
to satisfy alignment in the block progression dimension. For example, this assures that
the background color associated with the body element, if not transparent,
will fill the containing region wholly.

In the above document, the content hierarchy consists of two divisions, each
containing two paragraphs. This content is targeted (associated with) one of two
non-overlapping regions that are styled identically except for their position
and their foreground colors, the latter of which is inherited by and applies to
the (and, in this case, anonymous) spans reparented into the regions.

The following, first intermediate document shows the synchronic state for time
interval [0,1), during which time only division d1 is temporally active,
and where paragraphs p1 and p2 (and their ancestors)
are associated with regions r1 and r2, respectively.

Note:

The intermediate documents shown below are not valid document instances,
but rather, are representations of possible internal processing states used for
didactic purposes.

The following, second intermediate document shows the synchronic state for
time interval [1,2), during which time both divisions d1 and
d2 are temporally active, and where paragraphs p1 and
p4 (and their ancestors) are associated with region r1
and paragraphs p2 and p3 (and their ancestors) are
associated with region r2.

The following, third intermediate document shows the synchronic state for time
interval [2,3), during which time only division d2 is temporally active,
and where paragraphs p4 and p3 (and their ancestors)
are associated with regions r1 and r2, respectively.

12 Timing

This section specifies the timing matter of the core
vocabulary catalog, where
timing is to be understood as a separable layer of information that applies to
content and that denotes authorial intentions about the temporal presentation of
that content.

12.1 Timing Element Vocabulary

No timing related element vocabulary is defined for use in the core
vocabulary catalog.

12.2 Timing Attribute Vocabulary

This section defines the following basic timing attributes for use with timed elements:

In addition, this section defines the 12.2.4 timeContainer attribute for use with timed elements
that serve simultaneously as timing containers.

12.2.1 begin

The begin attribute is used to specify the begin
point of a temporal interval associated with a timed element. If
specified, the value of a begin attribute must adhere to
a <time-expression> specification as defined by 12.3.1 <time-expression>.

The begin point of a temporal interval is included in the
interval; i.e., the interval is left-wise closed.

The semantics of the begin attribute are those defined
by [SMIL 3.0], § 5.4.3,
while taking into account any overriding semantics defined by this specification.

12.2.2 dur

The dur attribute is used to specify the duration of a
temporal interval associated with a timed element. If specified,
the value of a dur attribute must adhere to a
<time-expression> specification as defined by 12.3.1 <time-expression>.

Note:

When the clock-time form of a <time-expression> specification
is used with a dur attribute, it is intended to be interpreted as
a difference between two implied clock time expressions.

When a document instance specifies the use of the
smpte time base and discontinuous marker
mode, a (well-formed) dur attribute must not be specified on any
element.

The semantics of the dur attribute are those defined
by [SMIL 3.0], § 5.4.3,
while taking into account any overriding semantics defined by this specification.
In a deliberate divergence from [SMIL 3.0], § 5.4.3, the value of
the dur attribute is permitted to be zero (0).

Note:

In the context of the subset of [SMIL 3.0] semantics supported by
this specification, the active duration of an element that specifies both
end and dur attributes is equal to the lesser of the value of
the dur attribute and the difference between the value of the
end attribute and the element's begin time.

12.2.3 end

The end attribute is used to specify the ending point
of a temporal interval associated with a timed element. If
specified, the value of an end attribute must adhere to a
<time-expression> specification as defined by 12.3.1 <time-expression>.

The ending point of a temporal interval is not included in the
interval; i.e., the interval is right-wise open.

The presentation effects of a non-empty active
temporal interval include the frame immediately prior to the frame
(or tick) equal to or immediately following the time specified by the ending
point, but do not extend into this latter frame (or tick).

Note:

For example, if an active interval is [10s,10.33333s), and the
frame rate is 30 frames per second, then the presentation effects of the interval
are limited to frames 300 through 309 only (assuming that 0s corresponds
with frame 0). The same holds if the active interval is specified
as [300f,310f).

The semantics of the end attribute are those defined
by [SMIL 3.0], § 5.4.3,
while taking into account any overriding semantics defined by this specification.

12.2.4 timeContainer

The timeContainer attribute is used to specify a local temporal
context by means of which timed child elements are temporally situated.

Editorial note: Time Containment in SMPTE Discontinuous Mode

2015-01-14

Indicate that parallel time container semantics always apply in smpte discontinuous mode, and, as such,
sequential containment must not be specified.

If specified, the value of a timeContainer attribute must be one
of the following:

par

seq

If the time container semantics of an element instance is par,
then the temporal intervals of child elements are considered to apply in
parallel, i.e., simultaneously in time. Furthermore, the specification of
the time interval of each child element is considered to be relative to the temporal
interval of the container element instance. For the purpose of determining the
[SMIL 3.0]endsync semantics of a par
time container, a default value of all applies.

Note:

The use of a default value of all for the endsync
behavior is distinct from [SMIL 3.0] which uses a default value
of last.

If the time container semantics of an element instance is seq,
then the temporal intervals of child elements are considered to apply in
sequence, i.e., sequentially in time. Furthermore, the specification of
the time interval of each child element is considered to be relative to the temporal
interval of its sibling elements, unless it is the first child element, in which case
it is considered to be relative to the temporal interval of the container
element instance.

Each time container is considered to constitute an independent time base, i.e.,
time coordinate system.

If a timeContainer attribute is not specified on an element that
has time container semantics, then par time container semantics must apply.

12.3 Time Value Expressions

12.3.1 <time-expression>

A <time-expression> is used to specify a coordinate within
some time base, where the applicable time base is determined by the
ttp:timeBase parameter, and where the semantics defined
by H Time Expression Semantics apply.

If a <time-expression> is expressed in terms of a
clock-time, then leading zeroes are used when expressing hours,
minutes, seconds, and frames less than 10. Minutes are constrained to
[0…59], while seconds (including any fractional part) are constrained to the closed
interval [0,60], where the value 60 applies only to leap seconds.

If a <time-expression> is expressed in terms of a
clock-time and a frames term is specified,
then the value of this term must be constrained to the interval
[0…F-1], where F is the frame rate
determined by the ttp:frameRate parameter as defined
by 7.2.4 ttp:frameRate.
It is considered an error if a frames term or
f (frames) metric is specified when the clock time base applies.

If a <time-expression> is expressed in terms of a
clock-time and a sub-frames term is
specified, then the value of this term must be constrained to the
interval [0…S-1], where S is the
sub-frame rate determined by the ttp:subFrameRate parameter as defined by 7.2.11 ttp:subFrameRate.
It is considered an error if a sub-frames term is specified
when the clock time base applies.

If a <time-expression> is expressed in terms of an
offset-time and no metric is specified, then it is to be treated as
if a metric of s (seconds) were specified.

12.4 Timing Semantics

The semantics of time containment, durations, and intervals defined by
[SMIL 3.0] apply to the interpretation of like-named timed elements and timing
vocabulary defined by this specification, given the following
constraints:

The implicit duration of an anonymous span is defined as follows: if
the anonymous span's parent time container is a parallel time container, then
the implicit duration is equivalent to the indefinite
duration value as defined by [SMIL 3.0]; if the anonymous span's
parent time container is a sequential time container, then the implicit duration
is equivalent to zero.

The implicit duration of a body, div, p,
or span element is determined in accordance to (1) whether
the element is a parallel or sequential time container, (2) the default
endsync semantics defined above by 12.2.4 timeContainer,
and (3) the semantics of [SMIL 3.0] as applied to these time
containers.

The implicit duration of the region element is defined to
be equivalent to the indefinite
duration value as defined by [SMIL 3.0].

If the governing time base is clock, then time
expressions are considered to be equivalent to wall-clock
based timing in [SMIL 3.0], where the specific semantics of
H.1 Clock Time Base apply.

If the governing time base is media, then time
expressions are considered to be equivalent to offset based timing
in [SMIL 3.0], where the specific semantics of
H.2 Media Time Base apply.

If the governing time base is smpte, then time
expressions are considered to be equivalent to either offset
based timing or event based timing in [SMIL 3.0], where the specific semantics of
H.3 SMPTE Time Base apply.

13 Animation

This section specifies the animation matter of the
core vocabulary catalog, where
animation is to be understood as a separable layer of information that combines
timing and styling in order to denote authorial intention about (temporally) dynamic
styling of content.

Editorial note: Out-of-Line Animation Time Containment

2014-07-31

Support ability for author to declare whether a referenced out-of-line animation's timing is relative
to its animation container element's timing or relative to the referring element's timing.
For example, add an @animateTimeContainer attribute optionally used with the newly defined
@animate attribute, where value can be normal (the default value) or self, and where normal
means timing is with respect to the out-of-line animation element's ancestor animation container and self means timing is
with respect to the referring element.

13.1 Animation Element Vocabulary

The following elements specify the structure and principal animation aspects of a
document instance:

Consider whether semantics of ARIB-TT's marquee extension can be handled by animate, and, if not, then consider extending.

Resolution:

None recorded.

An animate element may appear as either (1) a child of a
content element or a region element,
referred to as inline animation, or
(2) a child of an animation element, referred to as
out-of-line animation.
In the former case, the parent of the animate element is the associated element; in the latter
case, any element that references the animate element using an animate attribute is
an associated element.

The animate element accepts as its children zero or more
elements in the Metadata.class element group.

Style property attributes targeted by an animate element are specified directly using
attributes in the TT Style namespace or in a namespace that is not a TT namespace, where the list (sequence) of animation (key) values
adhere to the <animation-value-list> syntax, and where each
constituent <animation-value> adheres to the syntax of the specified
attribute.

Note:

In contrast with [SVG 1.1], §19.2.12, a single animate element, as defined here, may be used to
perform continuous animations on a set of targeted style property attributes instead of being limited to targeting a single style property attribute.
In [SVG 1.1], this would require the use of multiple animate elements rather than a single animate element.

Furthermore, by using direct specification of animated style property and key values, it is not necessary to employ the from,
to, by, or values animation value attributes defined by [SVG 1.1], §19.2.9.

Except for the constraints or variations enumerated below, the semantics of the animate element and its attributes
enumerated above are defined to be those specified by [SVG 1.1], §19.2.12:

The attributes targeted by an animate element and the key values to be applied to these attributes are
specified by direct use of attributes in the TT Style namespace or a namespace that is not a TT namespace (as opposed to using
SVG's attributeName and from, to, by, or values attributes).

Note:

For example, specifying tts:color="red;green;blue" is
considered equivalent to specifying attributeName="tts:color" and values="red;green;blue" in [SVG 1.1].

If no calcMode attribute is specified, then a calcMode value of linear applies.

If no fill attribute is specified, then a fill value of remove applies.

An example of using the animate element to animate content
styling is illustrated below:

In the above example, the foreground color of the content "Text
with Continuously Varying Colors!" is continuously animated from yellow, to red, to green, to
red, then back to yellow over a 5 second period.

An example of using the animate element to animate region
styling is illustrated below:

In the above example, a region, r1, is initially set to 0% opacity,
fully transparent, then is faded in to 100% opacity, fully opaque, over a one second
interval. Opacity remains at 100% for five more seconds, and then is faded out to 0%
over a one second interval, where it remains.

Editorial note: Animate Example Images

2013-08-25

Insert animated SVG images of animate examples.

Note:

The semantics of the animate element
are based upon that defined by [SVG 1.1],
§19.2.12, which, in turn, is based upon [SMIL 3.0], §12.

13.1.2 animation

The animation element is a container element used to group
out-of-line animation matter, including metadata that applies to animation matter.

The animation element accepts as its children zero or more
elements in the Metadata.class element group, followed by
zero or more elements in the Animation.class element group.

To the extent that time semantics apply to the content of the
animation element, the implied time interval of this element is
defined to be coterminous with the root temporal extent.

13.1.3 set

The set element expresses one or more a discrete changes (animations) to be applied (targeted) to style property attributes
of associated elements.

A set element may appear as either (1) a child of a
content element or a region element,
referred to as inline animation, or
(2) a child of an animation element, referred to as
out-of-line animation.
In the former case, the parent of the set element is the associated element; in the latter
case, any element that references the set element using an animate attribute is
an associated element.

The set element accepts as its children zero or more
elements in the Metadata.class element group.

Style property attributes targeted by an set element are specified directly using
attributes in the TT Style namespace or in a namespace that is not some TT namespace, where the single target animation (key) value
adheres to the <animation-value-list> syntax, where each
constituent <animation-value> adheres to the syntax of the specified
attribute, and where exactly one constituent <animation-value> is specified.

If more than one constituent <animation-value> is specified, then all
constituents other than the first must be ignored for the purpose of presentation processing, and must be considered an error for the
purpose of validation processing.

Note:

In contrast with [SVG 1.1], §19.2.13, a single set element, as defined here, may be used to
perform discrete animations on a set of targeted style property attributes instead of being limited to targeting a single style property attribute.
In [SVG 1.1], this would require the use of multiple set elements rather than a single set element.

Except for the constraints or variations enumerated below, the semantics of the set element and its attributes
enumerated above are defined to be those specified by [SVG 1.1], §19.2.13:

The attributes targeted by a set element and the discrete values to be applied to these attributes are
specified by direct use of attributes in the TT Style namespace or in a namespace that is not a TT namespace (as opposed to using SVG's
attributeName and to attributes).

Note:

For example, specifying tts:color="red" is
considered equivalent to specifying attributeName="tts:color" and to="red" in [SVG 1.1].

If no fill attribute is specified, then a fill value of remove applies.

An example of using the set element to animate content
styling is illustrated below:

In the above example, the root container region is divided into a
cell grid of 40 columns and 16 rows. A region, r1, with
dimensions of 24 columns and 2 rows is then positioned within the
root container region, with its position varying over time in order to
create an effect of moving the region, which may be desirable so as
to avoid obscuring characters in an underlying video with captions.

Editorial note: Set Example Images

2013-08-25

Insert animated SVG images of set examples.

Note:

The semantics of the set element
are based upon that defined by [SVG 1.1],
§19.2.13, which, in turn, is based upon [SMIL 3.0], §12.

If specified, the value of an animate attribute must
adhere to the IDREFS data type defined by [XML Schema Part 2],
§ 3.3.10, and, furthermore, each IDREF must reference an animate
or set element
which has a animation element as an ancestor.

A given IDREF must not appear more than one time in the value of an animate
attribute.

Note:

See the specific element type definitions that permit use of the
animate attribute.

13.3 Animation Value Expressions

Animation attribute values include the use of the following expressions:

13.3.1 <animation-value>

An <animation-value> expression is used to specify the starting (initial), intermediate,
or ending (final) of the attribute targeted by the animation.

Syntax Representation – <animation-value>

<animation-value>
: string

The syntax of an <animation-value> expression must satisfy all syntax
requirements that apply to the attribute targeted by the animation.

Editorial note: Improve Syntax of AnimationValue

2014-07-31

Enhance detail of syntax of <animation-value> in order to prevent appearance of an unquoted or unescaped semicolon,
which is used as a delimiter between animation values in <animation-value-list>.

The semantics of an <animation-value> expression are those defined by
[SVG 1.1], §19.2.9.

13.3.2 <animation-value-list>

An <animation-value-list> expression is used to specify a list of animation values that sequentially
apply to the attribute targeted by the animation, wherein each pair of values is separated by a SEMICOLON (U+003B) character
optionally surrounded by linear white-space (LWSP) characters.

The syntax of an <animation-value> in an <animation-value-list> expression must satisfy all syntax
requirements that apply to the attribute targeted by the animation.

The semantics of an <animation-value-list> expression are those defined by
[SVG 1.1], §19.2.9.

13.3.3 <calculation-mode>

A <calculation-mode> expression is used to control the interpolation mode of the animation.

Syntax Representation – <calculation-mode>

<calculation-mode>
: "discrete"
| "linear"
| "spline"

The semantics of a <calculation-mode> expression are those defined by
[SVG 1.1], §19.2.9.

13.3.4 <fill>

A <fill> expression is used to determine effect of the animation after the active end of the animation.

Syntax Representation – <fill>

<fill>
: "freeze"
| "remove"

The semantics of a <fill> expression are those defined by
[SVG 1.1], §19.2.8.

13.3.5 <key-splines>

An <key-splines> expression is used to specify a list of Bezier control points that control the pacing of an
animation, wherein each pair of values is separated by a SEMICOLON (U+003B) character
optionally surrounded by linear white-space (LWSP) characters.

The semantics of a <key-splines> expression are those defined by
[SVG 1.1], §19.2.9, as apply to the key-splines attribute.

13.3.6 <key-times>

An <key-times> expression is used to specify a list of relative time values that control the pacing of an
animation, wherein each pair of values is separated by a SEMICOLON (U+003B) character
optionally surrounded by linear white-space (LWSP) characters.

The semantics of a <repeat-count> expression are those defined by
[SVG 1.1], §19.2.8.

14 Metadata

This section specifies the metadata matter of the core
vocabulary catalog, where
metadata is to be understood as a separable layer of information that applies to
parameters, content,
style, layout, timing, and even metadata itself, where the information
represented by metadata takes one of two forms: (1) metadata defined by this
specification for standardized use in a document instance, and (2) arbitrary
metadata defined outside of the scope of this specification, whose use and
semantics depend entirely upon an application's use of TTML Content.

14.1.1 metadata

The metadata element functions as a generic container for metadata
information.

Metadata information may be expressed with a metadata element by specifying
(1) one or more metadata attributes or foreign namespace attributes on the metadata element,
(2) one or more metadata item or foreign namespace child elements,
(3) one or more data child elements, or
(4) a combination of the preceding.

The meaning of a specific metadata item must be evaluated in the
context where it appears. The core vocabulary catalog permits an
arbitrary number of metadata element children on any
content element type. See specific element
vocabulary definitions for any constraints that apply to such
usage.

In the above example, a global attribute from a foreign (external)
namespace is used to express a metadata attribute that applies
semantically to the containing div element. Note that the
attribute may also be expressed directly on the div element;
however, in this case the author wishes to segregate certain metadata
attributes by expressing them indirectly on metadata
elements.

The use of foreign element metadata is illustrated by the following example.

In the above example, two agents, a real (person) agent, Sean
Connery, and a fictitious (character) agent, James Bond, are defined,
where the latter is linked to the former by means of the a
ttm:actor element. A reference is then made from content (the
p element) to the character agent associated with
(responsible for producing) that content. Note that in this example
the ttm:agent metadata items are specified as immediate
children of the document's head element rather than being
placed in a container metadata element.

14.1.4 ttm:copyright

The ttm:copyright element is used to express a human-readable copyright that
applies to some scoping level.

A copyright statement that applies to a document as a whole should appear as a
child of the head element.

A name attribute must be specified to identify the name of the item, the value of which must adhere to
an <item-name> value expression.

Note:

No general constraint is placed on the appearance of multiple named metadata items that specify the same name; however,
the definition of a specific named item may further constrain the context of use as well as the potential appearance of multiple items that share the same name.

The value of a named metadata item is
(1) empty if the element has no child text or element nodes,
(2) the character content of the ttm:item element when that element's children consists solely of text nodes, or
(3) a collection of named metadata sub-items.

Note:

The definition of a particular named item will typically constrain the set of permitted values. Furthermore, it may
specify that a particular value is implied in the absence of a specified value.

The use of a named metadata item is illustrated by the following example, which shows the use of a named metadata item
in order to associate a simple data embedding with an original file name.

The above example makes use of a single chunk element in order
to include a ttm:item element as a child of the data element;
i.e., if the encoded image bytes had been included directly as #PCDATA in the data element,
then it would not have been possible to include the ttm:item child element. See the supported content models on the
data element for more information.

14.1.7 ttm:name

The ttm:name element is used to specify a name of a person, character,
group, or organization.

The same role token, R, should not appear more than once in the value of a ttm:role attribute.

Note:

This constraint is intended to discourage the use of redundant role tokens.

Note:

All values of ttm:role that do not start with the prefix
x- are reserved for future standardization.

Note:

If using a custom x- prefixed form of ttm:role, it
is recommended that an organization unique infix be used as well in order to
prevent collisions. For example, x-example-org-custom-role. Furthermore,
a registry for role values is available at
http://www.w3.org/wiki/TTML/RoleRegistry
in order to promote interoperability and collision avoidance.

14.3.1 <item-name>

If an item name expression takes the form of a qualified name (xsd:QName),
then the prefix of that qualified name must have been declared in a namespace declaration as specified by [XML Namespaces 1.0].

All values of <item-name> that do not take the form of qualified name (xsd:QName)
are reserved for future standardization by the W3C.

Note:

It is intended that all item names defined by this specification are unqualified (without a prefix), whereas those defined by
external specifications are qualified (with a prefix).

14.3.2 <named-item>

A <named-item> value is one of an enumerated collection of named metadata items associated with a value by
a ttm:item element.

Further specify the value syntax of certain named items, e.g., by adding external document references (CEA608) or by defining specific value syntax.

cea608CaptionService

A string that expresses the field and channel mapping of a CEA-608 caption service, where the value
adheres to xsd:string.

cea608Channel

A string that expresses the channel code of a CEA-608 caption service, where the value
adheres to xsd:string.

cea608ContentAdvisory

A string that expresses the content advisory packet information of a CEA-608 caption service, where the value
adheres to xsd:string.

cea608CopyAndRedistributionControl

A string that expresses the copy and redistribution control packet information of a CEA-608 caption service, where the value
adheres to xsd:string.

cea608FieldStart

An integer that expresses the field start of a CEA-608 caption service, where the value
is either 1 or 2.

cea608ProgramName

A string that expresses the program name of a CEA-608 caption service, where the value
adheres to xsd:string.

cea608ProgramType

A string that expresses the program type code of a CEA-608 caption service, where the value
adheres to xsd:string.

cea708EasyReader

A boolean that expresses whether a CEA-708 caption service is characterized for use with an easy reader, where the value
adheres to xsd:boolean.

cea708FCCMinimum

A boolean that expresses whether a CEA-708 caption service is characterized as conforming to minimum FCC decoder requirements, where the value
adheres to xsd:boolean.

cea708ServiceNumber

An integer that expresses the service number of a CEA-708 caption service, where the value
adheres to xsd:positiveInteger and is less than 32.

cea708TransformMode

One of the token values enhanced or preserved.

cea708TransformOrigin

Either the token none or an xsd:anyURI,
where the latter expresses a CEA-708 transformation source format.

cea708TransformTimingThreshold

A real number that expresses a threshold parameter used to suppress the inclusion of temporary timed states when
transforming amongst a CEA-708 caption service and a timed text content document,
where the value adheres to xsd:float.

creationCountryOfOrigin

A string that expresses a the country or origin code associated with this document, where the value
adheres to xsd:string.

creationDate

A date that expresses the creation date of this document, where the value
adheres to xsd:date.

creationSystem

A free form string expressing the software and version used to create the document, where the value
adheres to xsd:string.

editor

A string that expresses the name of one or more editors, where the value
adheres to xsd:string.

editorContact

A string that expresses the contact details of one or more editors, where the value
adheres to xsd:string.

maximumCharactersPerRow

A non-negative integer that expresses the maximum number of characters per row (line) used in this document, where the value
adheres to xsd:nonNegativeInteger.

originalEpisodeTitle

A string that expresses the episode title in the original language, where the value
adheres to xsd:string.

A string that expresses the episode title in the translated (local) language, where the value
adheres to xsd:string.

translatedProgramTitle

A string that expresses the program title in the translated (local) language, where the value
adheres to xsd:string.

translator

A string that expresses the name of one or more translators, where the value
adheres to xsd:string.

translatorContact

A string that expresses the contact details of one or more translators, where the value
adheres to xsd:string.

usesForced

A boolean that expresses whether some <condition> expression
makes use of the forced bound parameter, where the value
adheres to xsd:boolean. If this named metadata item
is present in a document instance, then it must be specified as a child
of the head element.

C Schemas

In any case where a schema specified by this appendix differs from the
normative definitions of document type, element type, or attribute type
as defined by the body of this specification, then the body of this
specification takes precedence.

C.1 Relax NG Compact (RNC) Schema

A Relax NG Compact Syntax (RNC) [RELAX NG] based schema
for TTML Content is available at ZIP
Archive. This schema is to be considered non-normative for the purpose of defining the validity
of Timed Text Markup Language content as defined by this specification.
In particular, the formal validity of TTML Content
is defined by 3.1 Document Conformance.

C.2 XML Schema Definition (XSD) Schema

A W3C XML Schema Definition (XSD) [XML Schema Part 1] based schema
for TTML Content is available at ZIP
Archive. This schema is to be considered non-normative for the purpose of defining the validity
of Timed Text Markup Language content as defined by this specification.
In particular, the formal validity of TTML Content
is defined by 3.1 Document Conformance.

E Features

This appendix is normative.

This appendix specifies (1) a set of feature designations, each of which
labels one or more syntactic and/or semantic features defined by this
specification, and (2) for each designated feature, whether the feature is mandatory
or optional for a transformation or presentation processor.

Note:

A TTML processor is said to implement the transformation semantics or
implement the presentation semantics of feature designation F
if it satisfies the requirements of this appendix with respect to the definition of
feature designation F as pertains to transformation or
presentation processing, respectively.

E.1 Feature Designations

A feature designation is expressed as a string that adheres to the following
form:

E.1.2 #backgroundColor

A TTML presentation processor supports the
#backgroundColor feature if it (1) implements presentation semantic support
for the tts:backgroundColor
attribute
and (2) is capable of displaying or generating an output display
signal that distinguishes between at least sixteen (16) values of color,
including all primary and secondary colors of the SRGB color space.

E.1.3 #backgroundColor-block

A TTML transformation processor supports the
#backgroundColor-block feature if it recognizes and is
capable of transforming all defined values of the tts:backgroundColor
attribute when applied to a content element that would generate a
block area during presentation processing.

A TTML presentation processor supports the
#backgroundColor-block feature if it (1) implements presentation semantic
support for the tts:backgroundColor
attribute when applied to a content element that generates a
block area
and (2) is capable of displaying or generating an output display
signal that distinguishes between at least sixteen (16) values of color,
including all primary and secondary colors of the SRGB color space.

E.1.4 #backgroundColor-inline

A TTML transformation processor supports the
#backgroundColor-inline feature if it recognizes and is
capable of transforming all defined values of the tts:backgroundColor
attribute when applied to a content element that would generate an
inline area during presentation processing.

A TTML presentation processor supports the
#backgroundColor-inline feature if it (1) implements presentation semantic
support for the tts:backgroundColor
attribute when applied to a content element that generates an
inline area
and (2) is capable of displaying or generating an output display
signal that distinguishes between at least sixteen (16) values of color,
including all primary and secondary colors of the SRGB color space.

A TTML presentation processor supports the
#backgroundColor-region feature if it (1) implements presentation semantic
support for the tts:backgroundColor
attribute when applied to a region element
and (2) is capable of displaying or generating an output display
signal that distinguishes between at least sixteen (16) values of color,
including all primary and secondary colors of the SRGB color space
.

E.1.6 #bidi

A TTML processor supports the #bidi feature if it
supports the following features:

E.1.7 #border

A TTML presentation processor supports the
#border feature if it (1) implements presentation semantic support
for the tts:border
attribute
and (2) is capable of displaying or generating an output display
signal that distinguishes between at least sixteen (16) values of border colors,
including all primary and secondary colors of the SRGB color space.

E.1.13 #color

A TTML presentation processor supports the
#color feature if it (1) implements presentation semantic support
for the tts:color
attribute
and (2) is capable of displaying or generating an output display
signal that distinguishes between at least sixteen (16) values of color,
including all primary and secondary colors of the SRGB color space.

E.1.18 #display-block

A TTML transformation processor supports the
#display-block feature if it recognizes and is
capable of transforming all defined values of the tts:display
attribute when applied to a content element that would generate a
block area during presentation processing.

A TTML presentation processor supports the
#display-block feature if it implements presentation semantic
support for all defined values of the tts:display
attribute when applied to a content element that generates a
block area.

E.1.19 #display-inline

A TTML transformation processor supports the
#display-inline feature if it recognizes and is
capable of transforming all defined values of the tts:display
attribute when applied to a content element that would generate an
inline area during presentation processing.

A TTML presentation processor supports the
#display-inline feature if it implements presentation semantic
support for all defined values of the tts:display
attribute when applied to a content element that generates an
inline area.

A TTML presentation processor supports the
#fontSize-anamorphic feature if it implements presentation semantic
support for defined values of the tts:fontSize
attribute that consist of two <length> specifications.

A TTML presentation processor supports the
#fontSize-isomorphic feature if it implements presentation semantic
support for defined values of the tts:fontSize
attribute that consist of a single <length> specification.

A TTML presentation processor supports the #layout
feature if it implements presentation semantic support for the
same vocabulary and features enumerated above.

E.1.43 #length

A TTML transformation processor supports the #length
feature if it recognizes and is capable of transforming all defined
values of the <length>
style value expression.

A TTML presentation processor supports the #length
feature if it implements presentation semantic support for all defined values of
the <length> style value
expression.

Note:

Support for #length is intended to imply support for the following features:
#length-integer,
#length-real,
#length-positive,
#length-negative,
#length-cell,
#length-em,
#length-percentage, and
#length-pixel.

E.1.44 #length-cell

A TTML transformation processor supports the
#length-cell feature if it recognizes and is capable of
transforming scalar values of the <length> style value expression
that use c (cell) units.

A TTML presentation processor supports the
#length-cell feature if it implements presentation semantic support
for scalar values of the <length> style value expression
that use c (cell) units.

Note:

Support for #length-cell does not, by itself, imply support for
#length-integer,
#length-real,
#length-positive, or
#length-negative features.

E.1.45 #length-em

A TTML transformation processor supports the
#length-em feature if it recognizes and is capable of
transforming scalar values of the <length> style value expression
that use em (EM) units.

A TTML presentation processor supports the
#length-em feature if it implements presentation semantic support
for scalar values of the <length> style value expression
that use em (EM) units.

Note:

Support for #length-em does not, by itself, imply support for
#length-integer,
#length-real,
#length-positive, or
#length-negative features.

E.1.46 #length-integer

A TTML transformation processor supports the
#length-integer feature if it recognizes and is
capable of transforming integer values of the <length> style value
expression.

A TTML presentation processor supports the
#length-integer feature if it implements presentation semantic
support for integer values of the <length> style value
expression.

Note:

Support for #length-integer does not, by itself, imply support for
#length-positive or
#length-negative features.

E.1.47 #length-negative

A TTML transformation processor supports the
#length-negative feature if it recognizes and is
capable of transforming negative values of the <length> style value
expression.

A TTML presentation processor supports the
#length-negative feature if it implements presentation semantic
support for negative values of the <length> style value
expression.

Note:

Support for #length-negative does not, by itself, imply support for
#length-integer or
#length-real features.

E.1.48 #length-percentage

A TTML transformation processor supports the
#length-percentage feature if it recognizes and is
capable of transforming percentage values of the <length> style value
expression.

A TTML presentation processor supports the
#length-percentage feature if it implements presentation semantic
support for percentage values of the <length> style value
expression.

Note:

Support for #length-percentage does not, by itself, imply support for
#length-integer,
#length-real,
#length-positive, or
#length-negative features.

E.1.49 #length-pixel

A TTML transformation processor supports the
#length-pixel feature if it recognizes and is capable of
transforming scalar values of the <length> style value expression
that use px (pixel) units.

A TTML presentation processor supports the
#length-pixel feature if it implements presentation semantic support
for scalar values of the <length> style value expression
that use px (pixel) units.

Note:

Support for #length-pixel does not, by itself, imply support for
#length-integer,
#length-real,
#length-positive, or
#length-negative features.

E.1.50 #length-positive

A TTML transformation processor supports the
#length-positive feature if it recognizes and is
capable of transforming positive values of the <length> style value
expression.

A TTML presentation processor supports the
#length-positive feature if it implements presentation semantic
support for positive values of the <length> style value
expression.

Note:

Support for #length-positive is intended to imply support for zero valued
<length> style value
expressions.

Note:

Support for #length-positive does not, by itself, imply support for
#length-integer or
#length-real features.

E.1.51 #length-real

A TTML transformation processor supports the
#length-real feature if it recognizes and is
capable of transforming real values of the <length> style value
expression.

A TTML presentation processor supports the
#length-real feature if it implements presentation semantic
support for real values of the <length> style value
expression.

Note:

Support for #length-real is intended to imply support for
integer valued <length> style value
expressions as well as real valued expressions.

Note:

Support for #length-real does not, by itself, imply support for
#length-positive or
#length-negative features.

E.1.52 #lineBreak-uax14

A TTML transformation processor supports the
#lineBreak-uax14 feature if it recognizes and is capable of
transforming requirements expressed by [UAX14] into its
target document space.

A TTML presentation processor supports the
#lineBreak-uax14 feature if it implements presentation semantic support
for [UAX14] as applies to line breaking.

A TTML presentation processor supports the #metadata
feature if it recognizes and is capable of presenting the information
expressed by the same vocabulary enumerated above.

Note:

This specification does not define a standardized form for the
presentation of metadata information. The presentation or ability to
present metadata information is considered to be implementation
dependent.

E.1.60 #opacity

A TTML presentation processor supports the
#opacity feature if it (1) implements presentation semantic support for
the tts:opacity
attribute and (2) is capable of displaying or generating an output display
signal that distinguishes between at least eight (8) values of opacity.

A TTML presentation processor supports the
#textDecoration-through feature if it implements
presentation semantic support for the lineThrough and
noLineThrough values of the tts:textDecoration
attribute.

E.1.91 #textOutline-blurred

A TTML transformation processor supports the
#textOutline-blurred feature if it recognizes and is capable of
transforming values of the tts:textOutline
attribute that includes a blur radius specification.

A TTML presentation processor supports the
#textOutline-blurred feature if it implements presentation semantic support
for values of the tts:textOutline
attribute that includes a blur radius specification.

E.1.92 #textOutline-unblurred

A TTML transformation processor supports the
#textOutline-unblurred feature if it recognizes and is capable of
transforming values of the tts:textOutline
attribute that does not include a blur radius specification.

A TTML presentation processor supports the
#textOutline-unblurred feature if it implements presentation semantic support
for values of the tts:textOutline
attribute that does not include a blur radius specification.

E.1.98 #time-clock

A TTML transformation processor supports the
#time-clock feature if it recognizes and is capable of
transforming all values of the <time-expression> that
satisfy the following subset of time expression syntax:

<time-expression>
: hours ":" minutes ":" seconds ( fraction )?

A TTML presentation processor supports the
#time-clock feature if it implements presentation
semantic support for the same syntax specified above.

A TTML presentation processor supports the
#time-clock-with-frames feature if it implements
presentation semantic support for the same features and syntax
specified above.

E.1.100 #time-offset

A TTML transformation processor supports the
#time-offset feature if it recognizes and is capable of
transforming all values of the <time-expression> that
satisfy the following subset of time expression syntax:

<time-expression>
: time-count fraction? ( "h" | "m" | "s" | "ms" )

A TTML presentation processor supports the
#time-offset feature if it implements presentation
semantic support for the same syntax specified above.

A TTML presentation processor supports the
#time-offset-with-frames feature if it implements
presentation semantic support for the same features and syntax
specified above.

E.1.102 #time-offset-with-ticks

A TTML transformation processor supports the
#time-offset-with-ticks feature if it supports the
#tickRate feature
and if it recognizes and is capable of
transforming all values of the <time-expression> that
satisfy the following subset of time expression syntax:

<time-expression>
: time-count fraction? "t"

A TTML presentation processor supports the
#time-offset-with-ticks feature if it implements presentation
semantic support for the same features and syntax specified above.

E.1.103 #timing

A TTML presentation processor supports the #timing
feature if it implements presentation semantic support for the
same vocabulary enumerated above.

E.1.104 #transformation

A TTML processor supports the
#transformation feature if it
(1) satisfies the generic processor criteria defined by
3.2.1 Generic Processor Conformance and
(2) implements the transformation semantics of the following features:

E.1.108 #visibility-block

A TTML transformation processor supports the
#visibility-block feature if it recognizes and is
capable of transforming all defined values of the tts:visibility
attribute when applied to a content element that would generate a
block area during presentation processing.

A TTML presentation processor supports the
#visibility-block feature if it implements presentation semantic
support for all defined values of the tts:visibility
attribute when applied to a content element that generates a
block area.

E.1.109 #visibility-inline

A TTML transformation processor supports the
#visibility-inline feature if it recognizes and is
capable of transforming all defined values of the tts:visibility
attribute when applied to a content element that would generate an
inline area during presentation processing.

A TTML presentation processor supports the
#visibility-inline feature if it implements presentation semantic
support for all defined values of the tts:visibility
attribute when applied to a content element that generates an
inline area.

E.2 Feature Support

The following table, Table E-1 – Feature Support,
enumerates every defined feature designation (expressed without the TT
Feature Namespace), and, for each designated feature, specifies
whether the feature must be implemented, i.e., is mandatory (M), or may be implemented, i.e.,
is optional (O), for transformation and presentation processors.

If the extension namespace of an extension designation is the TT
Extension Namespace, then all values of the following
designation token are reserved for future
standardization.

If the extension namespace of an extension designation is not the
TT Extension Namespace, i.e., is an Other Extension Namespace,
then the extension namespace must be expressed as an absolute URI
capable of serving as a base URI used in combination with a
designation token that takes the form of a fragment
identifier.

H Time Expression Semantics

This appendix is normative.

This appendix specifies the semantics for interpreting time expressions in document instances.

Note:

The phrase local real time as used below is intended to model a virtual real time clock in the document processing context, where
local means in the immediate proximity of the implementation of this processing context. The intent
of defining relationships with this virtual clock is to establish a locally valid physical realization of time for didactic purposes.

Note:

The phrase play rate as used below is intended to model a (possibly variable) parameter in the document processing context wherein
the rate of playback (or interpretation) of time may artificially dilated or narrowed, for example, when slowing down or speeding up the rate of
playback of a related media object. Without loss of generality, the following discussion assumes a fixed play(back) rate. In the case of
variable play rates, appropriate adjustments may need to be made to the resulting computations.

H.1 Clock Time Base

When operating with the clock time base, the following semantics apply for interpreting time expressions,
as defined by <time-expression>, and their relationship to media time and local real time.

The clock time base C is related to local real time R
expressed in an arbitrary (implementation defined) epoch E
as follows:

TTML Semantics – Clock Time and Real Time Relationship

R = C + epochOffset + discontinuityOffset

where C ∈ ℜ, 0 ≤ C < ∞, C in seconds since the most immediately prior midnight of the reference clock base;

epochOffset ∈ ℜ, 0 ≤ epochOffset < ∞, epochOffset in seconds, with 0 being the beginning
of epoch E, and where the value of epochOffset is determined from the computed value of the ttp:clockMode parameter
as follows:

(1) if local, then the difference between the local real time at the most immediately prior local midnight and the local real time
at the beginning of epoch E, expressed in seconds;

(2) if gps, then the difference between the GPS time at the most immediately prior GPS midnight
and the GPS time at the beginning of epoch E, expressed in seconds;

(3) if utc, then the difference between the UTC time at the most immediately prior UTC midnight
and the UTC time at the beginning of epoch E, expressed in seconds;

discontinuityOffset ∈ ℜ, −∞ < discontinuityOffset < ∞, discontinuityOffset in seconds,
and where the value of discontinuityOffset is equal to the sum of leap seconds (and fractions thereof) that have been added (or subtracted) since the
most immediately prior midnight in the reference clock base;

and epochOffset and discontinuityOffset are determined once and only once prior to the beginning of the root temporal extent such that
during the period between value determination and the beginning of the root temporal extent there occurs no local midnight or reference clock base discontinuity.

Time value expressions, as denoted by a <time-expression>, are related to
clock time C as follows:

TTML Semantics – Time Expressions and Clock Time Relationship

If a time expression uses the clock-time form or an offset-time form that doesn't use the ticks (t) metric, then:

C = 3600 * hours + 60 * minutes + seconds

where
hours,
minutes,
seconds components are extracted from time expression if present, or zero if not present.

Otherwise, if a time expression uses an offset-time form that uses the ticks (t) metric, then:

C = ticks / tickRate

Note:

The frames and sub-frames terms and the frames (f) metric of time expressions do not apply when using
the clock time base.

The clock time base C is independent of media time M:

TTML Semantics – Clock Time and Media Time Relationship

M ¬∝ C

Note:

That is to say, timing is disconnected from (not necessarily proportional to) media time when
the clock time base is used. For example, if the media play rate is zero (0), media playback is suspended; however, timing coordinates
will continue to advance according to the natural progression of clock time in direct proportion to the reference clock base. Furthermore, if the media play rate changes
during playback, presentation timing is not affected.

H.2 Media Time Base

When operating with the media time base, the following semantics apply for interpreting time expressions,
as defined by <time-expression>, and their relationship to media time and local real time.

The media time base M is related to local real time R
expressed in an arbitrary (implementation defined) epoch E as follows:

TTML Semantics – Media Time and Real Time Relationship

R = playRate * M + epochOffset

where M ∈ ℜ, 0 ≤ M < ∞, M in seconds, with 0 corresponding to the beginning of the root temporal extent;

playRate ∈ ℜ, −∞ < playRate < ∞, playRate is unit-less, and where the value of
playRate is determined by the document processing context;

and epochOffset ∈ ℜ, 0 ≤ epochOffset < ∞, epochOffset in seconds, with 0 corresponding to the beginning of
an epoch E, and where the value of epochOffset is the difference between the local real time at the beginning of the
root temporal extent and the local real time at the the beginning of epoch E, expressed in seconds.

Time value expressions, as denoted by a <time-expression>, are related to
media time M in accordance to the
ttp:frameRate, ttp:subFrameRate, and ttp:frameRateMultipler parameters as follows:

TTML Semantics – Time Expressions and Media Time Relationship

If a time expression uses a clock-time form or an offset-time form that doesn't use the ticks (t) metric, then:

where referenceBegin is determined according to whether the nearest ancestor time container employs
parallel (par) or sequential (seq) semantics: if parallel or if sequential and no prior sibling
timed element exists, then referenceBegin
is the media time that corresponds to the beginning of the nearest ancestor time container or
zero (0) if this time container is the root temporal extent; otherwise, if sequential and a prior sibling
timed element exists, then referenceBegin is the media time that corresponds to the active end of the
immediate prior sibling timed element;

the hours, minutes, seconds, frames, subFrames components
are extracted from time expression if present, or zero if not present;

subFrameRate is the computed value of the ttp:subFrameRate parameter;

and effectiveFrameRate (in frames per second) is frameRate * frameRateMultipler where
frameRate is the computed value of the ttp:frameRate parameter and
frameRateMultipler is the computed value of the ttp:frameRateMultiplier parameter.

Otherwise, if a time expression uses an offset-time form that uses the ticks (t) metric, then:

M = referenceBegin + ticks / tickRate

where referenceBegin is as described above;

the ticks component is extracted from time expression;

and tickRate is the computed value of the ttp:tickRate parameter;

Note:

If the computed frameRateMultipler ratio is not integral, then effectiveFrameRate will be a non-integral rational.

If the computed value of the ttp:markerMode parameter is discontinuous, then there is no direct relationship between
time expressions and media time M or local real time R. In
this case, time expressions refer to synchronization events (markers) emitted by the document processing context
when smpte time codes
are encountered in the related media object.

Otherwise, if the computed value of the ttp:markerMode parameter is continuous, then the relationships between time expressions and
local real time and media time are as described below in terms of a synthetic smpte document syncbase, here referred to as the
SMPTE time base S.

and effectiveFrameRate (in frames per second) is frameRate * frameRateMultipler where
frameRate is the computed value of the ttp:frameRate parameter and
frameRateMultipler is the computed value of the ttp:frameRateMultiplier parameter.

Notwithstanding the above, if a time expression contains a frame code that is designated as
dropped according to 7.2.3 ttp:dropMode, then that time expression
must be considered to be invalid for purposes of validation assessment.

The SMPTE time base S is related to the media time base M as follows:

TTML Semantics – SMPTE Time and Media Time Relationship

M = referenceBegin + S

where referenceBegin is determined according to whether the nearest ancestor time container employs
parallel (par) or sequential (seq) semantics: if parallel or if sequential and no prior sibling
timed element exists, then referenceBegin
is the SMPTE time that corresponds to the beginning of the nearest ancestor time container or
zero (0) if this time container is the root temporal extent; otherwise, if sequential and a prior sibling
timed element exists, then referenceBegin is the SMPTE time that corresponds to the active end of the
immediate prior sibling timed element;

Given the derived media time base as described above, then
media time base M is related to the local real time R
as described in H.2 Media Time Base above.

I Intermediate Document Syntax

This appendix is normative.

This appendix specifies the syntactic elements and structure of a
timed text intermediate document.
An ISD instance may be represented as a standalone document instance or
in a collection represented as an ISD Sequence instance.

All ISD related vocabulary is defined in the TTML ISD Namespace, defined here as http://www.w3.org/ns/ttml#isd,
where the recommended prefix is isd.

A TTML Intermediate Synchronic Document, in short, an ISD or ISD instance,
represents a discrete, temporally non-overlapping interval, an ISD interval,
of a source TTML document where, except for non-discrete animation, all content, styling, and layout information remains static within that interval.
In particular, the timing hierarchy of a TTML document is flattened and then sub-divided into temporally non-overlapping intervals, where each such
interval defines a static view of the source TTML document within that interval, and where that static view is represented as an ISD instance.
A concrete, standalone instance of a TTML
Intermediate Synchronic Document must specify an
isd:isd element as its root document element. When an instance of a
Intermediate Synchronic Document is included in a
Intermediate Synchronic Document Sequence instance, then the ISD instance is represented
by an isd:isd child element of the root
isd:sequence element.

Note:

An ISD instance may contain one or more animate elements that denote continuous animation within the associated interval. Continuously animated styles are sub-divided across
ISD interval boundaries such that their step-wise concatenation expresses an equivalent continuous animation over any intersecting ISD interval(s).

If the size attribute is specified, then it must be a non-negative integer corresponding to the number of
isd:isd child elements.
If not specified, then the size must be considered to be indefinite, unless and until the
isd:sequence element is terminated, in which case the size
may be determined by inspection.

Note:

The size attribute would normally be omitted in the case of real time captioning.

If the version attribute is specified, then it must be a positive integer corresponding to the version of this
Intermediate Synchronic Document Syntax specification used in authoring
the ISD sequence document. If specified, the numeric value must be greater than or equal to two (2). If not specified, then the version must be
consider to be equal to two (2). The version associated with this
Intermediate Synchronic Document Syntax specification is two (2).

Note:

The ISD abstraction referred to or implied by [TTML1] §9.3.2 was not concretely defined by that specification. Here we reserve version one (1)
for informal discussion of that earlier abstraction and its various (non-standardized) realizations.

If a child ttp:profile element is present,
then that ttp:profile element must satisfy the following constraints:

no combine attribute is specified;

no designator attribute is specified;

no type attribute is specified;

no use attribute is specified;

no descendant element is a ttp:profile element;

no descendant ttp:feature element specifies a value attribute with the value prohibited;

no descendant ttp:extension element specifies a value attribute with the value prohibited.

Furthermore, such a child ttp:profile element must specify a profile that is equivalent to the combined
processor profile of the source TTML document having fetched all externally referenced profile documents.

Note:

The intent of permitting a single ttp:profile to be specified in an
isd:sequence is to provide a simplified mechanism to declare
processor profile requirements that must be met in order to process the document (in the absence of an end-user override).

The isd:isd element accepts as its children zero or more ttm:metadata elements,
followed by zero or one ttp:profile element,
followed by zero or more isd:css elements,
followed by zero or more isd:region elements.

A begin attribute must be specified, the value of which must take the offset-time form of
a <time-expression>, and, further, is restricted to use a metric of
s (seconds),
f (frames),
t (ticks), or may omit the metric, in which case s seconds is implied. This
begin time is expressed as an offset from the begin time of the root temporal extent
of the source TTML document from which this isd:isd element was derived.

An end attribute must be similarlly specified, where the same constraints apply.
This end time is expressed as an offset from the begin time of the root temporal extent
of the source TTML document from which this isd:isd element was derived.

Note:

Expressed in the terminology of [SMIL 3.0], the values of these begin and end attributes
correspond to the resolved begin and end times of the active duration with respect to the document begin.

An xml:lang attribute must be specified on the
isd:isd element if it is a standalone Intermediate
Synchronic Document document; otherwise, it may be specified, and should be specified if the default language of the
isd:isd element differs from the default language of its
parent isd:sequence element.
If its value is empty, it signifies that there is no default language that applies
to the content within the Intermediate Synchronic Document. Otherwise,
the specified value denotes the default language that applies.

The version attribute follows the syntax and semantics of the same named attribute on the
isd:sequence element type. The version
attribute must not be specified on an isd:isd element that is not
a root document element, i.e., is a child element of an isd:sequence element.

I.1.3 isd:css

The isd:css element is used to represent a unique computed style set of some collection of elements
that share the same set of computed styles. In particular, for each
element E in the source TTML document which is selected and copied into a
isd:region element of a given
Intermediate Synchronic Document, the computed style
set of E, CSS(E), is determined, and, if that CSS(E) is not already specified
by an existing isd:css element, then it is assigned a unique identifier and instantiated as a new
isd:css element.

The isd:css element accepts as its children zero or more ttm:metadata elements.

For each arbitrary pair of isd:css child elements of an
isd:isd element,
S1 and S2, the set of specified styles of S1 must
not be the same as the set of specified styles of S2. For the purpose of comparing two
sets of specified styles, the styles must be placed into a canonical order and then compared item
by item for value equality, where the canonical order is in accordance to the qualified attribute name
order, where each qualified name consists of a tuple <namespace URL, local name>,
and such tuples are compared component-wise by case-sensitive lexical string order.

I.1.4 isd:region

The isd:region element is used to represent a layout and presentation region
and the content selected into that region, where that content takes the form of a
body element and its descendant TTML content elements.

The isd:region element accepts as its children zero or more ttm:metadata elements,
followed by zero or more animate elements,
followed by exactly one body element.

If the computed style set of the region represented by the isd:region element is not the
set of initial style values that apply to region, then a
style attribute must be specified which references an isd:css element that specifies the
region's computed style set.

The following constraints apply to the body element
and its descendant elements:

no significant text node, i.e., text node in a #PCDATA context, is not contained in a
span element that contains no other child.

In addition, for the body element B and
each of its descendant content elements C, if the computed style set of B or each C is
not equal to the computed style set of its parent element, then that element, B or C, must specify a style
attribute that references an isd:css element that specifies the
element's computed style set.

When a resource consisting of a concrete ISD Sequence or ISD instance is interchanged and a media type is used to identify the content type
of that resource, then the media type application/ttml+xml should be used, about which see [TTML1] Appendix C.
If this media type is used, the optional profile parameter must not be specified, or, if specified, must be ignored by a processor.

L Requirements (Non-Normative)

The Timed Text Markup Language (TTML), also known as the Distribution Format Exchange Profile (DFXP) of the Timed Text Authoring
Format (TTAF), satisfies a subset of the requirements established by
[TTAF1-REQ]. The following table enumerates these requirements and
indicates the extent to which they are satisfied by this specification, where
S denotes a requirement is satisfied, P denotes
a requirement is partially satisfied, and N denotes a
requirement is not satisfied.