At 11:15 AM 23-09-99 -0700, Rick McGowan wrote:
>and Michael said...
>> The chief reason for wanting to do so now is font-related.
>Correction: It is rendering (text sub-system) related. Fonts themselves
>have nothing to do with it, Michael. Fonts are just numbered bags of
>-- it's what you DO with the glyphs that makes the difference. If all your
>display system can do is string glyphs one-after the other corresponding
>one-to-one with codepoints, then you'll need every interesting graphical
>element as a unit of encoding. If all your string-manipulation routines
>do is blind binary comparision, then you're out of luck in other ways.
I agree. There are certainly good arguments, from a font technology
perspective, for building precomposed glyphs within a font -- e.g.
controlled positioning of diacritic marks at small ppm sizes --, but it
does not follow that these glyphs need to be encoded. The problem once
again facing font developers is not whether there will be _an_
implementation of 'on-the-fly' composition in text processing and font
display systems, but just how many implementations we might have to deal with!
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:53 EDT