make standard 14 fonts available
I very much like dspdfviewer. However, I have a problem: It does not display certain fonts (e.g. symbol) even though they are amongst the standard 14 fonts. I assume that they are not available in dspdfviewer and the struggle arises as pdfs generated by some programs don't even have the option to include these.
I wonder whether this can be fixed.
I will try to check if I can do something about this, but I will need an example PDF using those fonts un-embedded to reproduce the problem.
Additionally, please include the following information:
- Which version of dspdfviewer are you running?
- What operating system are you using?
Dear Danny,
thanks for the swift response. Attached is a pdf and a screen. The pdf has the letter a in a box which does not display in dspdfviewer.
My platform is Windows 7 and I am using dspdfviewer version 1.15.
Best,
Sven
Symbol Test.pdf
On Debian, this renders with a little small letter alpha inside, so this seems to be a windows specific bug. CCing @projekter -- this may be similar to #163 in the sense that maybe just a file is missing or at the wrong location.
Output on Debian:

I can reproduce the problem in a Windows 7 VM with the latest build.
Some information that may help in finding the missing file:
$ pdffonts Symbol.Test.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
Symbol Type 1 Symbol no no no 7 0
$ pdffonts -subst Symbol.Test.pdf
name object ID substitute font substitute font file
------------------------------------ --------- ------------------------------------ ------------------------------------
Symbol 7 0 Standard Symbols L /usr/share/fonts/type1/gsfonts/s050000l.pfb
This file is part of the gsfonts package, which lists its homepage as http://ghostscript.com.
This time, I don't think there's extra data to provide for poppler and ProcMon does not tell anything about a failed loading attempt. However, I just went to the poppler web site and found a bug regarding the symbol font which was just fixed in the most recent version two weeks ago. And when I run dspdfviewer in debug mode, an error "Couldn't find a font for 'Symbol'" is issued. So there's two things I will try:
- Update poppler
- Since there are lots of Fontconfig errors in debug mode, I will try switching the font management system when compiling the new poppler.
For me, the new release works. I can't tell which of the two things made the difference. Now font handling uses the Win32 mechanism instead of Fontconfig. As a result, all Fontconfig related errors in debug mode are gone, but there are new ones: "No display font for ..." where the fonts are ArialNarrow, HelveticaNarrow and BookAntiqua (in all variants regular, bold, italic and combinations thereof). Those occur in your test document, but since it does not even use these fonts, I can't tell you where the messages are from. I tried some other documents as well: My own LaTeX-created presentations do not give these errors, but the nasty-looking presentation that was given as a test case in the linked poppler bug (which now works) does the same. Perhaps this is something Word related. As long as no-one complains those fonts are actually missing, I tend to ignore the messages.
@projekter: I can confirm this works in my VM too. Thanks!
@Svendergrosse: Please test the new binary installer. If it works now we can close this ticket.
Dear Danny and Benjamin,
thank you for the quick help. Indeed, the alpha does display correctly now. However, there are some characters in Symbol that are displayed incorrectly. I have attached a pdf with the full Greek alphabet and a screenshot highlighting those that come out wrong in dspdfviewer. I wonder whether this is another bug in the module poppler.
Best, Sven
On 15/05/2016 03:42, Danny Edel wrote:
@projekter https://github.com/projekter: I can confirm this works in my VM too. Thanks!
@Svendergrosse https://github.com/Svendergrosse: Please test the new binary installer. If it works now we can close this ticket.
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/dannyedel/dspdfviewer/issues/173#issuecomment-219239418
On 05/15/2016 08:09 AM, Svendergrosse wrote:
I have attached a pdf with the full Greek alphabet and a screenshot highlighting those that come out wrong in dspdfviewer.
Hi Sven,
sadly GitHub's email reply feature feature still does not support attachments, as written in the original announcement in 2011, so your PDF got dropped somewhere along the way : (
Please use the github web interface to attach the PDF.
Thank you,
Danny
I will try to investigate a bit what's happening. But I would rather say this problem is PDF related: I can confirm the wrong letters with your attachment. But then, I embedded all fonts using Acrobat and reopened the PDF and all letters were displayed correctly. Of course the question is why other readers can display it properly.
This is how it's rendered on Debian:

So I suppose this is a windows-specific mis-rendering.
There's a bug from 2014 (!) that mentions these exact symbols:
https://bugs.freedesktop.org/show_bug.cgi?id=76893 - Quoting:
The following symbol characters are not displayed correctly under windows:
- capital delta
- capital omega
- lowercase mu
- lowercase pi
You're right, this must be related to that bug. I have installed Okular on Windows, which uses Poppler and it has exactly the same problems. So, @Svendergrosse, I'm sorry for that but you have to ask the Poppler team do work on it. And meanwhile you can bypass it by embedding your fonts.
Hello!
I just discovered this bug in my upcoming lecture slides. Since poppler in the meantime seems to have gone now from 0.43 to 0.57 I guess there is a chance that this problem is cured.
Is there any chance for a Windows pre-compiled binary based on poppler 0.57?
Yup, there is. But I have to disappoint you that the bug is still present. Embedded fonts are still the best way to ensure everything works.