Geek Answers Handbook

Change the built-in TrueType font so that it can be used by Windows GDI

I am trying to transfer PDF content to the context of a GDI device (more precisely, a 24-bit bitmap). Parsing a PDF stream into PDF objects and rendering PDF commands from a content dictionary works well, including font rendering.

Embedded fonts are unpacked from FontFile streams and "loaded" using AddFontMemResourceEx . Now some inline fonts delete some TrueType tables that GDI needs, such as the "name" table. Because of this, I tried to change the font by analyzing the font of the subset of TrueType in its tables and changing those tables in which the missing / missing data tables are regenerated with the maximum possible information.

I use the Microsoft Font Validator tool to see how the “correct” font is created. I am still getting a few errors, for example, for the maxp table, the maximum values ​​are usually too large (this is a subset), or the xAvgCharWidth field xAvgCharWidth not equal to the calculated value of the "OS / 2" table, but this is incorrect, but this does not stop the use of other built-in fonts. Fonts embedded with PDFCreator are problematic.

Questions:

  • How can I determine that I need to go to the font file in order for GDI to be able to use it?
  • Are there any other font checking tools that can give me insight into what is still wrong with fontfile?

If necessary: ​​I can create a source font file and a modified font file that can be downloaded anywhere.

What changes have been made so far:

  • Make sure there is a section called "head", "hhea", "maxp" and "OS / 2".
  • If we have a character font, clear the Panose and Unicode fields in the "OS / 2" section
  • Fill in the correct values ​​for WInAscent / Desc and TypoAsc / Desc if they are zero.
  • Fill in the valid values ​​for the positions and sizes of the super / substring / underline.
  • Scan all the glyphs that are left, fill in the minimum / maximum X / Y values ​​in the head.
  • Rebuild the name section with information from the PDF file from which it came.
+6
pdf embedded-fonts true-type-fonts gdi
source share
2 answers

Almost a year late, but I found the answer:

The font type (character or not) must be the same for the cmap table and the name table. Therefore, if cmap has 3.0.4 cmap (MS, character, delta coding of the segment), and the name table contains entries in 3.1, $ 0409 (MS, Unicode, enUS), the font does not load.

It appears that the presence of the cmap character determines whether the font is a Windows character font; flags in OS / 2 do not seem important.

So, if the font seems correct with the "Microsoft Font Validator", check if the character / unicode fields in the "cmap" and "name" tables match.

+3
source share

With AddMemoryFont in GDI +, you can check its Status for any errors in the memory font, such as NotTrueTypeFont .

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

By eliminating all this, you had the opportunity to view the PDFCreator source code (provided that you use open source as opposed to commercial)?

+3
source share

More articles:


All Articles