>- This entails creating fonts that have the presentation form
>glyphs accessible in the cmap via PUA codepoints [...]
True. But smart users may understand that they don't have to do so and why,
while naive users would probably stick to characters that are not on their
keyboard (and presentation form have no reason to be on a keyboard).
>- Smart font technologies, such as AAT and OpenType, can handle
>complex script rendering [...]
True. I would not suggest to implement naive rendering engines for systems
that already have these sharp technologies.
>- [...] its ability to
>support custom characters that an end user might need is
>limited [...]
True. Probably such a modest display engine would not even try supporting
user-defined characters.
>Not to say that, therefore, this shouldn't be done. This is
>certainly a valid use of the PUA. Any attempt to get widespread
>adoption within industry of any particular use of the PUA,
>however, is a bad idea.
I totally agree with that. This is the point: accept standardizing PUA
usage, and you'll end up having to use MIME to distinguish Microsoft
Unicode, Mac Unicode, AOL Unicode, Linux Unicode...
I prefer applications and systems that only do one or both of these two
things:
1. Use the PUA internally for they own purposes (but don't try to define
transmittable PUA encodings);
2. Leave the PUA in the hands of end users, allowing them to draw glyphs (or
define character sequences) and associate them to PUA code points in their
personal settings.
Ciao. Marco
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:59 EDT