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

Well, it's the only defined algorithm we have at the moment (in TTML). It's
widely implemented (via ICU). However, it doesn't deal with more complex
layout features such as ruby (furigana).


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

> Any known downside to using #lineBreak-uax14?
>
> -- Pierre
>
> On Thu, Oct 10, 2013 at 11:16 PM, Glenn Adams <glenn@skynav.com> wrote:
> > Not sure what you are asking.
> >
> >
> > On Thu, Oct 10, 2013 at 9:59 PM, Pierre-Anthony Lemieux <
> pal@sandflow.com>
> > wrote:
> >>
> >> Ok. Any known downside?
> >>
> >> On Thu, Oct 10, 2013 at 8:47 PM, Glenn Adams <glenn@skynav.com> wrote:
> >> >
> >> > On Thu, Oct 10, 2013 at 9:23 PM, Pierre-Anthony Lemieux
> >> > <pal@sandflow.com>
> >> > wrote:
> >> >>
> >> >> Hi Glenn,
> >> >>
> >> >> Thanks for the feedback.
> >> >>
> >> >> > without a standard line breaking algorithm
> >> >>
> >> >> Ah. What options exist?
> >> >
> >> >
> >> > UAX #14 [1], implemented by ICU. We actually have a feature for this
> in
> >> > TTML, #lineBreak-uax14
> >> >
> >> > and say the following
> >> >
> >> > 9.4 Line Layout
> >> >
> >> > If a profile that applies to a Document Instance requires use of the
> >> > #lineBreak-uax14 feature (i.e., the value attribute for the feature is
> >> > specified as use), then the recommendations defined by Line Breaking
> >> > Algorithm [UAX14] apply when performing line layout on the content of
> >> > the
> >> > Document Instance.
> >> >
> >> > [1] http://www.unicode.org/reports/tr14/
> >> >
> >> >>
> >> >>
> >> >> Best,
> >> >>
> >> >> -- 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.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>