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
