diff --git a/imsc1/spec/ttml-ww-profiles.html b/imsc1/spec/ttml-ww-profiles.html index e3d8f92f..cfb1c181 100644 --- a/imsc1/spec/ttml-ww-profiles.html +++ b/imsc1/spec/ttml-ww-profiles.html @@ -2424,9 +2424,6 @@

Overflow

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

- -

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

@@ -3006,14 +3003,6 @@

Signaling conformance using EBU-TT metadata

-
-

Hypothetical Render Model

- -

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

-
-

Style Resolution

@@ -3518,7 +3507,13 @@

Slanted Japanese-language text

(b) Japanese-language slanted vertical text consists of characters slanted in the vertical direction (and not in the horizontal direction), it is recommended that tts:shear be specified to slant Japanese-language text – instead of specifying tts:fontStyle="italic" or tts:fontStyle="oblique".

-
+ + +
+

Hypothetical Render Model

+ +

Document Instance SHALL conform to the Hypothetical Render Model specified at [[!imsc-hrm]].

+
@@ -3707,485 +3702,6 @@
smpte:image
-
-

Hypothetical Render Model

- -
-

Overview

- -

This Section specifies the Hypothetical Render Model illustrated in .

- -

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

- -
- Hypothetical Render Model - -
- Hypothetical Render Model -
-
- -

The model operates on successive intermediate synchronic documents - obtained from an input Document Instance, and uses a simple double buffering model: while an intermediate - synchronic document 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 Region dimensions, allowing subtitle - sequences to be authored independently of Related Video Object resolution.

- -

To enable scenarios where the same glyphs are used in multiple successive intermediate synchronic documents, e.g. to convey a CEA-608/708-style roll-up (see - [[CEA-608]] and [[CEA-708]]), the Glyph Buffers 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.

-
- -
-

General

- -

The Presentation Compositor SHALL render in Presentation Buffer Pn each successive intermediate synchronic - document En using the following steps in order:

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

The Presentation Compositor SHALL start rendering En:

- - - -

The duration DUR(En) for painting an intermediate synchronic document En in the Presentation - Buffer Pn SHALL be:

- -

DUR(En) = S(En) / BDraw + DURT(En) + - DURI(En)

- -

where

- - - -

The contents of the Presentation Buffer Pn SHALL 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.

- -

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

- -

It SHALL be an error if the total retrieved font size exceeds 10 MiB.

- -

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

- - - - - - - - - - - - - - - - - - - - - - - -
ParameterInitial 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 - 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×220pixels s-1.

- -

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

-
- -
-

Paint Regions

- -

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

- -

S(En) = CLEAR(En) + PAINT(En )

- -

where CLEAR(E0) = 0 and CLEAR(En | n > 0) = 1, i.e. the Root Container Region in its - entirety.

- -

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

- -

PAINT(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 NSIZE(Ri) ∙ - NBG(Ri)

- -

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

- -

NSIZE(Ri) SHALL be given by:

- -

NSIZE(Ri) = (width of Ri ∙ height of Ri ) ÷ (Root Container - Region height ∙ Root Container Region 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:

- - - -

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

-
- -
-

Paint Images

- -

The Presentation Compositor SHALL paint into the Presentation Buffer Pn all visible pixels of presented images - of intermediate synchronic document En.

- -

For each presented image, the Presentation Compositor SHALL either:

- - - -

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

- -

where

- - - -

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 - Region height ∙ Root Container Region width )

- -

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

- -

The contents of the Decoded Image Buffer Dn SHALL 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-1 SHALL be the sum of - their Normalized Image Area.

- -

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

- -

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ParameterInitial 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
-
- -
-

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:

- - - -

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

- -

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

- - - -

In the case of external data resource retrieved using [[HTTP11]], the size in bytes of the external data resource - is the entity-length of the message.

- -
- Example of Presentation Compositor Behavior for Text Rendering - -
- 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:

- -

DURT(En) = ∑gi ∈ Γr NRGA(gi) - / Ren(gi) + ∑gj ∈ Γc NRGA(gj) / GCpy

- -

where

- - - -

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

- -

NRGA(gi) = (fontSize of gi as percentage of Root Container Region - height)2

- -

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 Gn SHALL 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 - giGCpy
latin, greek, cyrillic, hebrew or base12
any other value3
Text rendering performance factor Ren(Gi)
Block property (see [[!UNICODE]]) for the character of giRen(Gi)
CJK Unified Ideograph0.6
any other value1.2
Normalized Glyph Buffer Size (NGBS)
1
- -

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.

- - - - - - -
-
-

Reference Fonts

@@ -4894,7 +4410,7 @@

EBU-TT-D

exceptions, including: