[Freetype] Fonttootf: first cut of a BDF->TTF converter available

[Juliusz Chroboczek]

Hello,

The first cut of fonttootf, a BDF to snft (TTF or OTF) converter for
bitmap fonts is available from

  http://www.pps.jussieu.fr/~jch/software/files/fonttootf-20020821.tar.gz

This is an early beta, please do not redistribute this version.

A few caveats.  First, you need a version of FreeType that contains
the bug fix of August 19; this means current CVS.  Second, due to
another bug, you will not be able to use this code on BDF fonts
(you'll need to convert to PCF first).

Second, the Microsoft TrueType, Apple TrueType and OpenType specs
differ on what tables are compulsory.  Microsoft TrueType makes all
tables compulsory.  OpenType makes loca and glyf optional (but hmtx
compulsory), while Apple TrueType makes all tables optional.  Thus,
fonttootf can generate different variants of fonts with the -m and -g
flags.  Please see the man page for details.

In short, though, FreeType works with -g at least 2 and -m at least 1.
Pfaedit requires -g 3.  The cases -g 2 and -m 0 violate the OpenType
spec; all other cases are legal.

Here's a summary of font sizes:
                                            (1)      (2)         (3)
                         .pcf    .pcf.gz  pfaedit  fonttootf  fonttotf -c
8x13-L1.pcf              19572     4579     6908     4012        4032
8x13.pcf                410660    57158             54044       52244
helvR14.pcf              71804    13901             15780       15796
9x18.pcf + 18x18ja.pcf        77976 + 580901       796464      917620 

All sizes are in bytes.  Column (1) is the size of the TTF generated
by pfaedit; I didn't try to tune pfaedit's options -- this is not
meant as a fair comparison, but rather as a baseline.  Colum (2) is
the size of the TTF generated by fonttootf by default; column (3) is
the size of the TTF generated by fonttootf with glyph cropping
disabled.

The first font is a small (196 glyphs) small (8x13) charcell font.
The second is a large (almost 4000 glyphs) small (8x13) charcell font.
The third is a small (196 glyphs) small (14 ppem) variable width font.
The fourth is a large large bi-width font generated from two charcell
fonts (yep, fonttootf can do that).

As you'll notice, cropping doesn't buy you much.  In the case of the
variable font, this is expected, as the font is already cropped
(except that spaces are represented as 1x1 bitmaps, cropping
eliminates the bitmaps altogether).  In the case of the charcell and
bi-width fonts, cropping does reduce the bitmap data quite a bit;
however, the glyphs then have variable metrics, which prevents
fonttootf from optimising the metrics table by encoding metrics only
once.  Thus, the gain in bitmap data is mostly offset by the larger
metadata.  Only in the case of the 18-pixel font, where the bitmap
data dominates the font size, is cropping worthwile.

Here's a selection of table sizes for the three TTFs generated from
8x13-L1.pcf.

EBDT (bitmap data): (1) 2468, (2) 2272, (3) 2903.

In case (2), we gain some w.r.t. pfaedit by writing metric-less
bitmaps whenever possible.  In case (3), the bitmap data is much
larger, but all bitmaps are metric-less (as they are all equal) which
makes the EBDT only slightly larger.

EBLC (bitmap index): (1) 968 , (2) 698, (3) 84.

As above.  In case (2), some EBDT subtables have been replaced by
metric-less tables.  In case (3), there is a single metric-less table,
and the EBLC is tiny.

cmap (character to index mapping): (1) 698, (2) 52, (3) 52.

Here we simply order all glyphs so that the cmap table is trivial.
Pfaedit orders the glyph in what appears to be a random order, and
therefore has to output a complex cmap.

Regards,

                                        Juliusz