Copyright © 2013 Motion Picture Laboratories, Inc. Derived from the Common File Format & Media Formats Specification 1.0.6 and Common File Format Timed Text XML Schemas 1.0.6 posted at http://www.uvvuwiki.com, © Digital Entertainment Content Ecosystem (DECE) LLC and used with permission.This document is available under theW3C Document License. See theW3C Intellectual Rights Notice and Legal Disclaimersfor additional information.
This submission specifies two profiles of the Timed Text Markup Language (TTML) Version 2.0: 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.
Both profiles are based on theCommon File Format & Media Formats Specification (CFF) developed byDigital Entertainment Content Ecosystem (DECE), and benefit from the technical consensus, conformance testing and implementation experience gathered there. The text profile is intended as a superset ofSDP-US, which is a subset of CFF. The image profile extends a subset of TTML withSMPTE Timed Text (SMPTE-TT) image support.
DECE is an industry forum with more than 80 members across the content and consumer electronics communities.
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 can be found in theW3C technical reports index at http://www.w3.org/TR/.
By publishing this document, W3C acknowledges that theSubmitting Members have made a formal Submission request to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to theW3C Process. AW3C Team Comment has been published in conjunction with this Member Submission. Publication of acknowledged Member Submissions at the W3C site is one of the benefits ofW3C Membership. Please consult the requirements associated with Member Submissions ofsection 3.3 of the W3C Patent Policy. Please consult the completelist of acknowledged W3C Member Submissions.
This document specifies two profiles of [TTML2]: 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.
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 keywordsMUST,MUST NOT,SHALL,SHALL NOT,REQUIRED,SHOULD,SHOULD NOT,RECOMMENDED,MAY, andOPTIONAL in this specification are to be interpreted as described in [RFC2119].
A subtitle documentSHALL conform to a profile defined herein if it meets all normative provisions associated with the profile.
A TTML presentation processorSHALL conform to a profile if it is capable of presenting any subtitle document conforming to the profile, i.e. if it implements all features and provisions of the profile
A subtitle documentSHALL NOT conform to the Text and Image Profiles simultaneously.
A subtitle document conforming to the Text ProfileSHALL conform to Sections4.Common Constraints and5.Text Profile Constraints.
A subtitle document conforming to the Image ProfileSHALL conform to Sections4.Common Constraints and6.Image Profile Constraints.
A subtitle documentSHALL use UTF-8 character encoding as specified in [UNICODE].
A subtitle documentMAY be associated with a related video object, whichSHALL consist of a sequence of frames, each a rectangular array of pixels.
The following assumes the addition of attp:aspectRatio
attribute to [TTML2].
The root container of a subtitle documentSHALL be mapped to the related video object frame according to the following:
Ifttp:aspectRatio
is present, the root containerSHALL be mapped to a rectangular area within the related video object such that:
ttp:aspectRatio
,Otherwise, the root container of a subtitle documentSHALL be mapped to the related video object frame in its entirety. Iftts:extent
is present on thett
element, the extents of the root containerSHALL be equal to the dimensions of the related video object frame.
ttp:aspectRatio
SHALL NOT be present iftts:extent
is present.
As specified in Section4.6Features,tts:extent
is present if thepx
length measure is used anywhere within the document.
Integer pixel positions on the related video object frame computed from real percentage length valuesSHALL use half-up rounding, i.e. round(x) = floor(x+0.5).
Each intermediate synchronic document of the subtitle document is intended to be displayed on a specific frame and removed on a specific frame of the related video object.
A media time expression MSHALL correspond to the frame of the related video object with the presentation time that is the closest to, but not less, than M.
Ifttp:frameRate
is specified, then the product ofttp:frameRate
andttp:frameRateMultiplier
SHALL be the frame rate of the related video object.
All instances of thexml:lang
attribute within a subtitle documentSHALL have identical values.
xml:lang
can have a value of "".
A region, as defined in [TTML2],SHALL be considered presented in a given intermediate synchronic document if both of the following conditions are true:
tts:opacity
is not equal to "0.0" for the region; and
content is selected into the region ortts:showBackground
is equal to "always" for the region.
As specified in [TTML2], the initial value oftts:opacity
is "1.0" and the default value oftts:showBackground
is "always".
All regionsSHALL be entirely contained within the root container.
No two regions presented in a given intermediate synchronic documentSHALL overlap
The number of presented regions in a given intermediate synchronic documentSHALL be smaller than or equal to 4.
Any sequence of consecutive intermediate synchronic documentsSHALL be reproducible without error by the Hypothetical Render Model specified in Section4.5Hypothetical Render Model.
Feature | Provisions |
---|---|
#animation | MAY be used. |
#cellResolution | SHALL NOT be used. |
#clockMode | SHALL NOT be used. |
#content | MAY be used. |
#core | MAY be used. |
#display-block | MAY be used. |
#display-inline | MAY be used. |
#display-region | MAY be used. |
#display | MAY be used. |
#dropMode | SHALL NOT be used. |
#extent-region | MAY be used. Thetts:extent attributeSHALL be present on allregion elements. |
#extent-root | MAY be used. If the document includes any length value that uses thepx expression,tts:extent SHALL be present on thett element. |
#extent | MAY be used. |
#frameRate | If the document includes any time expression that uses the frame field, thettp:frameRate attributeSHALL be present on thett element. |
#frameRateMultiplier | MAY be used. |
#layout | MAY be used. |
#length-cell | SHALL NOT be used. |
#length-integer | MAY be used. |
#length-negative | SHALL NOT be used. |
#length-percentage | MAY be used. |
#length-pixel | MAY be used. |
#length-positive | MAY be used. |
#length-real | MAY be used. |
#length | MAY be used. |
#markerMode | SHALL NOT be used. |
#metadata | MAY be used. |
#opacity | MAY be used. |
#origin | MAY be used. |
#overflow | SHALL NOT be used. |
#pixelAspectRatio | SHALL NOT be used. |
#presentation | MAY be used. |
#profile | MAY be used. |
#showBackground | MAY be used. |
#structure | MAY be used. |
#styling-chained | MAY be used. |
#styling-inheritance-content | MAY be used. |
#styling-inheritance-region | MAY be used. |
#styling-inline | MAY be used. |
#styling-nested | MAY be used. |
#styling-referential | MAY be used. |
#styling | MAY be used. |
#subFrameRate | SHALL NOT be used. |
#tickRate | MAY be used.ttp:tickRate SHALL be present on thett element. |
#timeBase-clock | SHALL NOT be used. |
#timeBase-media | SHALL be used.ttp:timeBase SHALL be present on thett element andSHALL be equal to "media". |
#timeBase-smpte | SHALL NOT be used. |
#time-clock-with-frames | MAY be used. |
#time-clock | MAY be used. |
#time-offset-with-frames | MAY be used. |
#time-offset-with-ticks | MAY be used. |
#time-offset | MAY be used. |
#timeBase-media | MAY be used. |
#timeContainer | MAY be used. |
#timing | MAY be used. The same syntax of#clock-time or#offset-time SHOULD be used throughout the subtitle document. |
#transformation | MAY be used. |
#unicodeBidi | MAY be used. |
#visibility-block | MAY be used. |
#visibility-inline | MAY be used. |
#visibility-region | MAY be used. |
#visibility | MAY be used. |
#writingMode-horizontal-lr | MAY be used. |
#writingMode-horizontal-rl | MAY be used. |
#writingMode-horizontal | MAY be used. |
#writingMode | MAY be used. |
#zIndex | MAY be used. |
#aspectRatio | MAY be used. |
#forcedDisplay | MAY be used. |
SeeISSUE-230 for a description of#forcedDisplay
This initial values specified fortts:color
,tts:displayAlign
andtts:textAlign
are those specified by [ST2052-1].
As specified in [TTML2], 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
)).
A subtitle document conforming to the Text ProfileSHALL be designated by the document conformance designator specified below.
http://www.w3.org/ns/ttml/profile/imsc-text
The ttp:profile mechanism of TTML 1.0 allows a document to indicate the profile(s) that a processorSHALL support in order to process the document. This mechanism cannot be used to indicate that a processor implementing any of the referenced profiles can process the document. The document conformance concept introduced below extends the TTML 1.0 ttp:profile mechanism by allowing a document to signal that it conforms to a specified set of normative provisions.
The following assumes, but does not require, the porting of the [ST2052-1]#backgroundImage
,#backgroundImageHorizontal
,#backgroundImageVertical
and#image
features to [TTML2].
Feature | Provisions |
---|---|
#backgroundColor-block | MAY be used. |
#backgroundColor-inline | MAY be used. |
#backgroundColor-region | MAY be used. |
#backgroundColor | MAY be used. |
#backgroundImage | SHALL NOT be used. |
#backgroundImageHorizontal | SHALL NOT be used. |
#backgroundImageVertical | SHALL NOT be used. |
#bidi | MAY be used. |
#color | MAY be used. The initial value oftts:color SHALL be "white". |
#direction | MAY be used. |
#displayAlign | MAY be used. The initial value oftts:displayAlign SHALL be "after". |
#extent-region | Thetts:extent attribute when applied to a region elementSHALL usepx units or "percentage" representation, andSHALL NOT useem units. |
#fontFamily-generic | MAY be used. |
#fontFamily-non-generic | MAY be used. |
#fontFamily | MAY be used. |
#fontSize-anamorphic | SHALL NOT be used. |
#fontSize-isomorphic | MAY be used. |
#fontSize | MAY be used. |
#fontStyle-italic | MAY be used. |
#fontStyle-oblique | MAY be used. |
#fontStyle | MAY be used. |
#fontWeight-bold | MAY be used. |
#fontWeight | MAY be used. |
#image | SHALL NOT be used. |
#length-em | MAY be used. |
#lineBreak-uax14 | MAY be used. |
#lineHeight | MAY be used. |
#nested-div | MAY be used. |
#nested-span | MAY be used. |
#origin | Thetts:origin attributeSHALL usepx units or "percentage" representation, andSHALL NOT useem units. |
#padding-1 | MAY be used. |
#padding-2 | MAY be used. |
#padding-3 | MAY be used. |
#padding-4 | MAY be used. |
#padding | MAY be used. |
#textAlign-absolute | MAY be used. |
#textAlign-relative | MAY be used. |
#textAlign | MAY be used. The initial value oftts:textAlign SHALL be "center". |
#textDecoration-over | MAY be used. |
#textDecoration-through | MAY be used. |
#textDecoration-under | MAY be used. |
#textDecoration | MAY be used. |
#textOutline-blurred | SHALL NOT be used. |
#textOutline-unblurred | MAY be used. |
#textOutline | MAY be used. If specified, the border thicknessSHALL be 10% or less than the associated font size. |
#wrapOption | MAY be used. |
#writingMode-vertical | MAY be used. |
The Image ProfileSHALL be designated by the document conformance designator specified below:
http://www.w3.org/ns/ttml/profile/imsc-image
The ttp:profile mechanism of TTML 1.0 allows a document to indicate the profile(s) that a processorSHALL support in order to process the document. This mechanism cannot be used to indicate that a processor implementing any of the referenced profiles can process the document. The document conformance concept introduced below extends the TTML 1.0 ttp:profile mechanism by allowing a document to signal that it conforms to a specified set of normative provisions.
The following assumes, but does not require, the porting of the [ST2052-1]#backgroundImage
,#backgroundImageHorizontal
,#backgroundImageVertical
and#image
features to [TTML2].
Feature | Provisions |
---|---|
#backgroundImage | MAY be used. The backgroundImage attributeSHALL reference a complete image that conforms to the PNG image coding as specified in Sections 7.1.1.3 and 15.1 of [MHP]. If a pHYs chunk is present, itSHALL indicate square pixels. Note: If no pixel aspect ratio is carried, the default of square pixels will be assumed. |
#backgroundImageHorizontal | SHALL NOT be used.#backgroundImage remains available for use. |
#backgroundImageVertical | SHALL NOT be used.#backgroundImage remains available for use. |
#bidi | SHALL NOT be used. |
#color | SHALL NOT be used. |
#content | Thep ,span andbr elementsSHALL NOT be present. |
#direction | SHALL NOT be used. |
#displayAlign | SHALL NOT be used. |
#extent-region | If atts:backgroundImage attribute is applied to a region, the width and height of the region extentSHALL be present andSHALL be equal to the width and height of the image source referenced by thetts:backgroundImage . |
#fontFamily | SHALL NOT be used. |
#fontSize | SHALL NOT be used. |
#fontStyle | SHALL NOT be used. |
#fontWeight | SHALL NOT be used. |
#image | SHALL NOT be used. |
#length-em | SHALL NOT be used. |
#lineBreak-uax14 | SHALL NOT be used. |
#lineHeight | SHALL NOT be used. |
#nested-div | SHALL NOT be used. |
#nested-span | SHALL NOT be used. |
#padding | SHALL NOT be used. |
#textAlign | SHALL NOT be used. |
#textDecoration | SHALL NOT be used. |
#textOutline | SHALL NOT be used. |
#wrapOption | SHALL NOT be used. |
#writingMode-vertical | SHALL NOT be used. |
This Section specifies the Hypothetical Render Model illustrated inFig.1 Hypothetical Render Model.
The purpose of the model is to limit subtitle document complexity. It is not however intended to serve as basis for implementation. 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 does not require an implementation to implement such a buffer.
The model operates on successive intermediate synchronic documents obtained from an input subtitle document, and uses a simple double buffering model: while an intermediate synchronic document En is being painted into Presentation Buffer Pn (the "front buffer" of the model), the previous intermediate synchronic document En-1 is available for display in Presentation Buffer Pn-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 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 enables 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.
The Presentation CompositorSHALL start rendering En:
The duration DUR(En) for painting an intermediate synchronic document En in the Presentation Buffer PnSHALL be:
DUR(En) = S(En) / BDraw + DURT(En) + DURI(En)
Where:
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.
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.
ItSHALL 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 tableSHALL specify values for IPD and BDraw.
Parameter | Initial value |
---|---|
Initial Painting Delay (IPD) | 1 s |
Normalized background drawing performance factor (BDraw) | 12 s-1 |
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.
IPD effectively sets a limit on the complexity of any given intermediate synchronic document.
The total normalized drawing area S(En) for intermediate synchronic document EnSHALL be
S(En) = CLEAR(En) + PAINT(En )
where CLEAR(E0) = 0 and CLEAR(En | n > 0) = 1, i.e. the root container in its entirety.
To ensure consistency of the Presentation Buffer, a new intermediate synchronic document requires clearing of the root container.
PAINT(En)SHALL be the normalized area to be painted for all regions that are used in intermediate synchronic document En according to
PAINT(En) = ∑Ri∈Rp SIZE(Ri) ∙ NBG(Ri)
where R_pSHALL be the set of regions presented in the intermediate synchronic document En – see Section4.4.1Presented Region for the definition of presented region.
NSIZE(Ri)SHALL be given by:
NSIZE(Ri) = (width of Ri ∙ height of Ri ) ÷ (root container height ∙ root container width)
tts:extent="250px 50px"
within a root container withtts:extent="1920px 1080px"
, NSIZE(Ri) = 0.603.NBG(Ri)SHALL be the total number oftts:backgroundColor
attributes associated with the given region Ri in the intermediate synchronic document. Atts: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:
region
layout element that defines the region.div
,p
,span
orbr
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).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 aset
animation element is applied to content elements).Even if a specifiedtts:backgroundColor
is the same as specified on the nearest ancestor content element or animation element, specifying anytts:backgroundColor
SHALL require an additional fill operation for all region pixels.
The Presentation CompositorSHALL paint into the Presentation Buffer Pn all visible pixels of presented images of intermediate synchronic document En.
A presented imageSHALL be adiv
element with a smpte:backgroundImage attribute that is contained within a presented region.
For each presented image, the Presentation CompositorSHALL either:
Two imagesSHALL 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 BufferSHALL be as follows:
DURI(En) = ∑Ii ∈ Ic NRGA(Ii) / ICpy + ∑Ij ∈ Id NSIZ(Ij) / IDec
where
NRGA(Ii) is the Normalized Image Area of presented image Ii andSHALL 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 tableSHALL 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 |
For each glyph displayed in intermediate synchronic document En, the Presentation CompositorSHALL:
Two glyphs are identical if and only if the following [TTML2] styles are identical:
tts:color
tts:fontFamily
tts:fontSize
tts:fontStyle
tts:fontWeight
tts:textDecoration
tts:textOutline
The duration DURT(En) for painting the text of an intermediate synchronic document En in the Presentation Buffer is as follows:
DURT(En) = ∑Gi ∈ Gr NRGA(Gi) / Ren(Gi) + ∑Gj ∈ Gc NRGA(Gj) / GCpy
Where:
Gr and GcSHALL include only glyphs in presented regions andSHALL NOT include a [UNICODE] Code Point if it does not result in a change to presentation, e.g. the Code Point is ignored.
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
The contents of the Glyph Buffer GnSHALL be copied instantaneously to Glyph Buffer Gn-1 at the presentation time of intermediate synchronic document En.
The total size occupied by the glyphs stored in Glyph Buffers Gn or Gn-1SHALL be the sum of their Normalized Rendered Glyph Area.
The size of Glyph Buffers Gn and Gn-1SHALL be the Normalized Glyph Buffer Size (NGBS).
Unless specified otherwise, the following tableSHALL specify GCpy, Ren and NGBS, andSHALL apply to all supported font styles (including provision of outline border).
Parameter | Initial value |
---|---|
Normalized glyph copy performance factor (GCpy) | 12 |
Text rendering performance factor Ren(Gi if Gi is not a CJK Unified Ideograph as specified in [UNICODE]. | 1.2 |
Text rendering performance factor Ren(Gi) if Gi is a CJK Unified Ideograph as specified in [UNICODE]. | 0.6 |
Normalized Glyph Buffer Size (NGBS) | 1 |
NRGA(Gi) does not take into account glyph decorations (e.g. underline), glyph effects (e.g. outline) or actual glyph aspect ratio. An implementation can determine an actual buffer size needs based on worst-case glyph size complexity.
The following table lists common code points (see [UNICODE]) definitions used in this Appendix:
(Basic Latin) |
---|
U+0020 - U+007E (Letterlike Symbols) |
U+2103 : DEGREES CELSIUS |
U+2109 : DEGREES FAHRENHEIT |
U+2120 : SERVICE MARK SIGN |
U+2122 : TRADE MARK SIGN |
(Latin-1 Supplement) |
U+00A0 - U+00FF (Number Forms) |
U+2153 – U+215F : Fractions |
(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 (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 |
(Latin Extended-B) |
U+0192 : LATIN SMALL LETTER F WITH HOOK (Block Elements) |
U+2588 : FULL BLOCK |
(Spacing Modifier Letters) |
U+02DC : SMALL TILDE (Geometric Shapes) |
U+25A1 : WHITE SQUARE |
(General Punctuation) |
U+2010 - U+2015 : Dashes |
U+2016 - U+2027 : General punctuation |
U+2030 - U+203A : General punctuation (Musical Symbols) |
U+2669 : QUARTER NOTE |
U+266A : EIGHTH NOTE |
U+266B : BEAMED EIGHTH NOTES |
(Currency symbols) |
U+20AC : EURO SIGN |
The following table specifies the [UNICODE] code points thatSHOULD be used in a document's textual content ifxml:lang
is present (Primary language subtag is as defined in IETF RFC 5646).
Languages | Primary language subtag ofxml:lang | [UNICODE] Code Points |
---|---|---|
Albanian Languages | ||
Albanian | "sq" | As defined in the table above |
Baltic Languages | ||
Latvian, Lithuanian | "lv", "lt" | As defined in the table above, except for "(Latin Extended-A)" which is re-defined below (Latin Extended-A) U+0100 - U+017F |
Finnic Languages | ||
Finish | "fi" | As defined in the table above |
Estonian | "et" | As defined in the table above, except for "(Latin Extended-A)" which is re-defined below (Latin Extended-A) U+0100 - U+017F |
Germanic Languages | ||
Danish, Dutch/Flemish, English, German, Icelandic, Norwegian, Swedish | "da", "nl", "en", "de", "is", "no", "sv" | As defined in the table above. |
Greek Languages | ||
Greek | "el" | As defined in the table above (Greek and Coptic) U+0386 : GREEK CAPITAL LETTER ALPHA WITH TONOS U+0387 : GREEK ANO TELEIA U+0388 – U+03CE : Letters |
Romanic Languages | ||
Catalan, French, Italian | "ca", "fr", "it" | As defined in the table above |
Portuguese, Spanish | "pt", "es" | (Currency symbols) U+20A1 : COLON SIGN U+20A2 : CRUZEIRO SIGN U+20B3 : AUSTRAL SIGN |
Romanian | "ro" | As defined in the table above, except for "(Latin Extended-A)" which is re-defined below (Latin Extended-A) U+0100 - U+017F |
Semitic Languages | ||
Arabic | "ar" | As defined in the table above U+060C – U+060D : Punctuation U+061B : ARABIC SEMICOLON U+061E : ARABIC TRIPLE DOT PUNCTUATION MARK U+061F : ARABIC QUESTION MARK U+0621 – U+063A : Based on ISO 8859-6 U+0640 – U+064A : Based on ISO 8859-6 U+064B – U+0652 : Points from ISO 5559-6 U+0660 – U+0669 : Arabic-Indic digits U+066A – U+066D : Punctuation |
Hebrew | "he" | As defined in the table above (Hebrew) U+05B0 – U+05C3 : Points and punctuation U+05D0 – U+05EA : Based on ISO 8859-8 U+05F3 – U+05F4 : Additional punctuation |
Slavic Languages | ||
Croatian, Czech, Polish, Slovenian, Slovak | "hr", "cs", "pl", "sl", "sk" | As defined in the table above, except for "(Latin Extended-A)" which is re-defined below (Latin Extended-A) U+0100 - U+017F |
Bosnian, Bulgarian, Macedonian, Russian, Serbian, Ukrainian | "bs", "bg", "mk", "ru", "sr", "uk" | As defined in the table above, except for "(Latin Extended-A)" which is re-defined below (Latin Extended-A) U+0100 - U+017F (Cyrillic) U+0400 – U+040F : Cyrillic extensions U+0410 – U+044F : Basic Russian alphabet U+0450 – U+045F : Cyrillic extensions |
Turkic Languages | ||
Turkish | "tr" | As defined in the table above, except for "(Latin Extended-A)" which is re-defined (Latin Extended-A) U+0100 - U+017F |
Kazakh | "kk" | As defined in the table above, except for "(Latin Extended-A)" which is re-defined (Latin Extended-A) U+0100 - U+017F (Cyrillic) U+0400 – U+040F : Cyrillic extensions U+0410 – U+044F : Basic Russian alphabet U+0450 – U+045F : Cyrillic extensions |
Ugric Languages | ||
Hungarian | "hu" | As defined in the table above, except for "(Latin Extended-A)" which is re-defined below (Latin Extended-A) U+0100 - U+017F |
This section is non-normative.
The following table summarizes subtitle languages commonly used in the listed regions. The Language Tag is as specified in RFC 5646.
Region | Subtitle Languages (Language Tag) |
---|---|
ALL (worldwide) | English ("en") |
America (North) | |
ALL | French ("fr") [Québécois ("fr-CA") or Parisian ("fr-FR")] |
United States | Spanish ("es") [Latin American ("es-419")] |
America (Central and South) | |
ALL | Spanish ("es") [Latin American ("es-419")] |
Brazil | Portuguese ("pt") [Brazilian ("pt-BR")] |
Asia, Middle East, and Africa | |
China | Chinese ("zh") [Simplified Mandarin ("zh-cmn-Hans")] |
Egypt | Arabic ("ar") |
Hong Kong | Chinese ("zh") [Cantonese ("zh-yue")] |
India | Hindi ("hi") Tamil ("ta") Telugu ("te") |
Indonesia | Indonesian ("id") |
Israel | Hebrew ("he") |
Japan | Japanese ("ja") |
Kazakhstan | Kazakh ("kk") |
Malaysia | Standard Malay ("zsm") |
South Korea | Korean ("ko") |
Taiwan | Chinese ("zh") [Traditional Mandarin ("zh-cmn-Hant")] |
Thailand | Thai ("th") |
Vietnam | Vietnamese ("vi") |
Europe | |
Benelux (Belgium, Netherlands, and Luxembourg) | French ("fr") [Parisian ("fr-FR")] Dutch/Flemish ("nl") |
Denmark | Danish ("da") |
Finland | Finnish ("fi") |
France | French ("fr") [Parisian ("fr-FR")] Arabic ("ar") |
Germany | German ("de") Turkish ("tr") |
Italy | Italian ("it") |
Norway | Norwegian ("no") |
Spain | Spanish ("sp") [Castilian ("sp-ES")] Catalan ("ca") |
Sweden | Swedish ("sv") |
Switzerland | French ("fr") ["fr-CH" or "fr-FR"] German ("de") ["de-CH"] Italian ("it") ["it-CH"] |
Albania | Albanian ("sq") |
Bulgaria | Bulgarian ("bg") |
Croatia | Croatian ("hr") |
Czech Republic | Czech ("cs") |
Estonia | Estonian ("et") |
Greece | Greek ("el") |
Hungary | Hungarian ("hu") |
Iceland | Icelandic ("is") |
Latvia | Latvian ("lv") |
Lithuania | Lithuanian ("lt") |
Macedonia | Macedonian ("mk") |
Poland | Polish ("pl") |
Portugal | Portuguese ("pt") [Iberian ("pt-PT")] |
Romania | Romanian ("ro") |
Russia | Russian ("ru") |
Serbia | Serbian ("sr") |
Slovakia | Slovak ("sk") |
Slovenia | Slovenian ("sl") |
Turkey | Turkish ("tr") |
Ukraine | Ukrainian ("uk") |
TBD