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

It is a weak version of OPTION 2, without a standard line breaking
algorithm. Further, there is no way in an XSL-FO or CSS mapping to say the
rendering engine that font Y should be used with the metrics of font X. So
I suspect that any OWP based presentation processor would simply ignore
that requirement.


On Thu, Oct 10, 2013 at 7:48 PM, Pierre-Anthony Lemieux <pal@sandflow.com>wrote:

> Hi Glenn et al.,
>
> > 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.
>
> The IMSC draft uses ubiquitous fonts (Courier and Helvetica) to define
> specify reference font metrics for selected font families
> (monospaceSerif and proportionalSansSerif, respectively). Presentation
> processors are not required to render using the reference font (and
> can use a font of a different shape in fact), but must render using
> the font metrics of the reference font.
>
> Is that OPTION 2, or a new OPTION 5?
>
> Best,
>
> -- Pierre
>
> On Thu, Oct 10, 2013 at 12:52 PM, Glenn Adams <glenn@skynav.com> wrote:
> > 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.
> >>
> >>
> >>
> >
>