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

With AddMemoryFont in GDI+ you can check it's Status for any errors in the memory font, like NotTrueTypeFont for example.

One option for GDI may be to try to load the embedded font into a document/form yourself with TTLoadEmbeddedFont and then check any errors returned from the error messages. The only functions that supply more information than this one are CreateFontPackage/MergeFontPackage, and their error codes, but I do fail to see how they can be used in your situation.

Barring all this, have you had a chance to review PDFCreator's source code (assuming you're using the open source one as opposed to the commercial one)?