path: root/doc/enhance.texi

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

@node Enhancements
@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
@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.


@node Program features
@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 (in fact, seeing the
bitmap and the generated splines simultaneously would be useful).
@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
@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
@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.)