Bug 18002 - character "q" instead of circle
Summary: character "q" instead of circle
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: low minor
Assignee: poppler-bugs
QA Contact:
: 21395 (view as bug list)
Depends on:
Reported: 2008-10-10 05:50 UTC by Thomas Zumbrunn
Modified: 2010-03-20 08:47 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

plot symbols used by R 2.7.2 (r-project.org) (5.59 KB, application/pdf)
2008-10-10 05:50 UTC, Thomas Zumbrunn
plot symbols used by R 2.7.2 (r-project.org), correct rendering (14.11 KB, image/png)
2008-10-10 05:51 UTC, Thomas Zumbrunn

Description Thomas Zumbrunn 2008-10-10 05:50:18 UTC
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.
Comment 1 Thomas Zumbrunn 2008-10-10 05:51:23 UTC
Created attachment 19561 [details]
plot symbols used by R 2.7.2 (r-project.org), correct rendering
Comment 2 Albert Astals Cid 2008-10-10 08:52:59 UTC
Works for me, which poppler version are you using? Any chance you can update to 0.10.0?
Comment 3 Thomas Zumbrunn 2008-10-10 23:55:59 UTC
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".

Comment 4 Albert Astals Cid 2008-10-11 04:25:41 UTC
Which freetype version are you using?
Comment 5 Thomas Zumbrunn 2008-10-11 09:34:37 UTC
freetype 2.3.5-18.2
Comment 6 Albert Astals Cid 2008-10-11 11:01:17 UTC
Strange, the same than here.

Do you have the poppler-data package installed?
Comment 7 Thomas Zumbrunn 2008-10-11 12:58:45 UTC
Yes, I have.

Could you suggest a fool-proof way of testing libpoppler which makes sure I use to correct library versions?
Comment 8 James Cloos 2008-10-11 16:22:04 UTC
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>

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

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
Comment 9 Albert Astals Cid 2008-10-12 04:48:24 UTC
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.

Comment 10 Albert Astals Cid 2008-10-12 04:49:21 UTC
Just for the record we already suggest this fontconfig configuration at http://freedesktop.org/wiki/Software/poppler
Comment 11 James Cloos 2008-10-12 11:09:25 UTC
> you should bug your distribution to improve their fontconfig rules.

The config is from upstream; the rfe should be submitted there.
Comment 12 Thomas Zumbrunn 2008-10-13 01:10:04 UTC
Changed the fontconfig rules helped indeed. Thanks a lot for tracking this down. I've reported the issue in the openSUSE bug database.
Comment 13 Albert Astals Cid 2009-04-26 13:30:33 UTC
*** 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.