CÔNG TY TNHH ĐẦU TƯ THƯƠNG MẠI VÀ DỊCH VỤ HỮU QUYẾT Số 2, ngách 1/1 Phố Thiên Hiền, Phường Mỹ Đình 1, Quận Nam Từ Liêm, Thành phố Hà Nội.
MST: 0110557925
Abstract
This document specifies two profiles of [TTML1]: a text-only profile and an image-only profile. These profiles are intended to be used across subtitle and caption delivery applications worldwide, thereby simplifying interoperability, consistent rendering and conversion to other subtitling and captioning formats.
It is feasible to create documents that simultaneously conform to both [ttml10-sdp-us] and the text-only profile.
The document defines extensions to [TTML1], as well as incorporates extensions specified in [ST2052-1] and [EBU-TT-D].
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document was published by the Timed Text Working Group as a Candidate Recommendation. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to [email protected] (subscribe, archives) with [imsc] at the start of your email's subject. W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 28 February 2016. All comments are welcome.
For this specification to exit the CR stage, at least 2 independent implementations of every feature defined in this specification but not already present in [TTML1] need to be documented in the implementation report. The implementation report is based on implementer-provided test results for the test suite (tests and sample content) maintained by the Working Group. The Working Group does not require that implementations are publicly available but encourages them to be so.
The Working Group expects the test suite and the implementation report to evolve significantly before the specification advances to Proposed Recommendation.
The Working Group has not identified features "at risk" for this specification.
Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document specifies two profiles of [TTML1]: a text-only profile and an image-only profile. These profiles are intended for subtitle and caption delivery worldwide, including dialog language translation, content description, captions for deaf and hard of hearing, etc.
The text profile is a syntactic superset of [ttml10-sdp-us], and a document can simultaneously conform to both [ttml10-sdp-us] and the text-only profile.
The document defines extensions to [TTML1], as well as incorporates extensions specified in [ST2052-1] and [EBU-TT-D].
2. Documentation Conventions
This specification uses the same conventions as [TTML1] for the specification of parameter attributes, styling attributes and metadata elements. In particular, Section 2.3 of [TTML1] specifies conventions used in the XML representation of elements.
All content of this specification that is not explicitly marked as non-normative is considered to be normative. If a section or appendix header contains the expression "non-normative", then the entirety of the section or appendix is considered non-normative.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, SHALL, SHALL NOT, SHOULD, and SHOULD NOT are to be interpreted as described in [RFC2119].
SHALL satisfy all normative provisions specified by the profile;
MAY use any vocabulary, syntax or attribute values whose interpretation will be successfully processed by a processor that supports "permitted" features;
SHALL NOT use any vocabulary, syntax or attribute values that would require the processor to implement any "prohibited" features to successfully process the document.
SHALL satisfy the Generic Processor Conformance requirements at Section 3.2.1 of [TTML1];
SHALL satisfy all normative provisions specified by the profile; and
SHALL implement presentation semantic support for all features designated as "permitted" by the profile, subject to any additional constraints on features as specified by the profile.
SHALL satisfy the Generic Processor Conformance requirements at Section 3.2.1 of [TTML1];
SHALL satisfy all normative provisions specified by the profile; and
SHALL implement transformation semantic support for all features designated as "permitted" by the profile, subject to any additional constraints on features as specified by the profile.
Note
The use of the term presentation processor (transformation processor) within this specification does not imply conformance to the DFXP Presentation Profile (DFXP Transformation Profile) specified in [TTML1]. In other words, it is not considered an error for a presentation processor (transformation processor) to conform to a profile defined in this specification without also conforming to the DFXP Presentation Profile (DFXP Transformation Profile).
In applications that require subtitle/caption content in image form to be simultaneously available in text form, two distinct Document Instances, one conforming to the Text Profile and the other conforming to the Image Profile, SHOULD be offered. In addition, the Text ProfileDocument InstanceSHOULD be associated with the Image ProfileDocument Instance such that, when image content is encountered, assistive technologies have access to its corresponding text form. The method by which this association is made is left to each application.
Note
The ittm:altText element specified 6.7.4ittm:altText also allows text equivalent string to be associated with an image, e.g. to support indexation of the content and also facilitate quality checking of the document during authoring.
Annex D.WCAG Considerations specifically discusses this specification in the context of the [WCAG20] guidelines.
The namespace prefix values defined above are for convenience and Document InstancesMAY use any prefix value that conforms to [xml-names].
The namespaces defined by this specification are mutable [namespaceState]; all undefined names in these namespaces are reserved for future standardization by the W3C.
6.4 Overflow
A Document InstanceSHOULD be authored assuming strict clipping of content that falls out of region areas, regardless of the computed value of tts:overflow for the region.
Note
As specified in [TTML1], tts:overflow has no effect on the extent of the region, and hence the total normalized drawing area S(En) at 9.3Paint Regions.
In typical scenario, the same video program (the Related Video Object) will be used for Document Instance authoring, delivery and user playback. The mapping from media time expression to Related Video Object above allows the author to precisely associate subtitle video content with video frames, e.g. around scene transitions. In circumstances where the video program is downsampled during delivery, the application can specify that, at playback, the relative video object be considered the delivered video program upsampled to is original rate, thereby allowing subtitle content to be rendered at the same temporal locations it was authored.
6.7 Extensions
6.7.1 ittp:aspectRatio
The ittp:aspectRatio attributes allows authorial control of the mapping of the root container of a Document Instance to each image frame of the Related Video Object.
If present, the ittp:aspectRatio attribute SHALL conform to the following syntax:
ittp:aspectRatio : numerator denominator // with int(numerator) != 0 and int(denominator) != 0 // where int(s) parses string s as a decimal integer. numerator | denominator : <digit>+
If ittp:aspectRatio is present, the root container SHALL be mapped to a rectangular area within the image frame such that:
the ratio of the width to the height of the rectangular area is equal to ittp:aspectRatio,
the center of the rectangular area is collocated with the center of the image frame,
the rectangular area (including its boundary) is entirely within the image frame (including its boundary), and
the rectangular area has a height or width equal to that of the image frame.
Otherwise, the root container of a Document InstanceSHALL be mapped to the image frame in its entirety.
An ittp:aspectRatio attribute is considered to be significant only when specified on the tt element.
Note
The ittp:aspectRatio parameter effectively defines the intended display aspect ratio (DAR) of the root container, while the tts:extent style property on the root element effectively defines the intended storage aspect ratio (SAR) of the root container.
Note
The mapping algorithm above allows the author to precisely control caption/subtitle position relative to elements within each frame of the video program, e.g. to match the position of actors. This mapping algorithm does not however specify the presentation of either the video frame or root container on the ultimate display device. This presentation depends on many factors, including user input, and can involve displaying only parts of the content. Authors are therefore encouraged to follow best practices for the intended target applications. Below are selected examples:
A 16:9 video program is authored to ensure adequate presentation on 4:3 display devices using a center-cut. Accordingly subtitle/captions are authored using ttp:aspectRatio="4 3", allowing the combination to be displayed on both 4:3 and 16:9 display devices while preserving both caption/subtitles content and the relative position of caption/subtitles with video elements.
A playback system zooms the content of example (a) to fill a 21:9 display, perhaps as instructed by the user. The system elects to scale the root container to fit vertically within the display (maintaining its aspect ratio as authored), at the cost of losing relative positioning between caption/subtitles and video elements.
The system described in (b) instead elects to map the root container to the video frame, maintaining relative positioning between caption/subtitles and video elements but at the risk of clipping subtitles/captions.
6.7.2 ittp:progressivelyDecodable
A progressively decodable Document Instance is structured to facilitate presentation before the document is received in its entirety, and can be identified using ittp:progressivelyDecodable attribute.
A progressively decodable Document Instance is a Document Instance that conforms to the following:
no attribute or element of the TTML timing vocabulary is present within the head element;
given two intermediate synchronic documentsA and B of the Document Instance, with start times TA and TB, respectively, TA is not greater than TB if A includes a p element that lexically precedes any p element that B includes;
no attribute of the TTML timing vocabulary is present on a descendant element of p; and
no element E1 explicitly references another element E2 where the opening tag of E2 is lexically subsequent to the opening tag of E1.
If present, the ittp:progressivelyDecodable attribute SHALL conform to the following syntax:
ittp:progressivelyDecodable : "true" | "false"
An ittp:progressivelyDecodable attribute is considered to be significant only when specified on the tt element.
If not specified, the value of ittp:progressivelyDecodableSHALL be considered to be equal to "false".
[TTML1] specifies explicitly referencing of elements identified using xml:id in the following circumstances:
an element in body referencing region elements. In this case, Requirement 4 above is always satisfied.
an element in body referencing style elements. In this case, Requirement 4 above is always satisfied.
a region element referencing style elements. In this case, Requirement 4 above is always satisfied.
a style element referencing other style elements. In this case, Requirement 4 provides an optimization of style element ordering within the head element.
a ttm:actor element referencing a ttm:agent element. In this case, Requirement 4 provides optimization of metadata elements ordering within the document.
a content element referencing ttm:agent elements using the ttm:agent attribute. In this case, Requirement 4 provides optimization of metadata elements ordering within the document.
6.7.3 itts:forcedDisplay
itts:forcedDisplay can be used to hide content whose computed value of tts:visibility is "visible" when the processor has been configured to do so via the application parameter displayForcedOnlyMode.
If and only if the value of displayForcedOnlyMode is "true", a content element with a itts:forcedDisplay computed value of "false" SHALL NOT produce any visible rendering, but still affect layout, regardless of the computed value of tts:visibility.
The itts:forcedDisplay attribute shall conform to the following:
Values:
false | true
Initial:
false
Applies to:
body, div, p, region, span
Inherited:
yes
Percentages:
N/A
Animatable:
discrete
Annex C.Forced content (non-normative) illustrates the use of itts:forcedDisplay in an application in which a single document contains both hard of hearing captions and translated foreign language subtitles, using itts:forcedDisplay to display translation subtitles always, independently of whether the hard of hearing captions are displayed or hidden.
The presentation processorSHALL accept an optional boolean parameter called displayForcedOnlyMode, whose value MAY be set by a context external to the presentation processor. If not set, the value of displayForcedOnlyModeSHALL be assumed to be equal to "false".
The algorithm for setting the displayForcedOnlyMode parameter based on the circumstances under which the Document Instance is presented is left to the application.
Example 4
... <head> ... <region xml:id="r1" tts:origin="10% 2%" tts:extent="80% 10%" tts:color="white" itts:forcedDisplay="true" tts:backgroundColor="black"/> <region xml:id="r2" tts:origin="10% 80%" tts:extent="80% 88%" tts:color="white" tts:backgroundColor="black"/> ... </head> ... <div> <p region="r1" begin="1s" end="6s">Lycée</p> <!-- the following will not appear if displayForcedOnlyMode='true' --> <p region="r2" begin="4s" end="6s">Nous étions inscrits au même lycée.</p> </div> ...
Note
As specified in [TTML1], the background of a region can be visible even if the computed value of tts:visibility equals "hidden" for all active content within. The background of a region for which itts:forcedDisplay equals "true" can therefore remain visible even if itts:forcedDisplay equals "false" for all active content elements within the region and displayForcedOnlyMode equals "true". Authors can avoid this situation, for instance, by ensuring that content elements and the regions that they are flowed into always have the same value of itts:forcedDisplay.
Note
Although itts:forcedDisplay, like all the TTML style attributes, has no defined semantics on a br content element, itts:forcedDisplay will apply to a br content element if it is either defined on an ancestor content element of the br content element or it is applied to a region element corresponding to a region that the br content element is being flowed into.
Note
It is expected that the functionality of itts:forcedDisplay will be mapped to a conditional style construct in a future revision of this specification.
6.7.4 ittm:altText
ittm:altText allows an author to provide a text string equivalent for an element, typically an image. This text equivalent MAY be used to support indexing of the content and also facilitate quality checking of the document during authoring.
The ittm:altText element SHALL conform to the following syntax:
<ittm:altText xml:id = ID xml:lang = string xml:space = (default|preserve) {any attribute not in the default namespace, any TT namespace or any IMSC 1.0 namespace}> Content: #PCDATA </ittm:altText>
The ittm:altText element SHALL be a child of the metadata element.
... <div region="r1" begin="1s" end="6s" smpte:backgroundImage="1.png"> <metadata> <ittm:altText>Nous étions inscrits au même lycée.</ttm:title> </metadata> </div> ...
Note
In contrast to the common use of alt attributes in [HTML5], the ittm:altText attribute content is not intended to be displayed in place of the element if the element is not loaded. The ittm:altText attribute content can however be read and used by assistive technologies.
6.8 Region
6.8.1 Presented Region
A presented region is a temporally active region that satisfies the following conditions:
the computed value of tts:opacity is not equal to "0.0"; and
the computed value of tts:display is not "none"; and
the computed value of tts:visibility is not "hidden"; and
either (a) content is selected into the region or (b) the computed value of tts:showBackground is equal to "always" and the computed value of tts:backgroundColor has non-transparent alpha.
6.8.2 Dimensions and Position
All regions SHALL NOT extend beyond the root container, i.e. the intersection of the sets of coordinates belonging to a region (including its boundary) and the sets of coordinates belonging to the root container (including its boundary) is the set of coordinates belonging to the region (including its boundary).
The ttp:profile attribute SHOULD be present on the tt element and equal to the designator of the IMSC1 profile to which the document conforms, and the ttp:profile element SHOULD NOT be present, unless:
the document also conforms to [EBU-TT-D], in which case the ttp:profile attribute and the ttp:profile element SHOULD NOT be present, and instead the designator of the IMSC1 profile to which the document conforms and the URI "urn:ebu:tt:distribution:2014-01" SHOULD each be carried in an ebuttm:conformsToStandard element as specified in [EBU-TT-D]; or
the document also conforms to [ttml10-sdp-us], in which case the ttp:profile attribute SHOULD NOT be present. [ttml10-sdp-us] requires that the ttp:profile element be present and that its use attribute be set to a specified value.
See 4.Conformance for a definition of "permitted" and "prohibited".
Feature
Disposition
Additional provision
Relative to the TT Feature namespace
#animation
permitted
#backgroundColor-block
permitted
#backgroundColor-region
permitted
#cellResolution
permitted
If the Document Instance includes any length value that uses the c expression, ttp:cellResolutionSHOULD be present on the tt element.
#clockMode
prohibited
#clockMode-gps
prohibited
#clockMode-local
prohibited
#clockMode-utc
prohibited
#core
permitted
#display-block
permitted
#display-inline
permitted
#display-region
permitted
#display
permitted
#dropMode
prohibited
#dropMode-dropNTSC
prohibited
#dropMode-dropPAL
prohibited
#dropMode-nonDrop
prohibited
#extent-root
permitted
If the Document Instance includes any length value that uses the px expression, tts:extentSHALL be present on the tt element.
#extent
permitted
#frameRate
permitted
If the Document Instance includes any clock time expression that uses the frames term or any offset time expression that uses the f metric, the ttp:frameRate attribute SHALL be present on the tt element.
#frameRateMultiplier
permitted
#layout
permitted
#length-cell
permitted
'c' units SHALL NOT be present outside of the value of ebutts:linePadding.
ttp:tickRateSHALL be present on the tt element if the document contains any time expression that uses the t metric.
#timeBase-clock
prohibited
#timeBase-media
permitted
NOTE: [TTML1] specifies that the default timebase is "media" if ttp:timeBase is not specified on tt.
#timeBase-smpte
prohibited
#time-clock-with-frames
permitted
#time-clock
permitted
#time-offset-with-frames
permitted
#time-offset-with-ticks
permitted
#time-offset
permitted
#timeContainer
permitted
#timing
permitted
All time expressions within a Document InstanceSHOULD use the same syntax, either clock-time or offset-time.
For any content element that contains br elements or text nodes or a smpte:backgroundImage attribute, the begin and end attributes SHOULD be specified on the content element or at least one of its ancestors.
#transformation
permitted
See constraints applied to #profile.
#visibility-block
permitted
#visibility-region
permitted
#writingMode-horizontal-lr
permitted
#writingMode-horizontal-rl
permitted
#writingMode-horizontal
permitted
#zIndex
permitted
Extension
Disposition
Provisions
Relative to the IMSC 1.0 Extension namespace
#aspectRatio
permitted
#forcedDisplay
permitted
#progressivelyDecodable
permitted
#altText
permitted
Note
As specified in [TTML1], a #time-offset-with-frames expression is translated to a media time M according to M = 3600 · hours + 60 · minutes + seconds + (frames ÷ (ttp:frameRateMultiplier · ttp:frameRate)).
7. Text Profile Constraints
7.1 Profile Designator
This profile is associated with the following profile designator:
Profile Name
Profile Designator
IMSC 1.0 Text
http://www.w3.org/ns/ttml/profile/imsc1/text
Note
As specified in 6.11Features, the presence of the ttp:profile attribute is not required by this profile. The profile designator specified above is intended to be generally used to signal conformance of a Document Instance to the profile. The details of such signaling depends on the application, and can, for instance, use metadata structures out-of-band of the Document Instance.
The flow of text within a region depends the dimensions and spacing (kerning) between individual glyphs. The following allows, for instance, region extents to be set such that text flows without clipping.
When rendering codepoints matching one of the combinations of computed font family and codepoints listed in A.Reference Fonts, a processor SHALL use a font that generates a glyph sequence whose dimension is substantially identical to the glyph sequence that would have been generated by one of the specified reference fonts.
Note
Implementations can use fonts other than those specified in A.Reference Fonts. Two fonts with equal metrics can have a different appearance, but flow identically.
7.4 Features
See 4.Conformance for a definition of "permitted" and "prohibited".
Feature
Disposition
Additional provisions
Relative to the TT Feature namespace
#backgroundColor-inline
permitted
#backgroundColor
permitted
#bidi
permitted
#content
permitted
#color
permitted
The initial value of tts:colorSHALL be "white". NOTE: This is consistent with [ST2052-1].
#direction
permitted
#displayAlign
permitted
#extent-region
permitted
The tts:extent attribute SHALL be present on all region elements, where it SHALL use either px units or "percentage" syntax.
#fontFamily-generic
permitted
A tts:fontFamily of either "monospaceSerif" or "proportionalSansSerif"SHOULD be specified for all presented text content. A tts:fontFamily of "default"SHALL be equivalent to "monospaceSerif".
The processorSHALL implement the #lineBreak-uax14 feature defined in the TT Feature namespace.
#lineHeight
permitted
As implementation of the "normal" value is not uniform at the time of this writing, tts:lineHeightSHOULD NOT be set to "normal" and SHOULD be explicitly specified such that the specified style set of each p element contains a tts:lineHeight property whose value is not assigned by initial value fallback.
#nested-div
permitted
#nested-span
permitted
#origin
permitted
The tts:origin attribute SHALL use px units or "percentage" representation, and SHALL NOT use em units.
#padding-1
permitted
#padding-2
permitted
#padding-3
permitted
#padding-4
permitted
#padding
permitted
#textAlign-absolute
permitted
#textAlign-relative
permitted
#textAlign
permitted
#textDecoration-over
permitted
#textDecoration-through
permitted
#textDecoration-under
permitted
#textDecoration
permitted
#textOutline-blurred
prohibited
#textOutline-unblurred
permitted
#textOutline
permitted
The computed value of tts:textOutline on a span element SHALL be 10% or less than the computed value of tts:fontSize on the same element.
#unicodeBidi
permitted
#visibility
permitted
#visibility-inline
permitted
#wrapOption
permitted
#writingMode
permitted
#writingMode-vertical
permitted
Extension
Disposition
Provisions
Relative to the SMPTE-TT Extension Namespace
#image
prohibited
Relative to the IMSC 1.0 Extension namespace
#linePadding
permitted
If used, the attribute ebutts:linePaddingMAY be specified on elements region, body, div and p in addition to style.
In contrast to this specification, [EBU-TT-D] specifies that the attributes ebutts:linePadding and ebutts:multiRowAlign are allowed only on the style element.
8. Image Profile Constraints
8.1 Profile Designator
This profile is associated with the following profile designator:
Profile Name
Profile Designator
IMSC 1.0 Image
http://www.w3.org/ns/ttml/profile/imsc1/image
Note
As specified in 6.11Features, the presence of the ttp:profile attribute is not required by this profile. The profile designator specified above is intended to be generally used to signal conformance of a Document Instance to the profile. The details of such signaling depends on the application, and can, for instance, use metadata structures out-of-band of the Document Instance.
8.2 Presented Image
8.2.1 Definition
A presented image is a div element with a smpte:backgroundImage attribute that flows into a presented region.
8.2.2 Constraints
In a given synchronic document, each presented regionSHALL contain at most one div element, which SHALL be a presented image.
8.2.3 Intermediate Synchronic Document Construction
For the purposes of constructing an intermediate synchronic document, a div element with a smpte:backgroundImage attribute SHALL NOT be considered empty.
8.3 smpte:backgroundImage Constraints
If a smpte:backgroundImage attribute is applied to a div element:
the width and height (in pixels) of the image source referenced by smpte:backgroundImageSHALL be equal to the width and height (as specified by the tts:extent attribute using px units) of the region in which the div element is presented;
the div element SHOULD contain a metadata element containing an ittm:altText element that is a text alternative of the image referenced by the smpte:backgroundImage attribute; and
The smpte:backgroundImage attribute SHALL reference a PNG datastream as specified in [PNG]. If a pHYs chunk is present, it SHALL indicate square pixels. Note: If no pixel aspect ratio is carried, the default of square pixels is assumed.
Note
In [TTML1], tts:extent and tts:origin do not apply to div elements. In order to individually position multiple div elements, each div can be associated with a distinct region with the desired tts:extent and tts:origin.
8.4 Features
See 4.Conformance for a definition of "permitted" and "prohibited".
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 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 En completes before the end of intermediate synchronic document En-1.
Whenever applicable, constraints are specified relative to root container 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 Gn and Gn-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 Dn and Dn-1 store decoded images across intermediate synchronic documents, allowing images to be copied into the Presentation Buffer instead of decoded.
9.2 General
The Presentation Compositor SHALL render in Presentation Buffer Pn each successive intermediate synchronic document En using the following steps in order:
clear the pixels, except for the first intermediate synchronic document E0 for the which the pixels of P0SHALL be assumed to have been cleared;
paint, according to stacking order, all background pixels for each region;
paint all pixels for background colors associated with text or image subtitle content; and
paint the text or image subtitle content.
The Presentation Compositor SHALL start rendering En:
at the presentation time of E0 minus Initial Painting Delay (IPD), if n = 0; or
BDraw is the normalized background drawing performance factor;
DURT(En) is the duration, in seconds, for painting the text subtitle content for intermediate synchronic document En, as specified in Section 9.5Paint Text; and
DURI(En) is the duration, in seconds, for painting the image subtitle content for intermediate synchronic document En, as specified in Section .
The contents of the Presentation Buffer PnSHALL be transferred instantaneously to Presentation Buffer Pn-1 at the presentation time of intermediate synchronic document En, making the latter available for display.
Note
It is possible for the contents of Presentation Buffer Pn-1 to never be displayed. This can happen if Presentation Buffer Pn is copied twice to Presentation Buffer Pn-1 between two consecutive video frame boundaries of the Related Video Object.
It SHALL be an error for the Presentation Compositor to fail to complete painting pixels for En before the presentation time of En.
Unless specified otherwise, the following table SHALL specify values for IPD and BDraw.
BDraw effectively sets a limit on fillings regions - for example, assuming that the root container is ultimately rendered at 1920×1080 resolution, a BDraw of 12 s-1 would correspond to a fill rate of 1920×1080×12/s=23.7×220pixels s-1.
NSIZE(Ri) = (width of Ri ∙ height of Ri ) ÷ (root container height ∙ root container width)
NBG(Ri) SHALL be the total number of tts:backgroundColor attributes associated with the given region Ri in the intermediate synchronic document. A tts:backgroundColor attribute is associated with a region when it is explicitly specified (either as an attribute in the element, or by reference to a declared style) in the following circumstances:
it is specified on the region layout element that defines the region; or
it is specified on a div, p, span or br content element that is to be flowed into the region for presentation in the intermediate synchronic document (see [TTML1] for more details on when a content element is followed into a region); or
it is specified on a set animation element that is to be applied to content elements that are to be flowed into the region for presentation in the intermediate synchronic document (see [TTML1] for more details on when a set animation element is applied to content elements).
Even if a specified tts:backgroundColor is the same as specified on the nearest ancestor content element or animation element, specifying any tts:backgroundColorSHALL require an additional fill operation for all region pixels.
9.4 Paint Images
The Presentation Compositor SHALL paint into the Presentation Buffer Pn all visible pixels of presented images of intermediate synchronic document En.
For each presented image, the Presentation Compositor SHALL either:
if an identical image is present in Decoded Image Buffer Dn, copy the image from Decoded Image Buffer Dn to the Presentation Buffer Pn using the Image Copier; or
if an identical image is present in Decoded Image Buffer Dn-1, i.e. an identical image was present in intermediate synchronic document En-1, copy using the Image Copier the image from Decoded Image Buffer Dn-1 to both the Decoded Image Buffer Dn and the Presentation Buffer Pn; or
otherwise, decode the image using the Image Decoder the image into the Presentation Buffer Pn and Decoded Image Buffer Dn.
Two images SHALL be identical if and only if they reference the same encoded image source.
The duration DURI(En) for painting images of an intermediate synchronic document En in the Presentation Buffer SHALL be as follows:
DURI(En) = ∑Ii ∈ Ic NRGA(Ii) / ICpy + ∑Ij ∈ Id NSIZ(Ij) / IDec
ICpy is the normalized image copy performance factor.
NRGA(Ii) is the Normalized Image Area of presented image Ii and SHALL be equal to:
NRGA(Ii)= (width of Ii ∙ height of Ii ) ÷ ( root container height ∙ root container width )
NSIZ(Ii) SHALL be the number of pixels of presented image Ii.
The contents of the Decoded Image Buffer DnSHALL be transferred instantaneously to Decoded Image Buffer Dn-1 at the presentation time of intermediate synchronic document En.
The total size occupied by images stored in Decoded Image Buffers Dn or Dn-1SHALL be the sum of their Normalized Image Area.
The size of Decoded Image Buffers Dn or Dn-1SHALL be the Normalized Decoded Image Buffer Size (NDIBS).
Unless specified otherwise, the following table SHALL specify ICpy, IDec, and NDBIS.
Parameter
Initial value
Normalized image copy performance factor (ICpy)
6
Image Decoding rate (IDec)
1 × 220 pixels s-1
Normalized Decoded Image Buffer Size (NDIBS)
0.9885
9.5 Paint Text
In the context of this section, a glyph is a tuple consisting of (i) one character and (ii) the computed values of the following style properties:
tts:color
tts:fontFamily
tts:fontSize
tts:fontStyle
tts:fontWeight
tts:textDecoration
tts:textOutline
Note
While one-to-one mapping between characters and typographical glyphs is generally the rule in some scripts, e.g. latin script, it is the exception in others. For instance, in arabic script, a character can yield multiple glyphs depending on its position in a word. The Hypothetical Render Model always assumes a one-to-one mapping, but reduces the performance of the glyph buffer for scripts where one-to-one mapping is not the general rule (see GCpy below).
if an identical glyph is present in Glyph Buffer Gn, copy the glyph from Glyph Buffer Gn to the Presentation Buffer Pn using the Glyph Copier; or
if an identical glyph is present in Glyph Buffer Gn-1, i.e. an identical glyph was present in intermediate synchronic document En-1, copy using the Glyph Copier the glyph from Glyph Buffer Gn-1 to both the Glyph Buffer Gn and the Presentation Buffer Pn; or
otherwise render using the Glyph Renderer the glyph into the Presentation Buffer Pn and Glyph Buffer Gn.
Fig. 2 Example of Presentation Compositor Behavior for Text Rendering
The duration DURT(En) for rendering the text of an intermediate synchronic document En in the Presentation Buffer is as follows:
Ren(gi) is the text rendering performance factor for glyph gi; and
GCpy is the normalized glyph copy performance factor.
The Normalized Rendered Glyph Area NRGA(gi) of a glyph giSHALL be equal to:
NRGA(gi) = (fontSize of gi as percentage of root container height)2
Note
NRGA(Gi) 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 GnSHALL be copied instantaneously to Glyph Buffer Gn-1 at the presentation time of intermediate synchronic document En.
It SHALL be an error for the sum of NRGA(gi) over all glyphs Glyph Buffer Gn to be larger than the Normalized Glyph Buffer Size (NGBS).
Unless specified otherwise, the following table specifies values of GCpy, Ren and NGBS.
Normalized glyph copy performance factor (GCpy)
Script property (see Standard Annex #24 at [UNICODE]) for the character of gi
GCpy
latin, greek, cyrillic, hebrew or common
12
any other value
3
Text rendering performance factor Ren(Gi)
Block property (see [UNICODE]) for the character of gi
Ren(Gi)
CJK Unified Ideograph
0.6
any other value
1.2
Normalized Glyph Buffer Size (NGBS)
1
Note
The choice of font by the presentation processor can increase rendering complexity. For instance, a cursive font can generally result in a given character yielding different typographical glyphs depending on context, even if latin script is used.
When authoring textual content, authors are encouraged to select from sets of characters based on the language indicated using xml:lang. The idea is to increase the confidence that the text will be presented correctly by implementations targeting specific locales.
Specifically, for a given language, an author SHOULD choose characters from the set resulting from the union of the following sets:
the main exemplar character set specified for the language in [CLDR] as well as any corresponding uppercase characters as specified in [UNICODE]; and
the punctuation exemplar character set specified for the language in [CLDR];
the digits and symbols included in all numberSystems specified for the language in [CLDR];
the common character set specified in Table 1; and
supplementary characters specified for the language in Table 2, if any.
Some of these sets overlap.
Table 1 captures the set of characters intended to be available to authors across all languages. The terms used in the table are defined in [UNICODE].
Table 1. Common Character Set.
(Basic Latin)
U+0020 - U+007E
(Latin-1 Supplement)
U+00A0 - U+00FF
(Latin Extended-A)
U+0152 : LATIN CAPITAL LIGATURE OE
U+0153 : LATIN SMALL LIGATURE OE
U+0160 : LATIN CAPITAL LETTER S WITH CARON
U+0161 : LATIN SMALL LETTER S WITH CARON
U+0178 : LATIN CAPITAL LETTER Y WITH DIAERESIS
U+017D : LATIN CAPITAL LETTER Z WITH CARON
U+017E : LATIN SMALL LETTER Z WITH CARON
(Latin Extended-B)
U+0192 : LATIN SMALL LETTER F WITH HOOK
(Spacing Modifier Letters)
U+02DC : SMALL TILDE
(Combining Diacritical Marks)
U+0301 : COMBINING ACUTE ACCENT
(General Punctuation)
U+2010 - U+2015 : Dashes
U+2016 - U+2027 : General punctuation
U+2030 - U+203A : General punctuation
(Currency symbols)
U+20AC : EURO SIGN
(Letterlike Symbols)
U+2103 : DEGREES CELSIUS
U+2109 : DEGREES FAHRENHEIT
U+2120 : SERVICE MARK SIGN
U+2122 : TRADE MARK SIGN
(Number Forms)
U+2153 - U+215F : Fractions
(Mathematical Operators)
U+2212 : MINUS SIGN
U+221E : INFINITY
(Box Drawing)
U+2500 : BOX DRAWINGS LIGHT HORIZONTAL
U+2502 : BOX DRAWINGS LIGHT VERTICAL
U+250C : BOX DRAWINGS LIGHT DOWN AND RIGHT
U+2510 : BOX DRAWINGS LIGHT DOWN AND LEFT
U+2514 : BOX DRAWINGS LIGHT UP AND RIGHT
U+2518 : BOX DRAWINGS LIGHT UP AND LEFT
(Block Elements)
U+2588 : FULL BLOCK
(Geometric Shapes)
U+25A1 : WHITE SQUARE
(Musical Symbols)
U+2669 : QUARTER NOTE
U+266A : EIGHTH NOTE
U+266B : BEAMED EIGHTH NOTES
Table 2 specifies supplementary character set that have proven useful in captioning and subtitling applications for a number of selected languages. Table 2 is non-exhaustive, and will be extended as needs arise.
Fig. 3 Illustration of the use of itts:forcedDisplay below illustrates the use of forced content, i.e. itts:forcedDisplay and displayForcedOnlyMode. The content with itts:forcedDisplay="true" is the French translation of the "High School" sign. The content with itts:forcedDisplay="false" are French subtitles capturing a voiceover.
Fig. 3 Illustration of the use of itts:forcedDisplay
When the user selects French as the playback language but does not select French subtitles, displayForcedOnlyMode is set to "true", causing the display of the sign translation, which is useful to any French speaker, but hiding the voiceover subtitles as the voiceover is heard in French.
If the user selects French as the playback language and also selects French subtitles, e.g. if the user is hard-of-hearing, displayForcedOnlyMode is set to "false", causing the display of both the sign translation and the voiceover subtitles.
The algorithm for setting the displayForcedOnlyMode parameter and selecting the appropriate combination of subtitle and audio tracks depends on the application.
D. WCAG Considerations
In order to meet the guidelines in [WCAG20], the following considerations apply.
Guideline 1.1 of [WCAG20] recommends that an implementation provide text alternatives for all non-text content. In the context of this specification, this text alternative is intended primarily to support users of the subtitles who cannot see images. Since the images of an Image ProfileDocument Instance usually represent subtitle or caption text, the guidelines for authoring text equivalent strings given at Images of text of [HTML5] are appropriate.
Thus, for each subtitle in an Image ProfileDocument Instance, a text equivalent content in a Text ProfileDocument InstanceSHOULD be written so that it conveys all essential content and fulfills the same function as the corresponding subtitle image. In the context of subtitling and captioning, this content will be (as a minimum) the verbatim equivalent of the image without précis or summarization. However, the author MAY include extra information to the text equivalent string in cases where styling is applied to the text image with a deliberate connotation, as a functional replacement for the applied style.
For instance, in subtitling and captioning, italics can be used to indicate an off screen speaker context (for example a voice from a radio). An author can choose to include this functional information in the text equivalent; for example, by including the word "Radio: " before the image equivalent text. Note that images in an Image ProfileDocument Instance that are intended for use as captions, i.e. intended for a hard of hearing audience, might already include this functional information in the rendered text.
Guideline 1.1 of [WCAG20] also recommends that accessible text alternatives must be "programmatically determinable." This means that the text must be able to be read and used by the assistive technologies (and the accessibility features in browsers) that people with disabilities use. It also means that the user must be able to use their assistive technology to find the alternative text (that they can use) when they land on the non-text content (that they can't use).
E. Sample Document Instance (non-normative)
The following sample Document Instances conforms to the Text and Image Profiles, respectively. These samples are for illustration only, and are neither intended to capture current or future practice, nor exercise all normative prose contained in this specification.
The following sections define extension designations, expressed as relative URIs (fragment identifiers) relative to the IMSC 1.0 Extension Namespace base URI.
A presentation processor supports the #altText feature if it implements presentation semantic support for values of the ittm:altText element.
F.6 #linePadding
A transformation processor supports the #linePadding feature if it recognizes and is capable of transforming values of the ebutts:linePadding attribute specified in [EBU-TT-D].
A presentation processor supports the #linePadding feature if it implements presentation semantic support for values of the ebutts:linePadding attribute specified in [EBU-TT-D].
F.7 #multiRowAlign
A transformation processor supports the #multiRowAlign feature if it recognizes and is capable of transforming values of the ebutts:multiRowAlign attribute specified in [EBU-TT-D].
A presentation processor supports the #multiRowAlign feature if it implements presentation semantic support for values of the ebutts:multiRowAlign attribute specified in [EBU-TT-D].
G. XML Schema Definitions (non-normative)
XML Schema definitions (see [xmlschema-1]) for extension vocabulary defined by this specification are provided here for convenience.
These definitions are non-normative and are not sufficient to validate conformance of a Document Instance.
In any case where a definition specified by this appendix diverge from the prose of the specification, then the latter takes precedence.
Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Edward O'Connor; Silvia Pfeiffer. HTML5. 28 October 2014. W3C Recommendation. URL: http://www.w3.org/TR/html5/
