Created attachment 19560 [details] plot symbols used by R 2.7.2 (r-project.org) Plot symbols used by R (http://www.r-project.org/) are properly rendered with exception of the circle, where a "q" character is displayed instead. I attache two files: 1. symbols.pdf PDF output of a simple R graph 2. symbols.png PNG output of the same R graph The symbols in the PDF file should look like in the PNG file.
Created attachment 19561 [details] plot symbols used by R 2.7.2 (r-project.org), correct rendering
Works for me, which poppler version are you using? Any chance you can update to 0.10.0?
My version of Okular (Version 0.7.2, KDE 4.1.2) says the following about the backend: PDF Backend Version 0.1.1 Using KDE 4.1.2 (KDE 4.1.2) "release 44.2" I have several versions of libpoppler installed, however I don't know which one is used by Okular. I compiled version 0.10.0 of libpoppler from source and checked the document "symbols.pdf" with the poppler_qt4viewer demo application. Still the same, circles are shown as "q".
Which freetype version are you using?
freetype 2.3.5-18.2
Strange, the same than here. Do you have the poppler-data package installed?
Yes, I have. Could you suggest a fool-proof way of testing libpoppler which makes sure I use to correct library versions?
I can verify the bug using git master poppler and xpdf/poppler. And that it does not occur with upstream xpdf-302. Of note: :; pdffonts attachment_19560.pdf name type emb sub uni object ID ------------------------------------ ----------------- --- --- --- --------- ZapfDingbats Type 1 no no no 5 0 Helvetica Type 1 no no no 10 0 and lsof(8) shows that xpdf/poppler loads only my prefered font for the Sans alias and Nimbus Sans for Helvetica. (Although I would have expected it to load Arial....) For me, the latter is related to this difference: :; fc-match 'ZapfDingbats' LucidaSansRegular.ttf: "Lucida Sans" "Regular" :; fc-match 'Zapf Dingbats' Dingbats.ttf: "Dingbats" "Regular" The latter is due to this code in /etc/fonts/conf.d/30-urw-aliases.conf: <alias binding="same"> <family>Zapf Dingbats</family> <accept><family>Dingbats</family></accept> </alias> Something of that sort is probably also the case for the OP. I just added this similar snippit to my ~/.fonts.conf: <alias binding="same"> <family>ZapfDingbats</family> <accept><family>Dingbats</family></accept> </alias> and pdf/poppler started rendering the pdf correctly. It still seems odd that it displays a 'q'. The solid circle in the Dingbats encoding is at 0x6C, the same spot as 'l' in ASCII. And in fact the PDF has many occurances of the form of: /F1 1 Tf 1 Tr 9.97 0 0 9.97 71.38 78.65 Tm (l) Tj 0 Tr all setting the string (l) in ZapfDingbats. Somehow poppler is converting that to a 'q'.... There is no /Encoding specified for /F1, just: << /Type /Font /Subtype /Type1 /Name /F1 /BaseFont /ZapfDingbats >> And I see that R uses the Tr operator to choose filled vs open circles. So why 'q' instead of 'l'??? (Interestingly, selecting a circle in the xpdf-302 window and pasting to a terminal pastes a 'q', not an 'l', even though xpdf-302 renders the circle from Dingbats. Acroread will only dump core for me since I last upgraded it, so I can’t compare what it sends when doing copy/ paste of the circles.) The PDF uses Helvetica only for the x, y and digits on the axes, the ZapfDingbats only for the circle. Everything else is done with stroked and/or filled lines and curves. I also see a difference between the pdf and png at x=5,y=3. The PDF shows a WHITE UP-POINTING TRIANGLE in a COMBINING ENCLOSING SQUARE whereas the png has a WHITE DOWN-POINTING TRIANGLE in the COMBINING ENCLOSING SQUARE.
Once James has demonstrated this is a shortcoming of your fontconfig configuration i'm all for closing the bug, you should bug your distribution to improve their fontconfig rules. Agreed?
Just for the record we already suggest this fontconfig configuration at http://freedesktop.org/wiki/Software/poppler
> you should bug your distribution to improve their fontconfig rules. The config is from upstream; the rfe should be submitted there.
Changed the fontconfig rules helped indeed. Thanks a lot for tracking this down. I've reported the issue in the openSUSE bug database.
*** Bug 21395 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.