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

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