لطفا منتظر باشید ...
Running an
Expanded Font Server
Unfortunately, X's font handling is fairly
primitive by the standards of most desktop OSs at the start of the 21st
century. Most users notice this in the awkward methods required for adding
fonts and in poor font displays in many programs, particularly if the font path
isn't set up correctly or if the system uses the default fonts, some of which
aren't as good as their counterparts in other OSs. At least as important,
though, is the fact that X's font system wasn't designed for integrating screen
fonts with printer fonts. This fact, and other design limitations in X's font
handling, make the task of creating a smooth interface between screen fonts and
printed fonts difficult for applications in which this is important, such as
word processors and desktop publishing packages. For this reason, there are
various alternatives to traditional font servers available in Linux. Many
of these are implemented internally to specific programs, but at least one is a
full-fledged font server that can be used by many programs.The most notable expanded font server for
Linux is known as FontTastic (
that are written with FontTastic in mind. Specifically, FontTastic can deliver
information such as an outline representation of a font, the raw font data, and
kerning information. This information isn't readily obtained through a traditional
font server, or from fonts handled directly by the X server. This information
allows programs to do things that they might not otherwise be able to do, at
least not without some other way around X's font-handling limitations. For
instance, consider a word processor. If a word processor uses X's conventional
font handling, a user may specify a standard X font for use in a document. When
it comes time to print, though, the word processor must somehow tell the
printer about the font in question. Assuming the printer is a PostScript
printer, this means either telling the printer to use one of its built-in fonts
or downloading the font to the printer. If the font chosen by the user is some
non-standard font, though, the only way the word processor might be able to
send the font is as a bitmap, because that's how it's delivered to X
applications. Without knowing the printer's resolution, the word processor may
have to guess what resolution to use, request characters at that resolution
from the font server, and paste the results together. The result probably won't
be very good.With FontTastic, on the other hand, the word
processor can request the raw font data to embed in the document, which is a
superior solution because it produces a higher-quality output with less effort.
(If the font is a TrueType font, the word processor might be able to convert it
to a Type 42 font if it knows the PostScript printer can handle this format, or
it may need to request the font in raw outline form and effectively reconstruct
the font. This is more work, but will produce a cleaner result than would an
attempt to print with bitmaps.) The word processor can also utilize improved
information on character sizes, spacing, kerning, and so on to produce
better-looking output.Because of its commercial nature, FontTastic
hasn't been widely adopted as a standard tool in the Linux community. It is
used, however, by at least two major commercial programs for Linux: Corel's
WordPerfect Office 2000 (which has now been discontinued) and VistaSource's
ApplixWare Office ( target="_blank">http://www.vistasource.com/products/axware/ ). If you run either of these programs, the package installs
FontTastic and runs it automatically when its master program runs. You can
create a configuration that allows other computers to use FontTastic as a
conventional font server, thus simplifying your overall network font
configuration requirements. (Studying the details of FontTastic's
implementation may take some effort, though.) FontTastic isn't the only way around the
problem of the disconnect between the screen and the printer. Some tools, like
TeX, avoid the problem by focusing on the printer, and leaving screen fonts to
fall where they mayTeX is a page description language, so TeX users edit
documents using text editors that may or may not display the document in
anything resembling the ultimate fonts. Other programs integrate screen and
printer fonts by ignoring X's font handling. For instance, WordPerfect 8 used a
very different model than its successor; version 8 of the program requires
users to install fonts in WordPerfect, instead of or in addition to installing
them in X. WordPerfect, not X or a font server, rasterizes fonts for display on
the screen. WordPerfect can then download the fonts to a printer or create
bitmaps that it downloads to the printer.Another approach is to tell the program where
the original font files are located. The program can then send those files to
the printer for use in rendering files that X renders for the screen. This
approach is simple, but X's lack of support for some of the finer font-handling
features can still cause on-screen displays to have awkward spacing, and if the
application doesn't use the appropriate information from the original font
files, the printout will suffer from this problem, as well. None of these
approaches is particularly network-oriented, so I don't cover them in any depth
in this book; I mention them only because they're alternatives to the network-capable
FontTastic, and because they may still use a network font server for on-screen
font display.
