Reference information on CreateScalableFontResource

[Dmitry Timoshkov]

"Jeremy White" <jwhite at 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.

-- 
Dmitry.