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

Hi Glenn,

Thanks for the information re: line breaking.

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

How much variation would you expect in the metrics of the various
Helvetica-like fonts used by OWP-based presentation processors?

Thanks,

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

Received on Friday, 11 October 2013 15:32:49 UTC