-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows: still font problems #194
Comments
Actually, this is not true. In March, I updated poppler to version 0.52.0. This is not yet online - since nothing changed in dspdfviewer, I did not make a new release. The symbols are not rendered correctly even with this version. Hence, the problem is really related to the way poppler works in Windows. |
That's interesting... And it's also interesting that all other viewers I have tested on Windows show the \Omega correctly. I have now tried to embed the fonts using gs and still it does not seem to work - what would I need to install on my Windows-machine to be able to compile dspdfviewer from the source code? The only reliable way on my system which I have currently identified is to convert the eps-files with gs using the -dNoOutputFonts option, rendering all text as vectors... |
For you to verify that indeed the problem is still present in the newest poppler version, I added a new release which has "just" updated third-party components. |
WOW and thank you very much! |
There are still font problems with the current 1.15.1 build version. These are caused by the poppler 0.43 libraries used in the pre-build binaries.
I have just built dspdfviewer on Linux Mint 17.3 using poppler 0.44 and the \Omega sign is correctly displayed using dspdfviewer on the attached example document.
The PDF was created using XeTeX, beamer and including an eps-file created with XCircuit.
Is it possible to provide a new pre-built Windows binary using a more recent poppler library than 0.43?
poppler_mwe.pdf
The text was updated successfully, but these errors were encountered: