Choosing the Set of Renderable Strings

[Richard Wordingham via Unicode]

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.