On Wed, 14 Aug 2002, Martin Kochanski wrote:
> (1) Most software doesn't know what characters exist in any particular
> font that the user happens to have chosen, and it doesn't want to know.
> This is straightforward modular software design: some part of the
> *operating system* is responsible for fonts, rendering, etc.
Then let's call a part of the operating system. I was specifically having
Pango in mind, a text-layout library used in GNOME. Pango queries fonts to
find available characters. I was also thinking about Arabic text
terminals.
> (2) Even if you had software that did laboriously check every character
> in every font, it wouldn't be able to use the compatibility
> decomposition because it wouldn't know it existed... until it, itself,
> had first been updated with new Unicode tables. By which time the user
> might as well have loaded the new fonts.
I explicitly referred to the case of newer software and older fonts. This
happens frequently with Free operating systems, where the software is
updated regularly, but since only a few free fonts are contributed, they
will be updated much slower. Also, I always dream about pieces of software
that can load Unicode data files dynamically. These are also a case when
more standard data will help implementations.
> How many word processors in common use are *incapable* of including
> graphics in their documents? I use Word 2.0, and it has that feature,
> and I use it the whole time: for example, for my signature. Unless there
> is a large installed user base of pre-1992 software, using a simple
> graphic would work; and would have the advantage of instant
> implementation on every platform with no reprogramming.
Is this a comment recommending against encoding this character?
roozbeh
This archive was generated by hypermail 2.1.2 : Wed Aug 14 2002 - 04:39:28 EDT