Skip to content
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

Open
uwezi opened this issue Aug 27, 2017 · 5 comments
Open

Windows: still font problems #194

uwezi opened this issue Aug 27, 2017 · 5 comments

Comments

@uwezi
Copy link

uwezi commented Aug 27, 2017

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

@projekter
Copy link
Contributor

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.
However, when I analyze your PDF with Acrobat, it reports possible Font problems, since the \Omegas are not embedded. If I embed them and then display the PDF, dspdfviewer renders everything correctly.

@uwezi
Copy link
Author

uwezi commented Aug 28, 2017

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

@uwezi
Copy link
Author

uwezi commented Aug 28, 2017

eps2pdf
OK, now I succeeded in embedding the fonts correctly - but only by converting the XCircuit-generated eps-files using eps2pdf with the additional options -dEmbedAllFonts=true -dPDFSETTINGS=/prepress

It was nice that XeTeX automatically could convert end embed eps-files, but I guess I can live with this extra step...

And now I even managed to add these parameters to the configuration file dvipdfmx.cfg ;-)

@projekter
Copy link
Contributor

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.
I also spent the whole day on creating a repository which explains in-depth step-by-step what to do in order to compile dspdfviewer with all dependencies manually on Windows. Have fun.
Which viewers do you mean in particular? E.g. Acrobat, Foxit, Sumatra all use their own way to display the PDF. Okular uses poppler, so if it is display correctly in Okular but not with dspdfviewer, this should give an indication that something is wrong.

@uwezi
Copy link
Author

uwezi commented Aug 30, 2017

WOW and thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants