Subject: Re: RemapGlyph()
From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Mon Jun 25 2001 - 11:29:09 CDT
Hi Andrew,
> I'm pretty horrified by the font situation on Unix compared to
> Windows.
Yes, the Unix way of handling fonts is a mess ... One of the
fundamental problems is that the way you display glyphs on a
screen has nothing to do with the way you print them on paper.
> X fonts require "mappings" to be built and save on the HD and it
> looks like these mappings are the same as standard file encodings
> with UTF-8 being some kind of special case. All of this made my
> head spin. Are none of the fonts distro'd with Abiword unicode
> fonts? Or are we just omitting the mappings? If I had the
> mappings would I only see the characters if my locale encoding
> was set to UTF-8? Can I use my Windows fonts on Linux Abi?
> Can we make this all as easy as it is on Windows somehow?
> Multilingual church secreataries are going to hate Abi! (:
Historically the principal scalable font of the Unix world is a
PostScript font. All fonts distributed with AW are PS fonts, and
they live in a PostScript world of their own, a world in which
Unicode is pretty much a meaningless concept. Instead of
extending the encoding from 8-bit to more-than-8-bit, long time ago
Adobe solved the need for more then 256 glyphs in a font by giving
each glyph a name and referencing any needed glyphs that are
outwith the 8-bit range by name. This makes generating PS output
for printing easy (and human readable), but not displaying it on
screen, and as far as I know the X font server is capable of handling
only the basic 8-bit set in any PS font (even though the font may
contain many more glyphs).
Now, X is capable of handling 16-bit fonts and if your X server can
handle ttf fonts, then you can use ttf fonts from Windows (however,
X is not very efficient at doing so, so that attempts to use large ttf
fonts, such as Code2000, can easily crash the whole system).
Unfortunately, it is much more complicated to print with ttf fonts.
This is partly because the standard PS interpreter cannot handle
raw ttf font, but requires it to be wrapped in a special PS wrapper,
resulting in the so called type 42 font. Further, even though the ttf
font usually contains all the information that the PS interpreter
needs, typically ttf fonts (such as MS fonts) do not adhere to the
glyph naming conventions of PS.
You can use 16 bit fonts with AW, but only under utf-8 locale; this
is logical, to declare your locale encoding as ISO-8859-1 is the
same as to say that you do not care about characters outside of
iso 8859-1. (I think you are right about multilinugual church
secretaries, but the problem is not with AW, it is with Unix, and
until Unix replaces for good the locale system that was suitable for
the needs of 1970's with Unicode, it will not become and OS of
choice for great many people.)
In addition to using 16-bit fonts, an application can get around the 8-
bit limitations by using so called font sets; basically you have a set
of 8-bit fonts in different encodings which you use as if it was a
single font taking a glyph here and glyph there; AW does not at the
moment support font sets, changing the display side to font sets
might not be that much work, because gtk has a built-in fontset
support, but generating the PS output would be more complicated.
Finally, to answer your question whether we can make it as easy
on Unix as it is on Windows, probably not; the system is just too
messed up. We can only try to create the appearance to the AW
user that, as far as AW is concerned, things are easy and simple,
but at the point when the user needs something we did not bargain
for, such as Vietnamese :-), the bubble will burst, and the uggly
truth will become obvious.
Tomas
This archive was generated by hypermail 2b25 : Mon Jun 25 2001 - 11:32:46 CDT