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

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

>  [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.
>

If the font isn't downloaded on demand (or included along side the TTML
resource), then, unless we require every PP to implement a concrete font
containing a specific set of embedded bitmaps, then there will be little
hope for interoperability.

By concrete font, I mean we would need to actually supply the font resource
containing the embedded bitmap glyphs. Let's call it the *TTMLBitmaps* font.
There are probably a few open source fonts from which we could obtain the
necessary shapes (already in bitmap or outlines which we would need to
pre-rasterize).


>
>  Nigel
>
>
>   On 11/10/2013 17:26, "Glenn Adams" <glenn@skynav.com> wrote:
>
>
>  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.
>>
>> ---------------------
>>
>
>
>
> ----------------------------
>
> 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.
>
> ---------------------
>