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

On Fri, Oct 11, 2013 at 3:10 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote:

>  This appears to be meeting a different requirement: it allows for line
> breaking at sensible places within the text, if a break is required. It
> does not address the issue of unpredictable rendered text width.
>

I'm pointing out that there are three major aspects to obtaining
deterministic text layout, in order: line breaking algorithm, font/glyph
metrics, including support for GSUB/GPOS/kern functions, and glyph shapes.
There is also a fourth category, which includes glyph shape rasterization,
anti-aliasing, and LCD sub-pixel support, but this typically doesn't affect
line breaks.

If two different implementations don't use the same line breaking
algorithm, then none of the rest may matter. At present, TTML doesn't
prescribe an algorithm except for the feature I mentions. However, worse,
XSL-FO and CSS don't specify one either, and don't really have a way to
specify an algorithm if they support multiple algorithms. So there is no
way to translate TTML into either XSL-FO or CSS and then specify the line
break algorithm to be used.

It may be the case that the XSL-FO or CSS implementation will use UAX14, or
maybe it won't, and you won't probably know what algorithm it uses.


>  In terms of the presented options I believe there is an OPTION 5, which
> is to improve the shared knowledge between the author and the renderer of
> the font metrics without necessarily sharing fonts.
>

The IMSC approach is effectively this option but needs further development
> to explain how it would work in practice.
>

I'm not sure how this would work. The spec would have to actually contain
the metrics, but then there is the problem of how to use that on a
presentation processor (PP). If the PP uses XSL-FO or CSS, I suppose it
could ensure that some font on the platform was available (by installing if
needed) that uses those metrics, but then it comes back to the problem of
what line breaking algorithm is used by XSL-FO or CSS.

Of course, if the implementation does its own presentation (without relying
on XSL-FO or CSS), then a specific line break algorithm could be used with
such metrics.

However, given the expected use of OWP (open web platform) technologies to
perform rendering of TTML in browsers, I doubt any feature or requirement
to use alternative metrics for a font will work.

>

>
>  An alternative approach for this would be to set font metric value
> ranges for height and width, i.e. to specify with more richness the
> constraints that the renderer should meet when selecting a suitable font,
> e.g. min and max values.
>

This would only be useful when using bitmap fonts. Outline fonts will have
their metrics scaled along with their outlines.


>
>  Kind regards,
>
>  Nigel
>
>
> On 11 Oct 2013, at 04:48, "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<http://www.w3.org/TR/2013/REC-ttml1-20130924/#feature-lineBreak-uax14> feature
> (i.e., the value attribute for the feature is specified as use), then the
> recommendations defined by Line Breaking Algorithm<http://www.unicode.org/reports/tr14/#Algorithm>
>  [UAX14] <http://www.w3.org/TR/2013/REC-ttml1-20130924/#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.
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>>
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------
>