@c Copyright (C) 1992 Free Software Foundation.
@c This is part of the GNU font utilities manual.
@c For copying conditions, see the file fontutil.texi.

@node Enhancements, Copying, GSrenderfont, Top
@chapter Enhancements

@cindex enhancements, future
@cindex improvements, possible future
@cindex future enhancements
@cindex projects

@cindex volunteering
@cindex contribution, making your own
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
@samp{bug-gnu-utils@@prep.ai.mit.edu} first, so we can coordinate the
work.

@menu
* Additional fonts::            GNU needs more fonts.
* Program features::            These programs can be improved.
* Portability::                 Assumptions about the programming environment.
* Implementation::              Conventions we used in the sources.
@end menu


@node Additional fonts, Program features,  , Enhancements
@section 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 @code{gftopk} nor (2) what the PostScript @code{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
(@pxref{Installation}).  After that, contact us at
@samp{karl@@gnu.ai.mit.edu}.  I will get you a scanned type specimen
image.  @xref{Creating fonts}, for how to use these utilities to turn
that into a font you can use in @TeX{} or PostScript.

@menu
* Legal issues::                Legality (and illegality) differ by country.
@end menu


@node Legal issues,  ,  , Additional fonts
@subsection Legal issues

@cindex legalisms
@cindex typeface design protection
@cindex copyright on fonts
@cindex font copyrighting
@cindex patenting of fonts

@cindex Bigelow, Charles
@cindex Holmes, Kris
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
@emph{useful} and @emph{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:

@table @asis

@cindex United States, font design protection law
@cindex Lucida, protection of
@cindex Stone, protection of
@item 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.

@cindex Germany, font design protection law
@item 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.

@cindex England, font design protection law
@cindex Times Roman, protection of
@cindex Morison, Stanley
@cindex Lardent, Victor
@cindex Monotype
@item 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 @emph{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.

@cindex France, font design protection law
@cindex romain du roi
@cindex Grandjean, Philippe
@item 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.

@end table

@cindex Vienna treaty
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.


@node Program features, Portability, Additional fonts, Enhancements
@section Program features

@cindex features, lacking

Here are some possible projects:

@table @asis

@item BZRedit
@itemize @bullet
@item
Rewrite as a C program along the lines of XBfe.
@item
@cindex hints
Add support for hints.
@end itemize

@item BZRto
@itemize @bullet
@item
@cindex TrueType
Output more font formats, e.g., TrueType.
@item
Output hints for Metafont and Type 1 fonts.
@item
@vindex FontInfo
Make better guesses for the @code{FontInfo} information.
@item
@cindex obliquing
Handle obliquing fonts by changing the transform matrix in the output,
instead of changing the numbers in the splines.
@item
@cindex nonlinear scaling
@cindex scaling, nonlinear
@cindex anamorphic scaling
@cindex optical scaling
Do nonlinear scaling.
@item
@cindex italic corrections
Handle italic corrections in the Metafont output somehow.  Probably have
to do the same in Charspace.
@end itemize

@item Fontconvert
@itemize @bullet
@item
@cindex virtual fonts
Output virtual fonts as an option, instead of another bitmap font.
@item
@cindex encodings, translating between
Allow specifying entire input encodings and output encodings (the
same @file{.enc} files that the other programs read).
@end itemize

@item GF library
@itemize @bullet
@item
Support multiple simultaneous open fonts, like the PK library does now.
@cindex checksum
@item
Output a checksum.
@end itemize

@item GSrenderfont
@itemize @bullet
@item
@cindex size of characters, maximum
@cindex limit on character size
Allow for characters larger than 1 inch square in the original font.
@item
@cindex slanted fonts
@cindex extended fonts
@cindex small caps
Implement slanting, extending, and small caps, a la Dvips.
@end itemize

@item Imageto
@itemize @bullet
@item
@cindex Tiff
Recognize more image formats, e.g., Tiff.
@item
@cindex splitting characters
@cindex characters, splitting
Perhaps the @samp{-column-split} option in Fontconvert should be
removed, and the equivalent information specified in the IFI file.
@end itemize

@item IMGrotate
@itemize @bullet
@item
Perhaps combine with Imageto.
@item
@pindex pnmrotate
@cindex rotation algorithm
Implement a good rotation algorithm, perhaps as described in: ``A Fast
Algorithm for General Raster Rotation'', by Alan Paeth, @cite{Graphics
Interface '86}, pages 77--81.  (We'd be interested in hearing of
optimized alternatives for the case of 90 degree rotation only).  The
program @code{pnmrotate}, which mentions that article, in the PBMplus
distribution could perhaps be adapted.
@end itemize

@item @code{lib}
@itemize @bullet
@item
Extend the encoding files to allow defining math attributes, probably by
rewriting the parsing routines as a Bison grammar.
@item
@findex string_to_bitmap
@flindex font.c
@cindex typesetting kerns and ligatures
@cindex kerns, typesetting
@cindex ligatures, typesetting
Write a variant of @code{string_to_bitmap} (in @file{font.c}) which
understands kerns and ligatures.
@item
@cindex BDF format
Add support for BDF or other bitmap formats.  Unrelated utility programs
now exist for handling the X11 BDF format (specifically, Bdf2gf and
GFto), but it might be useful to integrate BDF support.
@end itemize

@item Limn
Handle the standard X toolkit options.

@item PK library
Implement output of PK files.

@item TFM library
@itemize @bullet
@item
Support multiple simultaneous open fonts, like PK does now.
@cindex ligatures in TFM files
@item
Support ligatures in their full generality.
@item
Output a checksum.
@end itemize

@item XBfe
@itemize @bullet
@item
Allow showing more than one character at a time.
@cindex guidelines
@item
Adjusting (or at least seeing) the baseline, cap height, x-height, or
arbitrary guidelines.
@item
Handle multiple fonts.
@item
Notice if the window it's given is too small, and give up.
@item
@cindex window size for XBfe
Ask the window manager for a window big enough for the largest character
in the font, not the first character.
@end itemize

@end table

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 @samp{-range}
options; allow for omitting ranges.


@node Portability, Implementation, Program features, Enhancements
@section Portability

@cindex portability of sources
@cindex GNU C extensions

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.

@cindex GNU evangelism
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.

@cindex GNU make, dependency on
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.

@cindex path searching, implementation of
The one exception is to this are the dozen or so files in the @file{lib}
and @file{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.

@xref{Archives}, for information on how to obtain GCC and the other
programs mentioned.  @xref{Portability, , Portability as it applies to
GNU, standards, GNU Coding Standards}, for more discussion of the
portability of GNU programs in general.


@node Implementation,  , Portability, Enhancements
@section Implementation

@cindex implementation
@cindex coding standards
@cindex programming conventions

@c Texinfo has no good way of referring to a whole manual.  Argh.
This section describes some of the conventions we used in the
organization of the source code.  @xref{Top, , , standards, GNU Coding
Standards}, for the general GNU conventions.

In our sources, @file{.c} files include @file{config.h} first, which in
turn includes @file{global.h}, which includes @file{types.h} and other
header files which define ubiquitous identifiers.

@cindex header files
@file{.h} files, on the other hand, do not include @file{config.h}.
They only include whatever headers are needed to define what they
themselves use---typically including but not limited to @file{types.h}.

All @file{.h} files are protected with @code{#ifndef @var{unique-symbol}}.

The upshot of these conventions is that headers can be included in any
order, as many times as necessary.  In a @file{.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.)

@ignore
@c Skip this, who cares?  Anyway, we aren't perfectly consistent.
Since the headers can be included in any order, we arbitrarily chose to
have three groups of @code{#include}s: @file{config.h}; system or
library headers, such as @file{<sys/stat.h>} or @file{line.h}; and
program-specific headers.
@end ignore

Virtually all @file{.c} files---the only exceptions are (sometimes)
@file{main.c} and some library files---have a corresponding @file{.h}
file, which defines all the public symbols (e.g., non-@code{static}
routines and types). in the @file{.h} file are intended to explain the
external interface; comments in the @file{.c} file assume you already
know what's in the @file{.h} file, to avoid having the same information
in two places, and try to explain only implementation details.

@opindex -Wmissing-prototypes
@cindex missing prototypes
@cindex prototypes, missing
Therefore, a @file{.c} file should always include its corresponding
@file{.h} file, to ensure consistency between the definitions and the
declarations.  GCC 2's @samp{-Wmissing-prototypes} option can be used to
check this.

@cindex main program
@flindex main.c
The main program is always in a file named @file{main.c}.  Typically it
loops through all the characters in the input font, doing something with
them.  Parsing arguments is also done in @file{main.c}, in a function
named @code{read_command_line}, using @code{getopt}.  @xref{Command-line
options}, for more information on option parsing.

@pindex configure@r{, creation of}
@flindex include/c-auto.h@r{, creation of}
The @file{configure} script used to determine system dependencies is
generated by GNU Autoconf from @file{configure.in}.  When
@file{configure} runs, it creates @file{include/c-auto.h} from
@file{include/c-auto.h.in} to record what it discovers.  @file{config.h}
includes this file.

@cindex structure types
We access members of most structure types via macros instead of with
@code{.} or @code{->} 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., @code{NULL}).
@vindex NULL

@cindex functions, declaring @code{const}
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 @code{const}.  (This is a GNU C extension.)
