Re: ISSUE-283 (Deterministic Presentation): Deterministic text wrapping and presentation [TTML2]

We have discussed this many times in the past, going back to 2003, and
within CSS and XSL WGs, where it is similarly a known problem.

The only way to obtain interoperable deterministic line breaks is:

OPTION 1 to manually break the line using <br/> and specify
wrapOption='noWrap'

or

OPTION 2 require every presentation processor to support at least one
concretely specified font, with effectively identical metrics on every
platform, *and* require every presentation processor to support at least
one concrete line break implementation, with a way for the author to
express that algorithm must be used;

or

OPTION 3 require support for downloadable fonts and at least one
specifiable, universally supported line break implementation;

or

OPTION 4 use only image based captions, where rendering is done once during
authoring.

Comments

OPTION 1 - May lead to region overflow (and possible clipping)
OPTION 2 - Difficult to specify concrete collection of fonts that serves
all of Unicode, or at least the subset of Unicode used in regional
caption/subtitle text.
OPTION 3 - Probably best option in theory, most likely solution would
require support for (1) OpenType fonts delivered by WOFF, (2) freetype font
rasterizer, and (3) ICU implementation of UAX14.
OPTION 4 - Makes timed "text" rather pointless, unless both image and text
formats delivered together.


On Thu, Oct 10, 2013 at 11:31 AM, Timed Text Working Group Issue Tracker <
sysbot+tracker@w3.org> wrote:

> ISSUE-283 (Deterministic Presentation): Deterministic text wrapping and
> presentation [TTML2]
>
> http://www.w3.org/AudioVideo/TT/tracker/issues/283
>
> Raised by: Nigel Megitt
> On product: TTML2
>
> There's a complex interaction between lineHeight, fontSize, overflow and
> wrapOption that determines, for the font that the display processor
> chooses, how much text will fit on a line and whether any text that doesn't
> fit overflows or is truncated. This creates a problem for document authors
> if they can not be certain of the metrics of the font used to present their
> content.
>
> The goal from an audience perspective is that the on-screen text is
> readable and complete. Nobody wants missing words (that could change the
> editorial meaning) or text that is visible but unreadable.
>
> TTML offers little by way of solution to this real world problem at the
> moment. The IMSC submission presents a 'reference font' mechanism, which
> should be considered. Is there anything more that we can do natively in
> TTML to allow deterministic rendering to be defined at the point of
> authoring?
>
> Raising this issue for discussion at TPAC.
>
> Note that there are related issues (to be filed separately) around
> lineHeight=normal being related to the height of the text actually flowed
> onto a line (is it? or is it related to the descendent elements of the
> <p>?) and being set to a percentage of the font size - should it be 100%,
> 120%, 125% etc. for compatibility with CSS etc.
>
>
>
>