General

This specification defines two profiles of [[TTML2]]: the Text Profile and the Image Profile. In the Text Profile, timed text is expressed using Unicode text exclusively, whereas, in the Image Profile, timed text is expressed using bitmap images exclusively. The clear distinction between the two profiles reduces authoring and processing complexity. For example, it allows systems to unambiguously specify whether text- and/or image-based timed text is permitted.

Image-based timed text images can be used in scenarios where the required text rendering functionality is not available, for example if the required fonts can not be distributed, or if the receiving processor has insufficient computing resources to present text while displaying video. They can also be used to achieve a visual effect that is beyond the capabilities of TTML, e.g. illuminated letters.

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

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

The altText named metadata item also allows text equivalent string to be associated with an image, e.g. to support indexation of the content and also facilitate quality checking of the document during authoring.

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

Text Profile

The Text Profile consists of Sections , and .

Image Profile

The Image Profile consists of Sections , and .

Profile Resolution Semantics

Document Encoding

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

Foreign Element and Attributes

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

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

Namespaces

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

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

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

Overflow

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

As specified in [[!TTML2]], tts:overflow has no effect on the extent of the region, and hence the total normalized drawing area S(E_n) at .

Related Video Object

A Document Instance MAY be associated with a Related Video Object.

While this specification contains specific provisions when a Document Instance is associated with a Related Video Object, it does not prevent the use of a Document Instance with other kinds of Related Media Object, e.g. an audio object.

Synchronization

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

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

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

Mapping the Root Container Region to the Related Video Object

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

1. the ratio of the width to the height of the rectangular area is equal to the display aspect ratio of the Root Container Region as determined in Appendix H of [[!TTML2]];
2. the center of the rectangular area is collocated with the center of the image frame;
3. the rectangular area is entirely within the image frame; and
4. the rectangular area has a height or width equal to that of the image frame.

Extension Vocabulary

ittp:aspectRatio
  : numerator denominator          // with int(numerator) != 0 and int(denominator) != 0
                                   // where int(s) parses string s as a decimal integer.

numerator | denominator
  : <digit>+                 // no linear white-space is implied or permitted
                                   // between each <digit> token

ittp:progressivelyDecodable
  : "true"
  | "false"

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

<ittm:altText
  xml:id = ID
  xml:lang = string
  xml:space = (default|preserve)
  {any attribute not in the default namespace, any TT namespace or any IMSC namespace}>
  Content: #PCDATA
</ittm:altText>

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

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

itts:fillLineGap

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

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

The itts:fillLineGap attribute SHALL conform to the following:

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

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

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

Profile Signaling

Hypothetical Render Model

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

Style Resolution

The following style properties are subject to the Style Resolution procedures specified at Section 10.5 of [[!TTML2]]:

• itts:fillLineGap
• itts:forcedDisplay
• ebutts:linePadding
• ebutts:multiRowAlign

Constraints

Profile Designator

This profile is associated with the following profile designator:

Recommended Character Sets

A Document Instance SHOULD be authored using characters selected from the sets specified in .

Reference Fonts

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

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

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

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

Constraints

Profile Designator

This profile is associated with the following profile designator:

Presented Image

Image Resources

An image resource is a PNG datastream as specified in [[!PNG]].

If a pHYs chunk is present, it SHALL indicate square pixels.

[[PNG]] specifies that, if no pixel aspect ratio is carried, the default of square pixels is assumed.

Constraints

Overview (non-normative)

This Section specifies the Hypothetical Render Model illustrated in .

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

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

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

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

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

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

General

The Presentation Compositor SHALL render in Presentation Buffer P_n each successive intermediate synchronic document E_n using the following steps in order:

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

The Presentation Compositor SHALL start rendering E_n:

• at the presentation time of E₀ minus Initial Painting Delay (IPD), if n = 0; or
• at the presentation time of E_n-1, if n > 0.

The duration DUR(E_n) for painting an intermediate synchronic document E_n in the Presentation Buffer P_n SHALL be:

DUR(E_n) = S(E_n) / BDraw + DUR_T(E_n) + DUR_I(E_n)

where

