Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!hp4nl!ruuinf!jeroen
From: jeroen@ruuinf.UUCP (Jeroen Fokker)
Newsgroups: comp.sys.atari.st
Subject: This is the GDOS font format
Keywords: GDOS .FNT file format
Message-ID: <1192@ruuinf.UUCP>
Date: 14 Mar 89 08:38:01 GMT
Organization: Univ of Utrecht, Dept of CS
Lines: 91


This is the GDOS fontfile format that so many people asked for.
It is adapted from the (Dutch edition of the German book)
"Software development on the Atari ST" by J. and D. Geiss,
which is quite a nice book. 

A GDOS font-file consists of four parts:
1. an 88-byte header
2. a tabel that describes where the information for each character starts
3. an (optional) table that gives an extra horizontal shift to each char
4. the pixel data.

1. The HEADER consists of ints (2 bytes each), longs (4 bytes), and a string.
All values in the header are in Intel-format, i.e. low byte first.
In order to process them, you should first apply
			(n>>8)&0xFF  + (n<<8)
to each int value n, and likewise for longs. 
Items in the header are:
int   number of this font (1=system font)
int   font size in points (1/72 inch)
char[32] font name
int   lowest ascii value in font
int   highest ascii value in font
int   distance baseline to top of box
int   distance baseline to ascenders
int   distance baseline to e-height
int   distance baseline to descenders
int   distance baseline to bottom box
int   width of widest character
int   width of widest character cell
int   left offset for slanted style
int   right offset for slanted style
int   number of pixels to broaden bold caracters
int   thickness of underline in pixels
int   mask for halftone style (normally 0x5555)
int   mask for halftone slanted style
int   flags:  bit 0 set = system font
	      bit 1 set = optional table 3 is used
	      bit 2 set = data is in M68000 format (high-low)
	      bit 3 set = font is proportional
long  pointer to table 3
long  pointer to table 2
long  pointer to font data
int   number of bytes in a scan line
int   number of scan lines
long  pointer to next font

2. Next comes a TABLE which for each character gives the startbit
in the scan lines. There is one item more than the number of characters
in the font; the last item point to the first unused bit.

3. If flag 1 in the header is set, another TABLE is given
which for each character gives a (positive or negative) number.
Characters should be shifted right this amount of bits before output.

4. Finally comes the PIXEL DATA.
All characters are packed directly next to another, ignoring 
byte boundaries. Data is stored one row at a time:
A font like this:		    would be encoded:
	.*.***..**.***.***		 0x5C, 0xDD, ....
	*.**..**..**..**..		 0xB3, 0x33, ....
	******.*...*..****		 0xFD, 0x13, ....
	*.**..**..**..**..		 0xB3, 0x33, ....
	*.****..**.***.***		 0xBC, 0xDD, ....
	<A><B ><C ><D ><E...
The corresponding values in table 2 would be:
	0  (for the A)
	3  (for the B)
	7  (for the C)
	11 (for the D)
	15 (for the E)
	etc.

Some observations:
The pointers in the header seem to count from the beginning of the file.
I found some fonts in which the distances from the baseline are incorrect;
so use the data matrix counts near the end of the header.
It is not clear to which tables bit 2 in the flags applies.
Data that is in Intel (low-high) format on disk, is converted to
M68000 (high-low) format by GDOS during loading.

I am currently working on a mouse-driven FNT-editor annex
(LaTeX-)PXL to FNT converter. When it is finished I will post
it to the binaries newsgroup.

		Jeroen Fokker
		dept of computer science
		university of Utrecht
		PO box 80.089, Utrecht
		the Netherlands
		jeroen@cs.ruu.nl / ...!hp4nl!ruuinf!jeroen