IMSC Hypothetical Render Model W3C Recommendation 25 April 2024 More details about this document This version: https://www.w3.org/TR/2024/REC-imsc-hrm-20240425/ Latest published version: https://www.w3.org/TR/imsc-hrm/ Latest editor's draft: https://w3c.github.io/imsc-hrm/spec/imsc-hrm.html History: https://www.w3.org/standards/history/imsc-hrm/ Commit history Implementation report: https://www.w3.org/wiki/TimedText/IMSC-HRM-1ED-Implementation-Report Editor: Pierre Lemieux Feedback: GitHub w3c/imsc-hrm ( pull requests , new issue , open issues ) Errata: Errata exists . See also translations . Copyright © 2024 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply. Abstract This specification specifies a Hypothetical Render Model (HRM) that constrains the presentation complexity of documents that conform to the Text Profiles specified in any edition of Internet Media Subtitles and Captions ([ IMSC ]). The objective of the HRM is to allow subtitle and caption authors and providers to verify that the content they provide does not exceed defined complexity levels, so that playback systems can render the content synchronized with the author-specified display times. The model is not intended as a specification of the processing requirements for implementations. For instance, while the model defines glyph cache for the purpose of modelling how the number of glyph drawing operations can be reduced, it neither requires the implementation of such a cache, nor models the sub-pixel glyph positioning and anti-aliased glyph rendering that can be used to produce text output. Furthermore, the model is not intended to constrain readability complexity. Status of This Document This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/. This document was published by the Timed Text Working Group as a Recommendation using the Recommendation track . The history of substantive changes made to this document is summarized at F. Summary of substantive changes . W3C recommends the wide deployment of this specification as a standard for the Web. A W3C Recommendation is a specification that, after extensive consensus-building, is endorsed by W3C and its Members, and has commitments from Working Group members to royalty-free licensing for implementations. Future updates to this Recommendation may incorporate new features . This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy . This document is governed by the 03 November 2023 W3C Process Document . Table of Contents Abstract Status of This Document 1. Scope 2. Documentation Conventions 3. Terms and Definitions 4. Conformance 5. Introduction 5.1 Objective 5.2 Why limit the complexity of IMSC Document Instances ? 5.3 Why is the HRM needed to limit complexity? 5.4 How does the HRM measure and limit complexity? 5.5 Where is the HRM used? 6. Architecture 7. Algorithm 8. Paint Regions 9. Paint Text A. Index A.1 Terms defined by this specification A.2 Terms defined by reference B. Accessibility Considerations B.1 Impact of non-conformance B.2 User customisation of presentation C. Privacy and Security Considerations C.1 General C.2 Implementation considerations D. Error Reporting and Exception Handling D.1 Error Reporting D.2 Exception Handling E. Acknowledgements F. Summary of substantive changes F.1 Changes since the First Public Working Draft F.2 Changes since the first Candidate Recommendation G. References G.1 Normative references G.2 Informative references 1. Scope This specification specifies a Hypothetical Render Model (HRM) that constrains the presentation complexity of a IMSC Document Instance . 2. Documentation Conventions This specification uses the same conventions as [ IMSC ]. 3. Terms and Definitions character . The character code property of a [ TTML2 ] Character Information Item . Note The term character is for practical purposes the same as a code point , as defined by [ i18n-glossary ]. empty ISD . An Intermediate Synchronic Document with no presented region . non-empty ISD . An Intermediate Synchronic Document with at least one presented region . error . A failure to conform to the constraints defined by this specification. grapheme . As defined by [ i18n-glossary ] at grapheme . Intermediate Synchronic Document . As defined by [ TTML2 ] at Intermediate Synchronic Document . IMSC Document Instance . A [ TTML2 ] Document Instance that conforms to the Text Profile defined in any edition of [ IMSC ]. presentation processor . As defined by [ TTML2 ] at presentation processor . presented region . As defined by [ IMSC ] at presented region . Related Video Object . As defined by [ IMSC ] at Related Video Object . Root Container Region . As defined by [ TTML2 ] at Root Container Region . 4. Conformance 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 word SHALL in this document is to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here. Unless noted otherwise, this specification applies to an IMSC Document Instance . A IMSC Document Instance conforms to the Hypothetical Render Model if the sequence of Intermediate Synchronic Documents generated from it using the Intermediate Synchronic Document Construction procedure specified in [ TTML2 ] is processed without error by the HRM algorithm specified at 7. Algorithm . Note Applying the Hypothetical Render Model to a Document Instance that is not an IMSC Document Instance yields results that might not reflect the complexity of the Document Instance . Note In applications where sequences of Document Instances can be resolved into a single sequence of Intermediate Synchronic Documents that do not overlap each other temporally, conformance can be determined based on a synthesised Document Instance that generates an equivalent sequence of Intermediate Synchronic Documents , where minimal equivalence is limited to the content and metrics that are used to identify errors . 5. Introduction This section is non-normative. 5.1 Objective The objective of the HRM is to allow subtitle and caption authors and providers to verify that the content they provide does not exceed defined complexity levels, so that playback systems can render the content synchronized with the author-specified display times. Playback systems include desktop computers, mobile devices and home theatre devices. Note The HRM is not a new concept: a version of it has been included in all versions and editions of [ IMSC ]. This specification extracts the HRM into a standalone document to simplify maintenance. The First Public Working Draft of this specification essentially included the HRM as it was specified in [ ttml-imsc1.2 ]. Substantive changes made since then are summarized in F. Summary of substantive changes . 5.2 Why limit the complexity of IMSC Document Instances ? IMSC Document Instances are typically authored by a first party and rendered by a second party. Unless both parties agree on the maximum complexity of a IMSC Document Instance , it is likely that: an IMSC Document Instance authored by a first party will exceed the capabilities of the presentation processor of a second party, resulting in an incomplete presentation where some subtitles or captions might be missing or might be presented too late; a first party authors only extremely simple IMSC Document Instances in an attempt to ensure a complete presentation across all renderers, resulting in a lower quality presentation; a second party over-provisions their presentation processor in order to ensure a complete presentation of all IMSC Document Instances , resulting in increased run-time resource usage, code complexity, etc.; or one presentation processor becomes the de-facto reference to determine whether the presentation of a IMSC Document Instance will succeed, at the expense of other renderers and consistency of presentation. Figure 1 The HRM allows authors and implementers of presentation processors to agree on the maximum complexity of IMSC Document Instances . As illustrated in Figure 1 , by defining a method (the HRM) to compute a proxy for the complexity of an IMSC Document Instance and specifying a complexity limit based on such proxy: authors can ensure that their IMSC Document Instances do not exceed this limit; implementers can design their presentation processors to maximize the likelihood that they will be able to render correctly all IMSC Document Instances that do not exceed this limit; and audiences can expect subtitle and caption presentation to match the authorial intention. 5.3 Why is the HRM needed to limit complexity? The HRM supplements the syntactic and structural constraints imposed in [ IMSC ] by imposing constraints on the contents of the presentation. Because of the temporal and spatial variability of subtitles and captions across types of content, territories and languages, it is not possible to limit the complexity of an IMSC Document Instance using only average values. An average-based constraint of 840 characters per minute could be met in multiple ways, with different rendering complexities. Contrast two potential approaches: In the first, 5 characters are presented for a fraction of a second, followed by 835 characters that are then presented for over 59 seconds. This generates a high rendering complexity for the 835 characters , since there is only a brief time available to paint them. In the second, 210 characters are painted every 15 seconds, giving 15 seconds to prepare for the next presentation. This has a much lower rendering complexity. The HRM achieves a more accurate representation of the complexity of an IMSC Document Instance at any given time by taking into account its past complexity in addition to its instantaneous complexity. The same approach is commonly used in video to limit bitstream complexity, e.g., the Hypothetical Reference Decoder (HRD) specified in [ iso14496-10 ]. 5.4 How does the HRM measure and limit complexity? The HRM defines a simple model for the rendering of subtitles and captions, and uses the time it takes to render subtitles and captions according to that model as a proxy for the complexity of the subtitles and captions. Rendering includes drawing region backgrounds, rendering text and copying text. Complexity is then limited by requiring that the time to render one subtitle or caption is shorter than the time elapsed since the previous subtitle or caption. This simple model requires only a static analysis of the IMSC Document Instance , requires no fetching of external resources and does not require the IMSC Document Instance to be actually rendered. Several simplifying assumptions are made to achieve this. For example, the model assumes that each character is drawn independently, and accounts for that assumption being, in many cases, false, by assigning different render speeds for different scripts. In general the model is not intended to capture the actual time that an implementation takes to render subtitles and captions, but rather scale with it: a document that is twice as complex according to the model would require roughly twice as many resources to actually render. 5.5 Where is the HRM used? The HRM is typically used prior to distribution of the IMSC Document Instance to the end-user, as an integral part of authoring and as a quality check before distribution. When the HRM is used, the consequences of an IMSC Document Instance exceeding the HRM limits depends on the context: an authoring system might, for example, flag the specific point in time where the HRM limits were exceeded; the ingest component of a streaming platform might outright reject the IMSC Document Instance . The HRM is not intended to be used when the IMSC Document Instance is presented to end-users since: end-users are not concerned with a technical complexity measure, just as they are not concerned with video bit-rate, but instead with whether the presentation is successful; a presentation processor cannot generally reduce the complexity of a IMSC Document Instance without impacting the presentation. 6. Architecture This section is non-normative. Figure 2 Hypothetical Render Model The HRM, illustrated in Figure 2 , operates on a sequence of Intermediate Synchronic Documents E i : non-empty ISDs are processed using a simple double buffering model: while a non-empty ISD E n is being painted into a Back Buffer by the Presentation Compositor , the previous non-empty ISD E m is available for display in a Front Buffer; and empty ISDs merely disconnect the Front Buffer from the display when presented, i.e., presenting an empty ISD is equivalent to presenting nothing. The model specifies a (hypothetical) time required for completely painting a non-empty ISD as a proxy for complexity. Painting includes clearing the Back Buffer, drawing region backgrounds, rendering glyphs, and copying glyphs. Complexity is then limited by requiring that painting of non-empty ISD E n begins no earlier than the presentation time of the previous non-empty non-empty ISD E m and completes by the presentation time of E n . In contrast, there is no complexity involved connecting and disconnecting the Front Buffer from the display, and thus no complexity associated with empty ISDs . Whenever applicable, constraints are specified relative to Root Container Region dimensions, allowing subtitle sequences to be authored independently of the 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 ]), a Glyph Cache stores rendered glyphs across Intermediate Synchronic Documents , allowing glyphs to be copied into the Presentation Buffer instead of rendered, a more costly operation. Note The HRM permits a maximum rate of 12 Intermediate Synchronic Documents per second. This is ultimately limited by the BDraw parameter and is intended to capture processing and presentation overhead. When converting a [ CEA-608 ] signal to IMSC, it is therefore impossible to create IMSC Document Instances that generate an Intermediate Synchronic Document for every [ CEA-608 ] packet, which are sampled at the video field rate. It is instead preferable to coalesce sequences of [ CEA-608 ] packets into longer groupings, such as words, phrases, complete lines or paragraphs before creating an IMSC Document Instance , and let the presentation processor perform any desired animation, e.g., typewriter effect. Each of the terms Presentation Compositor , Glyph Renderer and Glyph Copier is defined by the algorithmic requirements defined for it in this specification. 7. Algorithm The HRM algorithm processes a sequence of Intermediate Synchronic Documents E i . Each successive non-empty ISD E n is rendered by the Presentation Compositor using the following steps in order: clear the pixels of the entire Root Container Region ; paint, according to stacking order, all background pixels for each region; paint all pixels for background colors associated with the text subtitle content; and paint the text subtitle content. The Presentation Compositor begins rendering E n : at the presentation time of E m , where m is the largest non-zero value that is both less than n and is such that E m is not an empty ISD , if the presentation time of E n minus that of E m is less than IPD ; or at the presentation time of E n minus IPD , otherwise. Note The Presentation Compositor never begins rendering an ISD more than IPD ahead of its presentation time. Figure 3 illustrates the rendering and presentation of Intermediate Synchronic Documents , where the hatched areas indicate time spent drawing the associated Intermediate Synchronic Document . For example, the Presentation Compositor begins rendering E 1 at the presentation time of E 0 since E 1 is not an empty ISD . In contrast, the Presentation Compositor begins rendering E 5 at the presentation time of E 5 minus IPD since (i) both E 3 and E 4 are empty ISDs and the presentation time of E 5 minus that of E 2 is greater than IPD. Furthermore, E 2 remains in the Front Buffer until the presentation time of E 5 but is not presented while E 3 and E 4 are presented, during which time the Front Buffer is not available for display. Finally, the Presentation Compositor begins rendering E 0 at the presentation time of E 0 minus IPD since E 0 is the first Intermediate Synchronic Document . The duration DUR(E n ) for painting an Intermediate Synchronic Document E n in the Back Buffer is given by: DUR(E n ) = S (E n ) / BDraw + DUR T (E n ) where S (E n ) is the total normalized drawing area for Intermediate Synchronic Document E n , as specified in 8. Paint Regions ; BDraw is the normalized background drawing performance factor; and 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 9. Paint Text . The contents of the Back Buffer are transferred instantaneously to the Front Buffer at the presentation time of a non-empty ISD E n , making the latter available for display. The Front Buffer is: disconnected from the display while an empty ISD is being presented; and connected to the display, otherwise. Note It is possible for the contents of the Front Buffer to never be displayed. This can happen, for example, if the Back Buffer is copied twice to Front Buffer 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 non-empty ISD E n before its presentation time. The following table specifies the values of IPD and BDraw . Parameter Initial value Initial Painting Delay (IPD) 1 s Normalized background drawing performance factor (BDraw) 12 s -1 Note BDraw effectively sets a limit on fillings regions - for example, assuming that the Root Container 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 20 pixels s -1 . Note IPD effectively sets a limit on the complexity of any given Intermediate Synchronic Document . 8. Paint Regions The total normalized drawing area S (E n ) for Intermediate Synchronic Document E n is given by: S(E n ) = CLEAR (E n ) + PAINT (E n ) where CLEAR (E n ) = 1. Note To ensure consistency of the Back Buffer, a new Intermediate Synchronic Document requires clearing of the Root Container Region . PAINT (E n ) is the normalized area to be painted for all regions that are used in Intermediate Synchronic Document E n according to: PAINT(E n ) = ∑ R i ∈R p NSIZE (R i ) ∙ NBG (R i ) where R p is the set of presented regions in the Intermediate Synchronic Document E n . NSIZE (R i ) is given by: NSIZE(R i ) = (width of R i ∙ height of R i ) ÷ ( Root Container Region height ∙ Root Container Region width) Example 1 For a region R i in with tts:extent="250px 50px" within a Root Container Region with tts:extent="1920px 1080px" , NSIZE (R i ) ≈ 0.00603. NBG (R i ) is the total number of elements within the tree rooted at region R i that satisfy the following criteria: the element is either a region , body , div , p or span ; and the opacity of the computed value of tts:backgroundColor is not 0 . Note An element and its parent that satisfy the criteria above and share identical computed values of tts:backgroundColor are counted as two distinct elements for the purpose of computing NBG (R i ). Note The set element is not included in the computation of NBG (R i ). While it can affect the computed values of tts:backgroundColor , it is removed during Intermediate Synchronic Document construction. 9. 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 tts:textShadow Note In the case where a property is prohibited in a profile of [ IMSC ], the computed value of the property specified in [ ttml2 ] can be used. Note The Hypothetical Render Model defines a one-to-one mapping between characters and glyphs (using the definition of glyph from this document). While a one-to-one mapping between code points and glyphs (using the definition of glyph from [ i18n-glossary ]) is common in some scripts (such as the Latin script), the actual relationship is more complex. Some scripts, such as Arabic, use different glyphs for a given character, depending on its position in a word. Some scripts require combining marks or use a sequence of code points to form a glyph. Cases exist where a given sequence of code points can have different glyph representations depending on context. This complexity is accounted for by reducing the performance of the Glyph Cache for scripts where a one-to-one mapping is not the general rule (see GCpy below). Iterating through each character in the character content of each presented region of Intermediate Synchronic Document E n , for the glyph associated with that character , the Presentation Compositor : if an identical glyph is present in the Glyph Cache, copies the glyph from Glyph Cache to the Back Buffer using the Glyph Copier and flag the glyph as retain ; or otherwise renders (using the Glyph Renderer) the glyph into the Back Buffer and Glyph Cache, and flags the glyph as retain . Figure 4 Example of Presentation Compositor Behavior for Text Rendering The duration DUR T (E n ) for rendering the text of an Intermediate Synchronic Document E n in the Back Buffer is as follows: DUR T (E n ) = ∑ g i ∈ Γ r NRGA(g i ) / Ren (g i ) + ∑ g j ∈ Γ c NRGA(g j ) / GCpy where Γ r is the set of glyphs rendered into the Back Buffer using the Glyph Renderer in Intermediate Synchronic Document E n ; Γ c is the set of glyphs copied to the Back Buffer 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 Rendered Glyph Area NRGA(g i ) of a glyph g i is given by: NRGA(g i ) = (fontSize of g i as a decimal fraction of Root Container Region height) 2 Note 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 cache size needs based on worst-case glyph size complexity. At the presentation time of Intermediate Synchronic Document E n , perform the following steps in order: purge from the Glyph Cache all glyphs not flagged retain ; and remove the retain flag from all remaining glyphs in the Glyph Cache. It SHALL be an error if the sum of NRGA(g i ) over all glyphs flagged retain in the Glyph Cache is at any time larger than the Normalized Glyph Cache Size ( NGBS ). Note The abbreviation NGBS reflects the name of the Glyph Cache from earlier editions of the specification. Unless specified otherwise, the following table specifies values of GCpy , Ren and NGBS . Normalized glyph copy performance factor (GCpy) Script property, as defined at [ UAX24 ], for the character of g i GCpy Latin , Greek , Cyrillic , Hebrew or Common 12 any other value 3 Text rendering performance factor Ren(G i ) Script property, as defined at [ UAX24 ], for the character of g i Ren(G i ) Han , Katakana , Hiragana , Bopomofo or Hangul 0.6 any other value 1.2 Normalized Glyph Cache Size (NGBS) 1 Note While DUR T (E n ) is not affected, the choice of font by the presentation processor can increase actual rendering complexity at time of presentation. For instance, a cursive font might select different glyphs for a given grapheme (in order to maintain joining or for the start/end of the word) even in the Latin script. Conversely the rendering of scripts that fall in the any other value category can in practice achieve performance comparable to, say, the Latin script. Example 2 Setting a Normalized Glyph Buffer Size effectively sets a limit on the total number of distinct glyphs present in any given Intermediate Synchronic Document E n . For example, assuming a maximum Normalized Glyph Buffer Size of 1 and the default tts:fontSize of 1c are used, the font size relative to the Root Container Region height is 1/15 , and the maximum number of distinct glyphs that can be cached is 1÷(1÷15) 2 =225 glyphs. Example 3 GCpy effectively sets a limit on animating text. For example, assuming that the Root Container Region is ultimately rendered at 1920×1080 resolution and no regions need to have background color painted (so only a CLEAR (E n ) operation is required for the normalized drawing area for the Intermediate Synchronic Document ), a GCpy and BDraw of 12 s -1 would mean that a group of 160 glyphs with a tts:fontSize equal to 5% of the Root Container Region height could be moved at most approximately 12 s -1 ÷ (1 + ( 160 × 0.05 2 )) = 8.6 times per second. Example 4 Ren (G i ) effectively sets a limit on the text rendering rate. For example, assuming that the Root Container Region is ultimately rendered at a 1920×1080 resolution, a Ren (G i ) of 1.2 s -1 would mean that at most 120 glyphs with a fontSize of 108 px (10% of 1080 px and NRGA(g i ) = 0.01) could be rendered every second. A. Index A.1 Terms defined by this specification character §3. CLEAR §8. code point §3. DURT §9. empty ISD §3. error §3. glyph §9. grapheme §3. IMSC Document Instance §3. Initial Painting Delay §7. Intermediate Synchronic Document §3. NBG §8. non-empty ISD §3. Normalized background drawing performance factor §7. Normalized Glyph Cache Size (NGBS) §9. Normalized glyph copy performance factor (GCpy) §9. NRGA(gi) §9. NSIZE §8. PAINT §8. Presentation Compositor §6. presentation processor §3. presented region §3. Related Video Object §3. Root Container Region §3. S §8. Text rendering performance factor Ren(Gi) §9. A.2 Terms defined by reference [ I18N-GLOSSARY ] defines the following: grapheme [ IMSC ] defines the following: presented region Related Video Object [ TTML2 ] defines the following: Character Information Item Document Instance Intermediate Synchronic Document presentation processor Root Container Region B. Accessibility Considerations This section is non-normative. B.1 Impact of non-conformance In a system where IMSC Document Instances are expected to conform to the Hypothetical Render Model, an IMSC Document Instance that does not conform to the Hypothetical Render Model might negatively impact accessibility during presentation of the IMSC Document Instance and its associated content. B.2 User customisation of presentation This specification does not attempt to model any additional complexity for presentation processors that might arise due to the user customisation of presentation, for example as described by [ media-accessibility-reqs ]; such user customisation is not defined by [ IMSC ]. Implementers of presentation processors that support user customisation of presentation should ensure that those processors are able to present IMSC Document Instances that conform to the Hypothetical Render Model, even if the customisation effectively increases the complexity of presentation. C. Privacy and Security Considerations This section is non-normative. C.1 General This specification has no inherent security or privacy implications. The algorithm defined within this specification is used for static analysis of a resource. This specification does not define any protocol or interface for obtaining such a resource, and it does not define any interface for exposing the results of the analysis. No personal or sensitive information is processed as part of the algorithm, other than any such information that might happen to be part of the IMSC Document Instance being analysed. No information is exposed by the algorithm to any origin. No scripts are loaded or processed as part of the algorithm and no links to external resources are dereferenced. C.2 Implementation considerations Implementers of this specification should capture and meet privacy and security requirements for their intended application. For example, an implementation could, when reporting on an error encountered during processing of an IMSC Document Instance , include a section of the content of an IMSC Document Instance to elaborate the error. If that content could include sensitive or personal information, the implementation should ensure that any such output is provided using appropriately secure protocols. No such reporting is defined or required by this specification. D. Error Reporting and Exception Handling This section is non-normative. D.1 Error Reporting This specification does not define how, or even if, errors should be reported. For example, an implementation could stop on the first error encountered, or continue to process the IMSC Document Instance and report every error. Or an implementation could exit with an appropriate status code without reporting any details at all. D.2 Exception Handling This specification does not define any runtime exceptions, or how such exceptions should be handled. E. Acknowledgements This section is non-normative. The editor acknowledges the current and former members of the Timed Text Working Group, the members of other W3C Working Groups, and industry experts in other forums who have contributed directly or indirectly to the process or content of this document. The editor wishes to especially acknowledge the following contributions by members: Nigel Megitt (British Broadcasting Corporation) and Atsushi Shimono ( W3C ). The editor also wishes to acknowledge Cyril Concolato (Netflix), Michael Dolan (Invited Expert) and Paul Londino (Warner Bros. Discovery) for contributing content producing implementations to the implementation report. F. Summary of substantive changes This section is non-normative. F.1 Changes since the First Public Working Draft Reduced complexity of empty ISD to zero In order to allow short (less than 100 ms) gaps between subtitles, which is common practice, the complexity of presenting empty ISDs has been reduced to zero: instead of being drawn into the Back Buffer, an empty ISD merely disconnects the Front Buffer from the display while it is presented. Details at: https://github.com/w3c/imsc-hrm/issues/49 Applied complexity of clearing the Back Buffer to all non-empty ISDs The first Intermediate Synchronic Document is no longer treated differently and incurs a cost for clearing the Back Buffer. Details at: https://github.com/w3c/imsc-hrm/issues/49 Clarified the mapping between Text rendering performance factor values and script values Details at: https://github.com/w3c/imsc-hrm/issues/38 Fixed an incorrect script value in the specification of GCpy Details at: https://github.com/w3c/imsc-hrm/issues/39 F.2 Changes since the first Candidate Recommendation Removed support for Image Profile Support for IMSC Image Profile, which was an at-risk feature, was removed due to insufficient demonstrable implementation experience. Details at: https://github.com/w3c/imsc-hrm/issues/63 G. References G.1 Normative references [i18n-glossary] Internationalization Glossary . Richard Ishida; Addison Phillips. W3C. 21 March 2024. W3C Working Group Note. URL: https://www.w3.org/TR/i18n-glossary/ [IMSC] TTML Profiles for Internet Media Subtitles and Captions . World Wide Web Consortium (W3C). URL: https://www.w3.org/TR/ttml-imsc/ [RFC2119] Key words for use in RFCs to Indicate Requirement Levels . S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119 [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words . B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174 [TTML2] Timed Text Markup Language 2 (TTML2) (2nd Edition) . Glenn Adams; Cyril Concolato. W3C. 9 March 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/ttml2/ [UAX24] Unicode Script Property . Ken Whistler. Unicode Consortium. 14 August 2023. Unicode Standard Annex #24. URL: https://www.unicode.org/reports/tr24/tr24-36.html G.2 Informative references [CEA-608] CTA 608-E, Line-21 Data Services . Consumer Technology Association. URL: https://www.techstreet.com/standards/cta-608-e-r2014?product_id=1815447 [CEA-708] CTA 708-D, Digital Television (DTV) Closed Captioning . Consumer Technology Association. URL: https://www.techstreet.com/standards/cta-708-d?product_id=1815448 [iso14496-10] Information technology — Coding of audio-visual objects — Part 10: Advanced video coding . ISO/IEC. Under development. URL: https://www.iso.org/standard/87574.html [media-accessibility-reqs] Media Accessibility User Requirements . Shane McCarron; Michael Cooper; Mark Sadecki. W3C. 3 December 2015. W3C Working Group Note. URL: https://www.w3.org/TR/2015/NOTE-media-accessibility-reqs-20151203/ [ttml-imsc1.2] TTML Profiles for Internet Media Subtitles and Captions 1.2 . Pierre-Anthony Lemieux. W3C. 4 August 2020. W3C Recommendation. URL: https://www.w3.org/TR/ttml-imsc1.2/ ↑ Permalink Referenced in: § 3. Terms and Definitions § 5.3 Why is the HRM needed to limit complexity? (2) (3) (4) (5) § 5.4 How does the HRM measure and limit complexity? § 9. Paint Text (2) (3) (4) (5) (6) Permalink Referenced in: § 9. Paint Text Permalink Referenced in: § 6. Architecture (2) (3) § 7. Algorithm (2) (3) (4) § F.1 Changes since the First Public Working Draft (2) Permalink Referenced in: § 6. Architecture (2) (3) (4) (5) (6) § 7. Algorithm (2) (3) Permalink Referenced in: § 4. Conformance (2) § 7. Algorithm § 9. Paint Text § C.2 Implementation considerations § D.1 Error Reporting Permalink Referenced in: § 9. Paint Text Permalink Referenced in: § 3. Terms and Definitions (2) § 4. Conformance (2) (3) § 6. Architecture (2) (3) (4) (5) § 7. Algorithm (2) (3) (4) (5) (6) (7) (8) § 8. Paint Regions (2) (3) (4) (5) § 9. Paint Text (2) (3) (4) (5) (6) (7) § F.1 Changes since the First Public Working Draft Permalink Referenced in: § 1. Scope § 4. Conformance (2) (3) § 5.2 Why limit the complexity of IMSC Document Instances? (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) § 5.3 Why is the HRM needed to limit complexity? (2) § 5.4 How does the HRM measure and limit complexity? (2) § 5.5 Where is the HRM used? (2) (3) (4) (5) § 6. Architecture (2) § B.1 Impact of non-conformance (2) (3) § B.2 User customisation of presentation § C.1 General § C.2 Implementation considerations (2) § D.1 Error Reporting Permalink Referenced in: § 5.2 Why limit the complexity of IMSC Document Instances? (2) (3) (4) (5) § 5.5 Where is the HRM used? § 6. Architecture § 9. Paint Text § B.2 User customisation of presentation (2) Permalink Referenced in: § 3. Terms and Definitions (2) § 8. Paint Regions § 9. Paint Text Permalink Referenced in: § 6. Architecture § 7. Algorithm Permalink Referenced in: § 6. Architecture § 7. Algorithm (2) § 8. Paint Regions (2) (3) (4) § 9. Paint Text (2) (3) (4) (5) Permalink Referenced in: § 6. Architecture § 7. Algorithm (2) (3) (4) (5) (6) (7) § 9. Paint Text (2) Permalink Referenced in: § 7. Algorithm (2) (3) (4) (5) Permalink Referenced in: § 6. Architecture § 7. Algorithm (2) (3) (4) (5) § 9. Paint Text Permalink Referenced in: § 7. Algorithm (2) Permalink Referenced in: § 8. Paint Regions § 9. Paint Text Permalink Referenced in: § 8. Paint Regions Permalink Referenced in: § 8. Paint Regions (2) Permalink Referenced in: § 8. Paint Regions (2) (3) Permalink Referenced in: § 9. Paint Text (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) Permalink Referenced in: § 7. Algorithm (2) § 9. Paint Text Permalink Referenced in: § 9. Paint Text (2) (3) (4) (5) Permalink Referenced in: § 9. Paint Text (2) (3) (4) (5) (6) § F.1 Changes since the First Public Working Draft Permalink Referenced in: § 9. Paint Text (2) (3) (4) (5) Permalink Referenced in: § 9. Paint Text (2) Permalink Referenced in: § 3. Terms and Definitions Permalink Referenced in: § 3. Terms and Definitions Permalink Referenced in: § 3. Terms and Definitions Permalink Referenced in: § 3. Terms and Definitions Permalink Referenced in: § 3. Terms and Definitions § 4. Conformance (2) (3) (4) Permalink Referenced in: § 3. Terms and Definitions Permalink Referenced in: § 3. Terms and Definitions Permalink Referenced in: § 3. Terms and Definitions