[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 #7 from thomasf <Thomas.Freitag at alfa.de> 2012-04-23 02:50:52 PDT ---
(In reply to comment #6)
> Thanks for your insights. I'm not a font expert myself, 

Welcome to the club :-)

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

Oh, I missed that: I never used cmake, it was to confusing for me to get it
running togethet with VisualC, therefore I oversee to define
ENABLE_RELOCATABLE. But then You should do it in the same way, i.e. introduce a
POPPLER_FONTDIR and then something like
#undef POPPLER_FONTDIR
#define POPPLER_FONTDIR get_poppler_fontdir ()
And of course get_poppler_fontdir should be bracketed by "#if
ENABLE_RELOCATABLE", too.

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

Yes, I see that, I only ask to remove then "Debug" and "Release", too. Of
course should be also done then in get_poppler_datadir, too.
> 
> 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.

Sorry, but I don't think so: looking for registry key and if find look into
that directory, too, will work in all cases :-). But nevertheless, it was
probably only a kiddy idea...

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

Yes, for MinGW users. On a pure Windows system there is no way to use a
"configure" script. When I started with poppler, I used MinGW, too, but in some
way it breaks my Visual C compilations, as far as I remember, therefore I
removed it and create my project files for Visual C manually..

> 
> PS: I'm using MinGW myself.

I guessed that already :-)

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