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

> Given the lack of definition of "Helvetica-like",

I meant as in the following, which are referenced in IMSC:

http://www.microsoft.com/typography/fonts/family.aspx?FID=8 (Arial)
http://www.linotype.com/en/526/Helvetica-family.html (Helvetica)

Thanks,

-- Pierre

On Fri, Oct 11, 2013 at 8:39 AM, Glenn Adams <glenn@skynav.com> wrote:
>
> On Fri, Oct 11, 2013 at 9:31 AM, Pierre-Anthony Lemieux <pal@sandflow.com>
> wrote:
>>
>> 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?
>
>
> Given the lack of definition of "Helvetica-like", I would interpret that as
> meaning any font that could be used to map the proportionalSansSerif generic
> font family. As such, there is extremely wide range of fonts and metrics
> that apply.
>
>>
>>
>> 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 16:06:33 UTC