******************************************************************
*                                                                *
*                                                                *
*          Title : Font conversion                               *
*                                                                *
*         Author : Neil Raine                                    *
*                                                                *
*           Date : 23-Apr-90                                     *
*                                                                *
*        Version : 1.00                                          *
*                                                                *
*  Change Record :  3-Apr-90    Initial draft                    *
*                   4-Apr-90    End users converting fonts       *
*                  23-Apr-90    Adobe type 1 format stuff added  *
*                                                                *
*                                                                *
******************************************************************

Font conversion
===============

This can be split into two areas:

    *   Conversion from our font format to others.

    *   Conversion from foreign font formats into our own.

Since the number of Acorn format fonts is likely to be far less than the
number available in other formats, the former category is really only
required to support rendering of our fonts on devices such as PostScript
printers.  This is described in the 'Download' document.

The latter category of conversions will be useful to increase the number of
fonts available to Archimedes users.

I believe it would be legal to supply end users with programs that allowed
fonts supplied for other font rendering systems to be converted to our
format, provided that we can read the appropriate disc format.  This
effectively would mean that fonts intended for (eg) the Apple Macintosh
could be used on an Archimedes.

The prime candidates for being converted to Acorn format are:

    *   Adobe type 1 format (internal format for PostScript printers)

    *   Apple/BitStream 'Royal' format (for Macintoshes)

    *   Scanned fonts (in bitmap form)

There are two levels of sophistication for conversion of each of these
formats: construction of the outlines, and construction of the hints (if
any).

These are discussed below:


Adobe type 1 format
-------------------

This format is used for the Adobe internal fonts in the Apple Laserwriter,
and will become increasingly widely available as the best format for fonts
to be downloaded to a Laserwriter.

Adobe have recently published the format of these fonts, including the
encryption mechanisms.

A font file consists of a simple PostScript program that creates a font
dictionary containing a set of 'CharStrings' that define each character. 
The CharStrings are encoded byte sequences, which are a set of integers and
commands that define the outline of the character and some hinting
information.  Normally a large part of the PostScript program is itself
encoded as a sequence of hex digits, decoded using the 'eexec' command.

The format of such font files has been restricted to allow a parser that is
not a full PostScript interpreter to read the data (ie. the Adobe Type
Manager, a program running on the Mac that gives access to Adobe Type 1
fonts for screen use).  This makes it much easier to write a converter that
reads such fonts.

The outline format has the following features:

    *   outlines represented as a series of bezier curves
    *   common sections (eg. serifs) can be called up as subroutines
    *   paths are directional (filled on left)
    *   outlines do not intersect, to allow stroking of fonts

The hints can:

    *   control the widths of character stems
    *   control the relative positions of straight and curved sections
    *   control the relative heights of characters throughout the font
    *   relate the heights of all characters in a family of fonts
    *   allow slightly curved sections to be made flat at small sizes

The hints encoded in Adobe type 1 fonts are similar to the Acorn format in
that they consist of a series of horizontal and vertical stem 'zones', which
are used to control the thickness of the stems at small sizes.

In general such graphical hints are higher-level and easier to convert from
than low-level representations such as sets of instructions that do specific
things.  They also match well with our existing scaffold lines.

Coupled with the existence of a large number of fonts in this format, this
means that the Adobe type 1 format would be a good candidate as a source of
fonts for RISC OS.

They are also the most useful format to generate, since they work on
PostScript printers.

It may be that we will have to extend the definition of our own font files
to enable them to be converted into efficient type 1 files - for example,
for efficient cacheing type 1 fonts should each be given a unique ID (an
integer), which must be allocated centrally by Adobe.  We can put special
knowledge into our font convertor to cope with existing fonts.


Apple TrueType ('Royal') format
-------------------------------

This is a sophisticated font format with support for internationalisation
(even down to alternative font names for different languages!) and a hinting
mechanism.

The character outlines consist of a series of subpaths, composed of a set of
quadratic B-splines.  These can be easily converted to a set of cubic Bezier
curves, although the result will be non-optimal and will be almost twice as
big as the original.

Composite characters are allowed - these are also supported by our own font
format.

The hinting mechanism consists of a set of instructions in a specialised
language that accompany each character's outline description.  Each
instruction is a single byte, rather like the opcode of a simple
microprocessor, and these manipulate values on an operand stack. 
Conditionals, loops and function calls are allowed, but branch instructions
are not.  There are specialised instructions for doing hints:

    *   grid-fitting of points
    *   interpolation of points in between fitted ones
    *   line angle adjustment
    *   special adjustments at certain point sizes
    *   finding the intersection of two lines
    *   character stem size equalisation
    *   adjustment for oversize/undersize dots on the output device

Basically the design of this hinting mechanism makes it extremely difficult
to convert the low-level information contained in a hinted font into any
other format that does not use similar low-level primitives.  It is clearly
designed to allow conversion of other font formats into it, but not
vice-versa.

Another potential problem is that the format has an optional encryption
scheme built-in, which will make it difficult (though not impossible) to
extract the outline and hint information.  It remains to be seen whether
many manufacturers will use this facility.

Apple is going to use more conventional discs in future, that our hardware
may be able to read.  If this is the case, then the MultiFS project which is
a part of the RISC OS 2.50 development will allow us to read this disc
format directly.

In that case we could provide a utility program to end-users to allow them
to convert Apple fonts into our format, or alternatively allow our font
manager to read the fonts on the disc directly.


Bitmaps
-------

Bitmap fonts can be obtained in three ways:

    *   Decoding a bitmap font file

    *   Rasterising fonts into bitmaps

    *   Scanning hard copy

The first method is normally the simplest, provided the file format is
known, but normally such fonts are only available at relatively small sizes.

The second method involves generating a font from its outlines at a
convenient size, using the package that handles that font format, and then
extracting the contents of the bitmap buffer where the results were sent. 
This is fairly simple, assuming that the results of rasterising the font can
be extracted (eg. this would be difficult if the output device was a laser
printer).

The third method involves using a scanner to read the contents of a page
containing samples of the font required.  This option is likely to be
available for any font required, although the results may contain some
undesirable artifacts from the scanning process.

I have already written a program that can generate a set of Bezier curves to
describe the outline(s) of a monochrome bitmap, although certain parameters
need to be altered depending on the size of the bitmap, and how 'smooth' it
is.

However, I currently have no way of automatically generating suitable hints,
so these have to be added by hand.

Since conversion of bitmaps will be a lengthy process, one could not expect
end users to have to perform this.  Instead, the fonts would have to be
prepared by font vendors, which means that the original fonts converted in
this way would have to be non-copyright.

