I don't know any of the details, but if they decided to store font
names in NFD, it would still be possible to NFC the text before it
goes into a rendering engine; while that step is not free, compared to
rendering costs it is pretty trivial.
An even better solution would be to use whichever form had available
glyphs. That is, if there is an a-macron glyph use that; otherwise use
an a and position the macron with respect to it.
“Eppur si muove”
----- Original Message -----
From: "Juliusz Chroboczek" <firstname.lastname@example.org>
To: "John Hudson" <email@example.com>
Sent: Wednesday, May 29, 2002 03:59
Subject: Re: Normalisation and font technology
> JH> Apple recently started applying normalisation to file names in
> JH> OS X, with the result that the content of folders can now only
> JH> correctly displayed with fonts that contain the necessary AAT
> JH> table information
> That's very surprising. Especially considering the excellent job
> did with Openstep 4.0.
> Even if you work with fully decomposed characters internally,
> to precomposed glyphs at display time is a triviality.
> And even if you don't find a suitable precomposed glyph or a
> entry in the smart font, for a large number of combining classes you
> can provide legible albeit not necessarily typographically
> output by semi-randomly positioning the components.
> JH> Do you really want word processing applications or web browsers
> JH> that can only correctly display text in a handful of fonts on a
> JH> user's system?
> Please note that this is not software meant for actual use; it is
> an experiment to show that we don't need heavy artillery in order to
> implement reasonable typesetting for the GLC subset of Unicode.
> JH> This in turn suggests that if text is going to be decomposed in
> JH> normalisation, it should be recomposed in a buffered character
> JH> string prior to rendering.
> The approach taken in Cedilla is different. The text is typeset as
> sequence of Combining Character Sequences (CCS). Given a
> CCS ``b c1 c2 ... cn'', Cedilla first attempts to find a precomposed
> glyph; if that fails, it attempts to find a precomposed glyph for
> ``b c1 ... c(n-1)'', and compose it with the glyph for ``cn''.
> All of that happens on the fly, there's never any need to do
> buffering. With suitable memoisation (caching), only a tiny
> of the execution time is spent on searching for the right glyphs.
> Cedilla implements a number of other techniques for conjuring
> glyphs; the main difficulty was finding the right ordering of the
> various fallbacks. It turns out that it is more important to avoid
> the ransom-note effect than find the best glyph.
This archive was generated by hypermail 2.1.2 : Wed May 29 2002 - 09:08:57 EDT