This can be split into two areas:
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:
These are discussed below:
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:
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.
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:
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.
Bitmap fonts can be obtained in three ways:
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.