• S(E_n) is the total normalized drawing area for intermediate synchronic document E_n, as specified in ;
• BDraw is the normalized background drawing performance factor;
• DUR_T(E_n) is the duration, in seconds, for painting the text subtitle content for intermediate synchronic document E_n, as specified in Section ; and
• DUR_I(E_n) is the duration, in seconds, for painting the image subtitle content for intermediate synchronic document E_n, as specified in Section .

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

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

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

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

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

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

Paint Regions

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

S(E_n) = CLEAR(E_n) + PAINT(E_n )

where CLEAR(E₀) = 0 and CLEAR(E_{n | n > 0}) = 1, i.e. the Root Container Region in its entirety.

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

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

PAINT(E_n) = ∑_Ri∈Rp NSIZE(R_i) ∙ NBG(R_i)

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

NSIZE(R_i) SHALL be given by:

NSIZE(R_i) = (width of R_i ∙ height of R_i ) ÷ (Root Container Region height ∙ Root Container Region width)

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

• it is specified on the region layout element that defines the region; or
• it is specified on a div, p, span or br content element that is to be flowed into the region for presentation in the intermediate synchronic document (see [[!TTML2]] for more details on when a content element is followed into a region); or
• it is specified on a set animation element that is to be applied to content elements that are to be flowed into the region for presentation in the intermediate synchronic document (see [[!TTML2]] for more details on when a set animation element is applied to content elements).

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

Paint Images

The Presentation Compositor SHALL paint into the Presentation Buffer P_n all visible pixels of presented images of intermediate synchronic document E_n.

For each presented image, the Presentation Compositor SHALL either:

• if an identical image is present in Decoded Image Buffer D_n, copy the image from Decoded Image Buffer D_n to the Presentation Buffer P_n using the Image Copier; or
• if an identical image is present in Decoded Image Buffer D_n-1, i.e. an identical image was present in intermediate synchronic document E_n-1, copy using the Image Copier the image from Decoded Image Buffer D_n-1 to both the Decoded Image Buffer D_n and the Presentation Buffer P_n; or
• otherwise, decode the image using the Image Decoder the image into the Presentation Buffer P_n and Decoded Image Buffer D_n.

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

The duration DUR_I(E_n) for painting images of an intermediate synchronic document E_n in the Presentation Buffer SHALL be as follows:

DUR_I(E_n) = ∑_{Ii ∈ Ic} NRGA(I_i) / ICpy + ∑_{Ij ∈ Id} NSIZ(I_j) / IDec

where

• I_c is the set of images copied when painting intermediate synchronic document E_n;
• I_d is the set of images decoded when painting intermediate synchronic document E_n;
• IDec is the image decoding rate; and
• ICpy is the normalized image copy performance factor.

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

NRGA(I_i)= (width of I_i ∙ height of I_i ) ÷ ( Root Container Region height ∙ Root Container Region width )

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

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

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

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

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

Paint Text

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

• tts:color
• tts:fontFamily
• tts:fontSize
• tts:fontStyle
• tts:fontWeight
• tts:textDecoration
• tts:textOutline

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

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

• if an identical glyph is present in Glyph Buffer G_n, copy the glyph from Glyph Buffer G_n to the Presentation Buffer P_n using the Glyph Copier; or
• if an identical glyph is present in Glyph Buffer G_n-1, i.e. an identical glyph was present in intermediate synchronic document E_n-1, copy using the Glyph Copier the glyph from Glyph Buffer G_n-1 to both the Glyph Buffer G_n and the Presentation Buffer P_n; or
• otherwise render using the Glyph Renderer the glyph into the Presentation Buffer P_n and Glyph Buffer G_n.

The duration DUR_T(E_n) for rendering the text of an intermediate synchronic document E_n in the Presentation Buffer is as follows:

DUR_T(E_n) = ∑_{gi ∈ Γr} NRGA(g_i) / Ren(g_i) + ∑_{gj ∈ Γc} NRGA(g_j) / GCpy

where

• Γ_r is the set of glyphs rendered into the Presentation Buffer P_n using the Glyph Renderer in intermediate synchronic document E_n;
• Γ_c is the set of glyphs copied to the Presentation Buffer P_n using the Glyph Copier in intermediate synchronic document E_n;
• Ren(g_i) is the text rendering performance factor for glyph g_i; and
• GCpy is the normalized glyph copy performance factor.

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

NRGA(g_i) = (fontSize of g_i as percentage of Root Container Region height)²

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

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

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

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

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