[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 #26 from suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp> 2012-04-26 05:27:40 PDT ---
(In reply to comment #25)
> (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.

Excuse me, do you think "lookup GS_LIB in the system registry is bad idea",
OR "lookup the gsfont directory by pathname juggling is bad idea"? Both
are bad ideas?

Anyway, I was going to ask Stefan about the frequency of the situation that
gsfonts are installed in the gs- or Unix-like directory structure, without
gs itself (the original proposal was lookup share/fonts/type1/gsfonts.

> 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.

Yes, yes, yes. I'm doing some experiments.
https://www.codeblog.org/blog/mpsuzuki/20120416.html
Although getting the font file images via GDI is not so simple
(CreateFont() does not bring us to there, more hooks are needed),
it would be better than the juggling of pathname & familynames.
However, the stabilization of the font detection by using GDI
features would spend more time.

> 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.

Indeed.

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