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

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

Received on Friday, 11 October 2013 06:23:48 UTC