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

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.

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.

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.

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.

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