Go to the first, previous, next, last section, table of contents.

Enhancements

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 `bug-gnu-utils@prep.ai.mit.edu' first, so we can coordinate the work.

Additional fonts

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 program gftopk nor (2) what the PostScript scalefont 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 `karl@gnu.ai.mit.edu'. 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.

Legal issues

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:

United States
Typeface designs can be patented, but not copyrighted. Only a few designs have been patented. (Lucida and Stone are the only ones we know of. We don't know what the grounds were for patenting Stone, but Lucida had some novel features in its design which make it reasonable to patent, if one accepts the patent system in the first place.) Particular programs which instantiate a font can be copyrighted just as any other computer program can. This is arguably wrong, since font programs are nothing but a description of the shapes, possibly with some simple hints, and there's only one basic way to describe the shapes in any given language. Thus, the creativity lies in making the shape right, not in making the computer program right, so it would seem that to be consistent, the copyright laws should protect the design, not the program--the opposite of the current situation.
Germany
Typeface designs have been copyrightable as original works of art since 1981. The law passed then was not retroactive, however, German courts have upheld the intellectual property rights of font designers even for earlier cases. In one case the heirs of Paul Bauer (designer of Futura) sued the Bauer foundry for arbitrarily discontinuing a portion of their royalties, and won. Since 1981, many (perhaps most) designs have been copyrighted in Germany.
England
A copyright law passed in 1989 covers typeface designs first published in England (or published in Britain within 30 days of its publication elsewhere), and it is (unbelievably foolishly) retroactive. It's unclear how far back the law extends, but Times Roman, designed in the late 1920's and 1930's by Stanley Morison and cut by Victor Lardent for Monotype is probably covered. This does not mean GNU cannot have a Times Roman; it just means we cannot start with an English version, as the law does not forbid importing foreign versions of English typefaces.
France
The Romain du Roi typeface designed by Philippe Grandjean in 1702 for the French royal family is protected, and perhaps other such "royal" designs. Since these are not widely used anyway, it's not important that GNU provide them.

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.

Program features

Here are some possible projects:

BZRedit
BZRto
Fontconvert
GF library
GSrenderfont
Imageto
IMGrotate
lib
Limn
Handle the standard X toolkit options.
PK library
Implement output of PK files.
TFM library
XBfe

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.

Portability

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.

Implementation

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 #ifndef unique-symbol.

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-static 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 named read_command_line, using 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 . or -> 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., NULL).

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.)

Go to the first, previous, next, last section, table of contents.