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

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

>  On 11/10/2013 16:23, "Glenn Adams" <glenn@skynav.com> wrote:
>
>
>  On Fri, Oct 11, 2013 at 8:42 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote:
>
>>   On 11/10/2013 15:29, "Glenn Adams" <glenn@skynav.com> wrote:
>>
>>
>>  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.
>>
>>
>>  That's a fair point. However I think it's reasonable to remove line
>> breaking algorithms from the problem space because if an author wants
>> deterministic behaviour they can insert explicit line breaks according to
>> whatever algorithm they want. That part of the solution is already
>> available. This then changes the problem to being one of 'how can we be
>> sure that the text that the author thinks should fit within a given line
>> actually does fit?'
>>
>>     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.
>>
>>
>>  There still needs to be a specification for scaling limits regardless
>> of whether the fonts are rendered as bitmaps or outlines. Implementations
>> may reasonably quantise the permitted outline font scaling factors for
>> readability on a particular display, based on pixel pitch etc.
>>
>
>  I'm not following what is the problem that scaling limits is trying to
> solve. The author specifies a definite font size in absolute or relative
> terms, or gets 1c through inheritance.
>
>
>  The problem is more general than scaling limits: it's that the
> resolution of a definite font size in the current specification does not
> result in any kind of guarantee that the text that should (from the
> author's perspective) fit on a line actually does, when rendered.
>

This is not a scaling problem. It is a problem with author expectation
management. The fact is that outline fonts and their rasterizers do not
enforce a constraint that the outline or its rendered pixels fit into the
EM square. Authors that expect such a constraint to be enforced are used to
working with bitmap fonts where such a constraint does hold.

The only way to address this IMO is to require support for downloadable
fonts using WOFF (a wrapper for OT/TT 'sfnt' format), and require support
for the use of embedded bitmap fonts expressed using the OT 'EBLC' [1],
'EBDT' [2] and 'EBSC' [3] tables.

[1] http://www.microsoft.com/typography/otspec/eblc.htm
[2] http://www.microsoft.com/typography/otspec/ebdt.htm
[3] http://www.microsoft.com/typography/otspec/ebsc.htm

I'm not sure about the condition of native platform support for these
tables on the primary OWP devices.


>
>     If the PP uses an outline font, it scales (the font's EM square)
> exactly to that size, so limits don't apply. If the PP uses a bitmap font,
> then it either just uses the closest size or it *could* attempt to scale
> (with resulting degradation of visual quality).
>
>
>  Right – closest size may be bigger than the maximum intended size at
> authoring and we have no mechanism for specifying the safety margin that
> the author has allowed in case this happens. Hence the problem – it's not
> deterministic.
>

That is not a problem we can solve if we expect to rely only on OWP
mechanisms, e.g., CSS and XSL-FO, that is, unless downloaded fonts with
bitmaps are used.


>
>     So, are you only talking about limiting scaling when a device uses
> bitmaps and doesn't have an exact size match?
>
>
>  Sorry, I'm not convinced that outline fonts will be scaled exactly in
> all cases – see my point about quantised scale factors above. However I
> don’t think it's the main thing we need to worry about.
>

The EM square of an outline font will be scaled exactly modulo its internal
coordinate representation format (quantization effects). However, the
rasterization (grid fitting) process is rarely exact.

In part, I'm saying that any use of an outline font must be accompanied by
an expectation that every distinct device rendering will be different.
Expectations that it can be done better or differently are unrealistic.


>
>  Unstated so far, I should add that there's another exacerbating factor:
> the font size is chosen based on height, but line wrapping depends on the
> glyphs' widths. Different fonts (even outline fonts) can have the same
> height but result in rendered text that occupies different widths.
>

Of course. And there is also kerning, ligatures, more generally the effects
of GSUB/GPOS processing to consider.


>
>  I think we need a solution that fixes both height and width within some
> limits, but as always I'm happy to consider alternative solutions.
>

IMO, the only workable solution for what you are asking (that satisfies OWP
interoperability) is downloaded WOFF fonts containing only bitmaps.


>
>
>
>>
>>  This reminds me that an approach we have not described recently is
>> permitting implementations to squeeze text by some limited maximum factor
>> in order to fit on a line, if the authored content would otherwise overflow
>> that line. This technique is used in some commercially available bitmap
>> image subtitle rasterisers. Doubtless there are interesting implementation
>> complexities in terms of preferentially squeezing blank spaces rather than
>> displaying glyphs etc but I suspect we can set those to one side for the
>> time being.
>>
>
>  There is a CSS font-stretch property. According to the Chrome dashboard
> [1], approximately 2% of web sites use this property.
>
>  [1] http://www.chromestatus.com/metrics/css/popularity
>
>  However, according to [2], none of the major browsers support it.
>
>  [2] http://www.w3schools.com/cssref/css3_pr_font-stretch.asp
>
>  Even then, this property doesn't support a numeric stretch value, e.g..
> a percentage, but rather an enumeration of keywords.
>
>  So even if we specified use of this property, it may not work in
> practice.
>
>
>>
>>
>>>  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.
>>>
>>> ---------------------
>>>
>>
>>
>>
>> ----------------------------
>>
>> 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.
>>
>> ---------------------
>>
>
>
>
> ----------------------------
>
> 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.
>
> ---------------------
>