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

On Fri, Oct 11, 2013 at 9:31 AM, Pierre-Anthony Lemieux <pal@sandflow.com>wrote:

> Hi Glenn,
>
> Thanks for the information re: line breaking.
>
> >  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.
>
> How much variation would you expect in the metrics of the various
> Helvetica-like fonts used by OWP-based presentation processors?
>

Given the lack of definition of "Helvetica-like", I would interpret that as
meaning any font that could be used to map the proportionalSansSerif
generic font family. As such, there is extremely wide range of fonts and
metrics that apply.


>
> Thanks,
>
> -- Pierre
>
> On Thu, Oct 10, 2013 at 7:04 PM, Glenn Adams <glenn@skynav.com> wrote:
> > 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.
> >> >>
> >> >>
> >> >>
> >> >
> >
> >
>