"Jeremy White" jwhite@codeweavers.com wrote:
FONTDIR and all related font structures are well described in Windows 3.1 DDK I used to have (and use) 15 years ago. I put some knowledge about it when I was fixing after Huw tools/fnt2fon.c, that's a good piece of knowledge about Windows .fon files.
Where in the DDK? I can't find any place that clearly defines the FONTDIR structure in the 3.11 DDK I am looking at.
If I recall correctly it was in the book devoted to developing printer drivers, around PFM file structure and device font description.
For example, by inspection, I see that the value placed by Windows mostly lines up with the structure we have defined in wine/wingdi16.h. (And you can find that definition of FONTDIR if you google around on the web).
But in the DDK, I find only FONTINFO and other structures; not FONTDIR.
What I really wanted to know was how the tail end of that structure was really mapped out.
That is, if I compare it to the FONTDIR16 structure we have, it seems as though the data written by windows matches pretty well up until dfDefaultChar. At that point, the order is:
BYTE always 0x1 (might be dfDefaultChar, but not clear) BYTE always 0x2 (might be dfBreakChar, but not clear) WORD always 0x0 (might be WidthBytes, but not clear) DWORD always 0x0 (might be dfDevice, but not clear) DWORD always 0x76, which is the location in the struct of the Family name, suggests dfFace is a reasonable name for this field BYTE mystery1 (mostly 0x9, sometimes 0xa, 0xb, or 0x6) BYTE mystery2 always 0 BYTE mystery3 always 0 BYTE mystery4 is sometimes 0xf0, appears to be linked to cases where the firstchar and last char both are in the 0xf0XX range [named dfReserved in the FONTDIR16 struct] BYTE mystery5 always 0xff ZSTRING family name ZSTRING family name (again) ZSTRING style name I'm pretty sure the latter 3 are in a constrained buffer of about 40 bytes; haven't nailed that down just yet.
Last field in the FONDIR structure should be dfBitsOffset, followed by font name. As you can see from fnt2fon.c not the whole FONTINFO16 structure is used, but only 0x72 bytes including dfVersion, dfSize, dfCopyright.
Also, I'd avoid using FreeType directly altogether, and used Win32 APIs instead to load a TTF file and get all required font info from it.