Noncompliance with Standard-14 fonts requirement in PDF specs
Submitted by Stefan Löffler
Assigned to poppler-bugs
Description
Created attachment 60413 Patch for handling of Standard-14 fonts on Windows
According to the PDF specs, every PDF viewer must be able to handle 14 standard fonts even if they are not embedded. On Windows, poppler does not supply suitable substitution fonts for Symbol and ZapfDingbats. "symbol.ttf" could be a fallback, but has a quite different appearance from the type1 font Symbol and has some missing/different glyphs (e.g., for the letters 'f', 'j', 'v'). ZapfDingbats is totally different from "wingding.ttf".
GlobalParams::setupBaseFonts(char * dir) [poppler/GlobalParamsWin.cc] does support passing a custom directory to it, but it is only called once without custom directory by GlobalParams::getDisplayFont(GfxFont *font) [poppler/GlobalParamsWin.cc].
In addition, if one manually changes the directory passed to setupBaseFonts(), the application crashes because it tries to access a NULL pointer.
Attached is a series of patches with the following changes:
- Remove "wingding.ttf" as it's not a suitable replacement. For a testcase pdf file, see http://texworks.googlecode.com/svn/trunk/testcases/base14-fonts.pdf and the expected output at http://texworks.googlecode.com/svn/trunk/testcases/base14-fonts.png)
- Fix the crash when supplying a custom directory to setupBaseFonts() by checking for valid paths
- Provide the directory "share/fonts/type1/gsfonts" relative to the library/application to setupBaseFonts() by default. Ideally, this should probably be encapsulated into a configuration variable similar to POPPLER_DATADIR, but I don't know the poppler sources well enough to code that.
Patch 60413, "Patch for handling of Standard-14 fonts on Windows":
win32-font-handling.patch