All the info is in that thread.
As I said there, those two fonts need to be prepended, instead of
appended for test test pdf to be correctly displayed.
(OK, for that pdf, only Dingbats are needed, but it's better to do it
for both fonts at the same time)
This simply follows the advice given on http://freedesktop.org/wiki/Software/poppler.
Could you attach test pdf here? Probably this change should be done in line with gnu-gs-fonts-std fonts deprecation (or whatever will happen with them).
Created attachment 218557 [details]
It's a bit hard to tell if that bug is related, however
it seems unlikely, as it was not a matter of missing fonts,
but wrong matching order.
While I didn't have urw-fonts, original reported did
and both of us could reproduce the bug.
As I said in the thread, default fontconfig setting for those two is
append, while poppler needs prepend, otherwise vera gets selected.
The fix is simple and easy - just apply 30-urw-aliases.patch from
nice patch. i bet it would look even nicer upstream.
also related: bug #282151
(In reply to comment #5)
> i bet it would look even nicer upstream.
That would be far too sensible for an open-source project. They'd rather just put a notice on their wiki, then forget about it (??!). See:
If you're gonna improve the fontconfig rules, I suggest mine:
I think that meant *fontconfig* upstream,
as your patch suggests a possible typo in default rules.
Cause right above the new rule, is the old one that differs
only with a space in the font name.
(In reply to comment #8)
> I think that meant *fontconfig* upstream
Yes, this is a *fontconfig* issue. It is not poppler's job to choose the font - it is fontconfig's job. This is why the correct, easily-checkable and easy-to-apply fix is to change fontconfig's config files ;)
> possible typo in default rules.
Not AFAIK. There are different ways of specifying the "same" font, especially e.g. the TrueType vs Postscript variants.
(In reply to comment #9)
> Yes, this is a *fontconfig* issue. It is not poppler's job to choose the font -
> it is fontconfig's job. This is why the correct, easily-checkable and
> easy-to-apply fix is to change fontconfig's config files ;)
which is why this should go upstream to fontconfig...
The patch is already upstream, where they are sitting on it and pondering whitespace:
thanks for tracking that down. i'll add the patch next chance i get.
fixed in 2.8.0-r1.
*** Bug 360735 has been marked as a duplicate of this bug. ***