Altering an embedded TrueType font so it will be usable by Windows GDI

Question

I am trying to render PDF content to a GDI device context (a 24bit bitmap to be exact). Parsing the PDF stream into PDF objects and rendering the PDF commands from the content dictionary works well, including font rendering.

Embedded fonts are decompressed from their FontFile streams and "loaded" using AddFontMemResourceEx. Now some embedded fonts remove some TrueType tables that are needed by GDI, like the 'name' table. Because of this, I tried to modify the font by parsing the TrueType subset font into it's tables and modify those tables that have data missing / missing tables are regenerated with as correct information as possible.

I use the Microsoft Font Validator tool to see how "correct" the generated font is. I still get a few errors, like for the maxp table the max values are usually too large (it is a subset) or the xAvgCharWidth field does not equal the calculated value of the 'OS/2' table is not correct but this does not stop other embedded fonts to be useable. The fonts embedded using PDFCreator are the ones that are problematic.

Questions:

1. How can I determine what I need to change to the font file in order for GDI to be able to use it?
2. Are there any other font validation tools that might give me insight into what is still wrong with the fontfile?

If needed: I can make an original fontfile and an altered fontfile available for download somewhere.

What modifications are made so far:

• Make sure there is a 'head', 'hhea', 'maxp' and 'OS/2' section.
• If we have a symbol font, clear out Panose and Unicode fields in the 'OS/2' section
• Fill in correct values for WInAscent/Desc and TypoAsc/Desc if they we're zero.
• Fill in acceptable values for super/subscript/underline positions and sizes.
• Scan all glyphs that are left en fill in X/Y min/max values in head.
• Rebuild the name section with information from the PDF file it came from.

Answer 1

Almost a year late, but I found the answer:

The font kind (symbol or not) should be the same for the 'cmap' table and the 'name' table. So if the cmap has a 3,0,4 cmap (MS, symbol, segment delta coding) and the name table contains 3,1,$0409 (MS, Unicode, enUS) entries, the font will not load.

It looks like the presence of a 'symbol cmap' determines if the font is considered a symbol font by Windows; flags in 'OS/2' don't seem to matter.

So if a font seems correct using 'Microsoft Font Validator', check if the symbol/unicode fields line up in the 'cmap' and 'name' tables.