Re: Choosing the Set of Renderable Strings

From: Richard Wordingham via Unicode <unicode_at_unicode.org>
Date: Sat, 19 May 2018 04:00:20 +0100

On Tue, 15 May 2018 04:19:42 -0800
James Kass via Unicode <unicode_at_unicode.org> wrote:

> On Mon, May 14, 2018 at 11:31 AM, Richard Wordingham via Unicode
> <unicode_at_unicode.org> wrote:

> > I've seen an implementation of the USE render
> > canonically equivalent strings differently. ...

> Because the USE failed or because the font provided look-ups for each
> of those strings to different glyphs?

Unless I haven't picked up a recent change, neither Microsoft (by
evidence of MS Edge) nor Apple (by evidence of Safari in iOS 10.3.2)
normalises Tai Tham text. <Tone, SAKOT> gets just one dotted circle,
while Apple and Microsoft award a dotted circle to each mark in the
canonically equivalent <SAKOT, tone>. Not many fonts handle two dotted
circles - subscript formation has to work in the context <DOTTED
CIRCLE, SAKOT, DOTTED CIRCLE, tone, base>. There's also the formal
problem that <DOTTED CIRCLE, SAKOT, DOTTED CIRCLE, tone> is actually a
legitimate sequence in the backing store. The defence to a charge of
violating the character identity of DOTTED CIRCLE would be to say that
such sequences are not supported - a renderer is not required to
support all strings!

Incidentally, I've fixed the Lamphun font; it will now install in
Windows 10. TTX found ways to reduce its size by 10%. While it should
work for most text, there are a few sequences that aren't handled
properly. These are issues that pertain to the font domain, not the
domain of the rendering engine.

Richard.
Received on Fri May 18 2018 - 22:00:51 CDT

This archive was generated by hypermail 2.2.0 : Fri May 18 2018 - 22:00:51 CDT