[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 #6 from Stefan Löffler <st.loeffler at gmail.com> 2012-04-23 02:05:51 PDT ---
Thanks for your insights. I'm not a font expert myself, but have seen some
reports for TeXworks (which uses poppler) that the Symbol font is rendered
incorrectly on Windows. As a test-case, you could use
http://texworks.googlecode.com/svn/trunk/testcases/base14-fonts.pdf (which
references all 14 standard fonts). What I did there was to simply render text
(hence my mentioning the characters that produce problems).

Regarding the patch:
I modeled the function looking for the font directory after
get_poppler_datadir() in poppler/GlobalParams.cc which does very much the same
thing for locating the poppler-data directory. It does not depend specifically
on ghostscript - I only chose the folder name to correspond to the *nix name
(as get_poppler_datadir() does), but it is rather arbitrary. Fonts could be
taken from ghostscript or other sources (e.g.,
http://www.ctan.org/tex-archive/fonts/urw/base35). All this patch does is
provide an additional directory to search for fonts.

bin/ is only stripped if it exists, as is done in get_poppler_datadir().

Regarding co-using ghostscript: if ghostscript fonts are installed in the
Windows system directory, they should be picked up by poppler automatically, I
assume. Being able to re-use the fonts in an existing ghostscript installation
(that does not touch the system directory) would be nice, but is not what this
patch is intended for. It is intended for an application using poppler to be
standard-compliant even if ghostscript is not installed (which is kind of the
point of a pdf viewer, IMO, to not depend on essentially another viewer).
BTW: using an existing ghostscript installation would only work reliably if (a)
the application using poppler bundles ghostscript or (b) the user build the
application himself. Otherwise, there is no guarantee if and where ghostscript
may be installed.

Exposing the path to the configure script is probably a good idea.

PS: I'm using MinGW myself.

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