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

[Scroll-saver in operation]

Thanks Glenn – that's one potential solution on the table.

I think the point about downloadable fonts though is that an author specified font is available for rendering by the presentation processor. The mechanism for it being made available doesn't have to be by on-the-fly downloading – it could have been delivered prior to document processing by another mechanism. However the most general solution is indeed to provide access to the required fonts online and on demand.

Nigel


On 11/10/2013 17:26, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:


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

On 11/10/2013 16:23, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:


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

On 11/10/2013 15:29, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:


On Fri, Oct 11, 2013 at 3:10 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto: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<mailto:glenn@skynav.com>> wrote:


On Thu, Oct 10, 2013 at 9:23 PM, Pierre-Anthony Lemieux <pal@sandflow.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto:sysbot%2Btracker@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.

---------------------




----------------------------

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.

---------------------