From: Richard Cook (email@example.com)
Date: Wed Oct 13 2004 - 14:23:53 CST
On Oct 13, 2004, at 10:27 AM, John Jenkins wrote:
>> Using a certain newly "Unicode-aware" database application which
>> shall remain nameless (FileMaker 7):
>> imported UTF-8 sequences like [U+0065][U+0303] <e, tilde> get
>> remapped internally to [U+1ebd] LATIN SMALL LETTER E WITH TILDE.
>> Is this kind of behavior what one would expect?
> Yes. Normalizing Unicode text on input is quite kosher, and generally
> a good idea.
Well, it's (not really) funny, but I was under the mistaken impression
that NFD was preferred ... NFC strikes me as a bit backward in some
respects, but, oh well ...
>> It's problematic (and buglike) for at least one reason: one needs to
>> put all these precomposed things in one's font, or FileMaker doesn't
>> display them properly.
> Well, on Mac OS X you can't guarantee that the decomposed things will
> display properly without font support, either (which means creating
> the precomposed glyphs anyway, and adding the 'morx' table to do the
> composition). Fortunately, Apple provides some *excellent*, free
> tools to handle just such cases…
I wish when you said "you can't guarantee that the decomposed things
will display properly without font support" you meant that there must
be kerning or other instructions, for precise placement (and skip the
precomposed things completely).
If someone uses a base+combining diacritic sequence that has no encoded
precomposed counterpart, how is this handled? with a precomposed form
But, it is possible to set the metrics of a combining form so that it
combines with a base without having to resort to precomposition, isn't
Probably I need to bone up on 'morx' ...
This archive was generated by hypermail 2.1.5 : Wed Oct 13 2004 - 18:52:29 CST