Bug 18002

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