Like all software, the font utilities can all be (probably endlessly) improved. Following are some possible projects.
If you would like to contribute, send mail to `firstname.lastname@example.org' first, so we can coordinate the work.
The original purpose of these programs was to create fonts for Ghostscript, the GNU PostScript-compatible interpreter written by Peter Deutsch. Adobe and many other vendors sell fonts which Ghostscript can use, but they place many restrictions on the use of those fonts. These restrictions certainly include modification and copying; in some cases, they even include using the font on more than one printer or display! These restrictions are contrary to the aims of the GNU project.
Obviously we cannot compete in volume with Adobe, Bitstream, or other vendors, all of whom probably have dozens if not hundreds of people working on nothing but font production, and additional people hired as programmers in support. The present authors (both working half-time) are the entire FSF "font production" department, both for design and for programming.
Fortunately, we do not need to compete in volume (certainly we haven't needed the thousands of Adobe fonts in our practice as typographers). Our aim is to produce the basic typefaces for typography: Garamond, Bodoni, Gill Sans, Univers, Baskerville, and perhaps a few others. If someone wants some other typeface, they could use our programs to make it, and, we hope, contribute it back to GNU for others to use.
We do need volunteers to help create fonts for the GNU project. You do
not need to be an expert type designer to help, but you do need to know
enough about TeX and/or PostScript to be able to install and test new
fonts. Example: if you know neither (1) the purpose of TeX utility
gftopk nor (2) what the PostScript
command does, you probably need more experience before you can help.
If you can volunteer, the first step is to compile the font utilities (see section Installation). After that, contact us at `email@example.com'. I will get you a scanned type specimen image. See section Creating fonts, for how to use these utilities to turn that into a font you can use in TeX or PostScript.
This section owes a great deal to Charles Bigelow (co-designer with Kris Holmes of the Lucida typeface family), who has generously answered our many queries about fonts and the law around the world with remarkable patience and understanding. (But he is naturally not responsible for any errors here, much less our opinions.)
Fonts have always been treated rather strangely under the law, as befits their rather strange nature: letterforms are indivisibly both useful and artistic. In most countries, and in all countries until recently, utility has taken precedence; i.e., it has been legal to copy fonts without permission or fee (the sitation that the Free Software Foundation hopes will obtain for software).
In any case, to the best of our knowledge, the situation in those countries which have any sort of typeface protection is as follows:
In 1973 the international Vienna treaty on typeface design protection was proposed. France ratified it in 1974 or 1975, and Germany in 1981. The English law might constitute ratification, but this has not been settled. In any case, since at least four countries have to ratify it before it takes effect (and even then it takes effect only in those countries which ratify it), it is still of no consequence for now.
Here are some possible projects:
pnmrotate, which mentions that article, in the PBMplus distribution could perhaps be adapted.
string_to_bitmap(in `font.c') which understands kerns and ligatures.
In addition, one general enhancement would be to allow more than 256 characters per font. The bitmap formats allow this already, and the TFM format has some support for it.
Two other smaller general improvements: combine multiple `-range' options; allow for omitting ranges.
We didn't worry about making the programs work with any C compiler; instead, we used GNU C extensions where they were useful. Likewise for GNU make.
We allowed ourselves this luxury because these programs are not historical utilities which people would expect to find on any Unix system. Rather, they are application programs. Perhaps having them work only with other GNU programs will encourage people to switch to GNU programs, or at least become aware of them.
It probably would not be too hard to change the programs to work with other ANSI C compilers. Changing them to work with old C compilers would be more painful. Thus far, the dependency on GCC hasn't proved a serious problem, because GCC runs on so many machines.
It would be dull but straightforward to write Makefiles for the programs which didn't use any of GNU make's special features. As with GCC, though, GNU make is so widely available that we haven't felt it necessary to do so.
The one exception is to this are the dozen or so files in the `lib' and `include' directories which implement the path searching algorithm. Because these files are shared with the TeX, Dvips, and XDvi distributions, they are written to work with old C compilers.
See section Archives, for information on how to obtain GCC and the other programs mentioned. See section `Portability as it applies to GNU' in GNU Coding Standards, for more discussion of the portability of GNU programs in general.
This section describes some of the conventions we used in the organization of the source code. See section `Top' in GNU Coding Standards, for the general GNU conventions.
In our sources, `.c' files include `config.h' first, which in turn includes `global.h', which includes `types.h' and other header files which define ubiquitous identifiers.
`.h' files, on the other hand, do not include `config.h'. They only include whatever headers are needed to define what they themselves use--typically including but not limited to `types.h'.
All `.h' files are protected with
The upshot of these conventions is that headers can be included in any order, as many times as necessary. In a `.c' file, only those headers which define symbols needed in the C source need be included, without worrying that some headers depend on others. (ANSI C defines its headers to follow these same rules.)
Virtually all `.c' files--the only exceptions are (sometimes)
`main.c' and some library files--have a corresponding `.h'
file, which defines all the public symbols (e.g., non-
routines and types). in the `.h' file are intended to explain the
external interface; comments in the `.c' file assume you already
know what's in the `.h' file, to avoid having the same information
in two places, and try to explain only implementation details.
Therefore, a `.c' file should always include its corresponding `.h' file, to ensure consistency between the definitions and the declarations. GCC 2's `-Wmissing-prototypes' option can be used to check this.
The main program is always in a file named `main.c'. Typically it
loops through all the characters in the input font, doing something with
them. Parsing arguments is also done in `main.c', in a function
getopt. See section Command-line options, for more information on option parsing.
The `configure' script used to determine system dependencies is generated by GNU Autoconf from `configure.in'. When `configure' runs, it creates `include/c-auto.h' from `include/c-auto.h.in' to record what it discovers. `config.h' includes this file.
We access members of most structure types via macros instead of with
-> directly. We pass and return whole structures
without hesitation; this has not resulted in any noticeable performance
loss. When we use pointers to structures, it's almost always because we
need a distinguishable value (i.e.,
When a function has no side effects (e.g., assignments to global
variables), and does not examine any values except its arguments (e.g.
if a pointer is passed, it does not examine the data pointed to),
we declare it
const. (This is a GNU C extension.)