[Poppler-bugs] [Bug 49037] Noncompliance with Standard-14 fonts requirement in PDF specs

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49037

--- Comment #25 from Adrian Johnson <ajohnson at redneon.com> 2012-04-26 05:09:54 PDT ---
(In reply to comment #23)
> Would also be nice if the fonts could be delivered with the poppler data dir,
> but that's probably a vain wish.

There is nothing stopping anyone providing a windows installer for poppler from
including the ghostscript fonts (http://sourceforge.net/projects/gs-fonts/).
The fonts are GPL.

I think that searching for a ghostscript installation is the wrong approach. It
is bad enough that pdftohtml has a dependency on gs without introducing another
one.

My preferred solution for font substitution on windows is:

1. First check poppler_data_dir/fonts
2. If not found, call CreateFont/CreateFontIndirect/CreateFontIndirectEx.

This allows anyone creating a poppler installer for windows to either install
the gs fonts to poppler_data_dir/fonts to ensure they are the first match for
the standard 14 or to install the fonts to the windows font directory.

The win32 CreateFont function is the windows equivalent of fontconfig. It finds
the font that is the closest match for the specified characteristics. This is
required to support substituting non Standard-14 fonts. Similar to Linux it is
up to the user to ensure either the non standard font is installed or a
substitution is configured in HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\FontSubstitutes.

I'm not sure why the code currently has hard coded font file names that it
searches the system font directory for. It would be better to use the windows
api to find the best matching font and use GetFontData to read the font file.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.