Explained below are some design decisions; it turns out that
Word Perfect for Linux uses a very similar font solution, so
maybe if you've tinkered with Word Perfect's fonts, you might
better understand what we're doing.
*********************************************************
If you're lazy and don't care how the new fonts work,
but just want to make the binary run, skip to the
section at the bottom marked just for you.
*********************************************************
As of now (or tonight's push to the anonymous CVS mirror),
AbiWord gets its fonts much differently than it did before.
AbiWord, on startup, parses a fontpath (you can set one through
the ABIWORD_FONTPATH environment variable, to a list of
directories seperated by semicolons). If one isn't set,
it looks for "../../lib/unix/fonts". Since this is a relative
directory (and just a fallback until we get some system-wide
application preferences written to disk somewhere), the
executable will need to be run from the abi/src/wp/main/unix
directory. If you have a font path set correctly, you can
run it from anywhere.
You're probably asking, "Ok, now I want to set my font path, but
where do I point it?" On our web server, in the downloads
directory, there is a big tarball full of Type1 fonts, in
ASCII format (PFA) with accompanying Type1 metric files
(AFM). Grab this tarball:
http://www.abisource.com/downloads/abi-fonts.tar.gz
And unpack it from the directory which is the parent of
the abi/ tree (in other words, unpack it from the same place
you would expand a source tarball, or do a top-level CVS
checkout).
This collection of fonts will probably change before release,
but shouldn't change often. In fact, you should always be able
to have a functioning word processor with this collection of
fonts.
Once you unpack these fonts, you will have an
abi/src/wp/lib/unix/fonts directory in your tree, with all
the contents of the tar file, plus a "fonts.dir" which should
have come in from CVS. This file is in the same format
X uses to pick fonts from a directory. In order for X to find
your new fonts, you'll have to alter your X font path, either
by editing the server configuration (probably /etc/XF86Config
or /etc/X11XF86Config if you're on Linux, refer to vendor
documentation otherwise). You can also just temporarily append
the new directory with "xset fp+ [newdirectory]" where
[newdirectory] is (well), the directory with the fonts (and
the fonts.dir) in it.
You can run the program. If you have any bugs, send them to
the list. I realize having to explicitly set the X server
font path is a pain; soon enough AbiWord will do the
modification if it can't find its fonts. This might seem
somewhat invasive, but it's actually what Word Perfect does.
If anyone has any better ideas, lemme hear 'em. Also,
AbiWord should be able to load any old documents and handle
the fonts in them. Right now, if it can't find a font that
it used to find, it will just use Times New Roman. AbiWord
will get smarter about this in the future.
Oh, the font selector _dialog_ doesn't work... I'm still
writing the new one. However, the combo boxes in the toolbars
should work. A new font selector dialog should be working
in a day or so.
********* the short process for the lazy people **********
Get the tarball of fonts from
http://www.abisource.com/downloads/abi-fonts.tar.gz
Expand it in whichever directory you want. From that
level, check out the latest CVS tree (or unpack a
source tarball greater than 0.3.2, if it exists at
the time (it doesn't now)).
Run "xset fp+ [whereyouarenow]/abi/src/wp/lib/unix/fonts".
Because of the way xset interprets the directory,
you'll probably have to feed it an absolute pathname over
a relative one (like "/usr/src/abi/src/wp/lib/unix/fonts"
instead of "./abi/src/wp/lib/unix/fonts").
Compile.
Run the binary with present working directory
abi/src/wp/main/unix only (unless you want to set
ABIWORD_FONTPATH to the absolute directory where those
fonts are).
Good luck; you should only have to grab this font collection
once in a long while. Since the collection is presently
just a bunch of fonts which ship with GhostScript, they're
not exactly pretty and well-hinted for the screen, but
they print well.
********** end of the short process **********
More info:
Things will get better. I realize that this process
is a bit cumbersome. There's now a problem where you
are displaying the application on a machine that isn't
where the process is running. This means that doing an
"xset" with the path to the client-side directory will fail
(since the server can't find the same directory to read
display fonts). You'll have to either manually copy the
contents of the abi/src/wp/lib/unix/fonts directory to
the display machine, and add it to the path, or set up
a font server on the client-side machine and set the X
server to get fonts from there. See vendor documentation
for this.
Perhaps guidelines for hacking the fonts.dir
to add your own fonts will come in a later message. It's
really not very difficult if you have an ASCII format
Type1 font and the metrics file for it.
-- Shaw Terwilliger