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

Agreed… the concept of the font metric dominating the region metric is the problem (for subtitling applications and others I would suggest). By allowing the region metrics to dominate, and forcing fonts to scale to fit, some of these problems disappear… although a mechanism is needed to communicate to the presentation processor the enforced width of the rendered inline text blocks.

Best regards,
John

John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 270 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems


Visit us at
SMPTE Technical Conference and Exhibition, Booth 107, Loews Hollywood Hotel, October 22-24

P Before printing, think about the environment

From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: 11 October 2013 15:43
To: Glenn Adams
Cc: Pierre-Anthony Lemieux; Timed Text Working Group
Subject: Re: ISSUE-283 (Deterministic Presentation): Deterministic text wrapping and presentation [TTML2]

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.

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.


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.

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

This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