## LaTeX forum ⇒ Fonts & Character Sets ⇒ pifont displays incorrect dingbat

Information and discussion about fonts and character sets (e.g. how to use language specific characters)
Linguist
Posts: 39
Joined: Mon Nov 07, 2011 12:07 pm

### pifont displays incorrect dingbat

Hello,

I have a Miktex distribution and my editor is TeXnicCenter.

When I compile the given code using TeXnicCenter's "LaTeX => PDF" option, everything displays as expected.

However, when I compile the code using TeXnicCenter's "LaTeX => PS => PDF" option, the pifont dingbats produced are different to expected. i.e. \ding{43} (a pointing hand) has no sleeve.

I've provided a MWE, but as I suspect the problem is in my LaTeX setup somewhere, I'm not sure how replicable it will be. I've also attached the two different output PDF files; "incorrect.pdf" is the result of selecting "LaTeX => PS => PDF" "correct.pdf" is the result of selecting "LaTeX => PDF".

\documentclass{report}\usepackage{pifont}\begin{document}\ding{43}\end{document}

Any pointers to where the source of the problem might lie are welcome. If more information on my setup is required, please ask.

Thanks
Attachments
incorrect.pdf
LaTeX => PS => PDF
correct.pdf
LaTeX => PDF

Tags:

localghost
Site Moderator
Posts: 9204
Joined: Fri Feb 02, 2007 12:06 pm
I can't spot a difference in my viewer (Okular).

Thorsten
LaTeX Community Moderator

¹ System: openSUSE 42.2 (Linux 4.4.52), TeX Live 2016 (vanilla), TeXworks 0.6.1

Linguist
Posts: 39
Joined: Mon Nov 07, 2011 12:07 pm
Hi,

Thanks for replying. Each bit of information moves me closer to a solution.

Do you mean that you can't spot a difference in the PDF files that I attached? If so, I've taken a screenshot of what I see in adobe acrobat at 600% resolution. You should see that the difference between the two characters isn't minor; each appears to be from an entirely different font/character set.

I can also confirm that when I view the .ps file directly, the dingbat displays as expected. (Identically to the attached correct.pdf/correct.jpg).

This indicates to me that the problem lies in the conversion from PS to PDF. I don't fully understand what is involved in this process. I can say, however, that when I select LaTeX => PS => PDF the default is for TeXnicCenter to run a post-processor called "ps2pdf"

Any advice? Perhaps there's another PS => PDF converter I could try?
Attachments
LaTeX => PS => PDF
incorrect.jpg (2.86 KiB) Viewed 13569 times
LaTeX => PDF
correct.jpg (3.19 KiB) Viewed 13569 times

Johannes_B
Site Moderator
Posts: 4163
Joined: Thu Nov 01, 2012 4:08 pm
I just ran your example, and i get your "correct" pointy-hand (including the sleeve) using pdflatex, latex ->[dvipdfmx] pdf, latex ->[dvips] ps ->[ps2pdf] pdf.

Did you try any other symbols?

latex* outputs a dvi-file, which has to be converted to pdf. This can be directly done using dvipdfmx (and others), or via PostScript using for example dvips and later ps2pdf to convert the ps to pdf.

* Internally latex and pdflatex are the same program running in different modes.
The smart way: Calm down and take a deep breath, read posts and provided links attentively, try to understand and ask if necessary.

localghost
Site Moderator
Posts: 9204
Joined: Fri Feb 02, 2007 12:06 pm
Linguist wrote:[…] Do you mean that you can't spot a difference in the PDF files that I attached? If so, I've taken a screenshot of what I see in adobe acrobat at 600% resolution. You should see that the difference between the two characters isn't minor; each appears to be from an entirely different font/character set. […]

I always see the "correct" output. And also after I ran the example with different compiling routes, I always get the correct output. You could compare the output by using another viewer like Sumatra PDF (which is preferable when working with TeXnicCenter).

Linguist wrote:[…] I can also confirm that when I view the .ps file directly, the dingbat displays as expected. (Identically to the attached correct.pdf/correct.jpg). […]

Since the pifont package provides access to Postscript Type 1 fonts (Zapf Dingbats), it could help to enable the correct font encoding by this line (before all font packages).
\usepackage[T1]{fontenc}

It can't do any harm to use this in general. But this is no guarantee for a successful conversion.
Linguist wrote:[…] This indicates to me that the problem lies in the conversion from PS to PDF. I don't fully understand what is involved in this process. I can say, however, that when I select LaTeX => PS => PDF the default is for TeXnicCenter to run a post-processor called "ps2pdf" […]

The relevant converter is Ghostscript. And I'm not aware of any other PS-to-PDF converter. Which version of Ghostscript do you have installed? If you don't have the latest version (9.07), think about doing an update.
LaTeX Community Moderator

¹ System: openSUSE 42.2 (Linux 4.4.52), TeX Live 2016 (vanilla), TeXworks 0.6.1

Linguist
Posts: 39
Joined: Mon Nov 07, 2011 12:07 pm
Johannes_B wrote:Did you try any other symbols?

I followed your advice, and tried the full symbol set. All display erroneously in Adobe Reader when I've built the file by selecting TeXnicCenter's LaTeX => PS => PDF option.

The symbols, are similar but not identical. Compare the attached chart to the one in the psnfss documentation at http://www.ctan.org/pkg/pifont.

I'll also give the code for the complete set of pifont dingbats, while I'm here. (I couldn't find it anywhere online, and others might find it useful)

\begin{tabular}{|rr|rr|rr|rr|rr|rr|rr|rr|} \hline32&\ding{32}&33&\ding{33}&34&\ding{34}&35&\ding{35}&36&\ding{36}&37&\ding{37}&38&\ding{38}&39&\ding{39} \\ \hline40&\ding{40}&41&\ding{41}&42&\ding{42}&43&\ding{43}&44&\ding{44}&45&\ding{45}&46&\ding{46}&47&\ding{47} \\ \hline48&\ding{48}&49&\ding{49}&50&\ding{50}&51&\ding{51}&52&\ding{52}&53&\ding{53}&54&\ding{54}&55&\ding{55} \\ \hline56&\ding{56}&57&\ding{57}&58&\ding{58}&59&\ding{59}&60&\ding{60}&61&\ding{61}&62&\ding{62}&63&\ding{63} \\ \hline64&\ding{64}&65&\ding{65}&66&\ding{66}&67&\ding{67}&68&\ding{68}&69&\ding{69}&70&\ding{70}&71&\ding{71} \\ \hline72&\ding{72}&73&\ding{73}&74&\ding{74}&75&\ding{75}&76&\ding{76}&77&\ding{77}&78&\ding{78}&79&\ding{79} \\ \hline80&\ding{80}&81&\ding{81}&82&\ding{82}&83&\ding{83}&84&\ding{84}&85&\ding{85}&86&\ding{86}&87&\ding{87} \\ \hline88&\ding{88}&89&\ding{89}&90&\ding{90}&91&\ding{91}&92&\ding{92}&93&\ding{93}&94&\ding{94}&95&\ding{95} \\ \hline96&\ding{96}&97&\ding{97}&98&\ding{98}&99&\ding{99}&100&\ding{100}&101&\ding{101}&102&\ding{102}&103&\ding{103} \\ \hline104&\ding{104}&105&\ding{105}&106&\ding{106}&107&\ding{107}&108&\ding{108}&109&\ding{109}&110&\ding{110}&111&\ding{111} \\ \hline112&\ding{112}&113&\ding{113}&114&\ding{114}&115&\ding{115}&116&\ding{116}&117&\ding{117}&118&\ding{118}&119&\ding{119} \\ \hline120&\ding{120}&121&\ding{121}&122&\ding{122}&123&\ding{123}&124&\ding{124}&125&\ding{125}&126&\ding{126}&& \\ \hline&&161&\ding{161}&162&\ding{162}&163&\ding{163}&164&\ding{164}&165&\ding{165}&166&\ding{166}&167&\ding{167} \\ \hline168&\ding{168}&169&\ding{169}&170&\ding{170}&171&\ding{171}&172&\ding{172}&173&\ding{173}&174&\ding{174}&175&\ding{175} \\ \hline176&\ding{176}&177&\ding{177}&178&\ding{178}&179&\ding{179}&180&\ding{180}&181&\ding{181}&182&\ding{182}&183&\ding{183} \\ \hline184&\ding{184}&185&\ding{185}&186&\ding{186}&187&\ding{187}&188&\ding{188}&189&\ding{189}&190&\ding{190}&191&\ding{191} \\ \hline192&\ding{192}&193&\ding{193}&194&\ding{194}&195&\ding{195}&196&\ding{196}&197&\ding{197}&198&\ding{198}&199&\ding{199} \\ \hline200&\ding{200}&201&\ding{201}&202&\ding{202}&203&\ding{203}&204&\ding{204}&205&\ding{205}&206&\ding{206}&207&\ding{207} \\ \hline208&\ding{208}&209&\ding{209}&210&\ding{210}&211&\ding{211}&212&\ding{212}&213&\ding{213}&214&\ding{214}&215&\ding{215} \\ \hline216&\ding{216}&217&\ding{217}&218&\ding{218}&219&\ding{219}&220&\ding{220}&221&\ding{221}&222&\ding{222}&223&\ding{223} \\ \hline224&\ding{224}&225&\ding{225}&226&\ding{226}&227&\ding{227}&228&\ding{228}&229&\ding{229}&230&\ding{230}&231&\ding{231} \\ \hline232&\ding{232}&233&\ding{233}&234&\ding{234}&235&\ding{235}&236&\ding{236}&237&\ding{237}&238&\ding{238}&239&\ding{239} \\ \hline&&241&\ding{241}&242&\ding{242}&243&\ding{243}&244&\ding{244}&245&\ding{245}&246&\ding{246}&247&\ding{247} \\ \hline248&\ding{248}&249&\ding{249}&250&\ding{250}&251&\ding{251}&252&\ding{252}&253&\ding{253}&254&\ding{254}&& \\ \hline\end{tabular}
Attachments
Erroneous dingbats (LaTeX => PS => PDF)
Dingbats.jpg (297.2 KiB) Viewed 13552 times

Linguist
Posts: 39
Joined: Mon Nov 07, 2011 12:07 pm
localghost wrote: I always see the "correct" output. And also after I ran the example with different compiling routes, I always get the correct output. You could compare the output by using another viewer like Sumatra PDF (which is preferable when working with TeXnicCenter).

Thanks for putting me onto Sumatra PDF. When I view the output using this, I also see the "correct" output. So this looks like my problem is with Adobe Reader.

More relevant information: when I view properties in Adobe Reader for the ('correct') PDF built from LaTeX => PDF the (relevant) font specification is given as:

Dingbats (Embedded Subset)
Type: Type 1
Encoding: Built-in

But when I view the properties in the ('incorrect') PDF built from LaTeX => PS => PDF the font specification is given as:

ZapfDingbats
Type: Type 1
Encoding: Built-in
Actual Font Type: Type 1

So, if I understand that info' correctly, it looks like the fonts aren't exactly the same. This explains why the entire set of dingbats is 'similar' but not identical; they're drawing on different character sets. I don't know why Adobe Reader sees/uses different fonts for the process LaTeX => PS => PDF and LaTeX => PDF, but it looks like it does. Weird.

localghost wrote:The relevant converter is Ghostscript. And I'm not aware of any other PS-to-PDF converter. Which version of Ghostscript do you have installed? If you don't have the latest version (9.07), think about doing an update.

As far as I can see, I don't have the most recent version. I'm not ashamed to admit that I'm no computer wiz, and I don't really know how to upgrade it and have it 'talk' to the rest of my LaTeX setup. (As an aside, I've got MiKTeX 2.8 and it looks like there's a newer distribution, 2.9, out so maybe I need to upgrade the whole thing?)

Thanks for your(pl.) help! You've helped me identify the source of the problem: Adobe Reader (grr...) The issue isn't completely solved yet; I still don't know why Adobe Reader finds the right character set if I go LaTeX => PDF but finds the wrong one if I go LaTeX => PS => PDF. But we're getting there. Maybe I'll need to ask elsewhere to find an answer to that question.

localghost
Site Moderator
Posts: 9204
Joined: Fri Feb 02, 2007 12:06 pm
Linguist wrote:[…] So, if I understand that info' correctly, it looks like the fonts aren't exactly the same. This explains why the entire set of dingbats is 'similar' but not identical; they're drawing on different character sets. I don't know why Adobe Reader sees/uses different fonts for the process LaTeX => PS => PDF and LaTeX => PDF, but it looks like it does. Weird. […]

It looks to me that the Ad0be Reader (AR) simply prefers the font from its manufacturer. But I have no idea why it doesn't use the embedded font. This is perhaps an issue for the Ad0be forum. I would be interested in the result of this discussion. Finally it would shed light on this issue for users of LaTeX.

Linguist wrote:[…] As far as I can see, I don't have the most recent version. I'm not ashamed to admit that I'm no computer wiz, and I don't really know how to upgrade it and have it 'talk' to the rest of my LaTeX setup. (As an aside, I've got MiKTeX 2.8 and it looks like there's a newer distribution, 2.9, out so maybe I need to upgrade the whole thing?) […]

Regarding Ghostscript, you just need to uninstall the old version and install the new one. Unfortunately there is no built-in upgrade routine. The same applies to MiKTeX. The old version 2.8 has reached its end of life about three months ago. It will not allow you to update packages by the package manager because repositories are closed for this version. Hence an update to version 2.9 is strongly recommendable.

Linguist wrote:[…] The issue isn't completely solved yet; I still don't know why Adobe Reader finds the right character set if I go LaTeX => PDF but finds the wrong one if I go LaTeX => PS => PDF. But we're getting there. Maybe I'll need to ask elsewhere to find an answer to that question.

See my assumption above regarding the fonts that the AR seemingly prefers. But we can do a final check. Consider the following example. It creates a font table of the Zapf Dingbats symbols.
\documentclass[12pt]{article}\usepackage[T1]{fontenc}\usepackage{fonttable} \begin{document}   \fonttable{pzdr}\end{document}

I have created three files which you should process as described. Find them in the attachment.

• "pifont.ps": The above example processed with LaTeX and converted to PS by dvips. Convert this as usual to PDF (ps2pdf) on your machine and view the output.
• "pifont-PS-PDF.pdf": The above example code compiled LaTeX→DVI→PS→PDF. View the output on your machine.
• "pifont-PDF.pdf": The above example directly compiled with PDFLaTeX. View the output on your machine (should be "correct").

My assumption is that "pifont.ps" will show the undesired behaviour after conversion to PDF when viewed with the AR.
Attachments
pifont.ps
The given example compiled LaTeX→DVI→PS
pifont-PS-PDF.pdf
The given example compiled LaTeX→DVI→PS→PDF
pifont-PDF.pdf
The given example compiled PDFLaTeX→PDF
LaTeX Community Moderator

¹ System: openSUSE 42.2 (Linux 4.4.52), TeX Live 2016 (vanilla), TeXworks 0.6.1

Linguist
Posts: 39
Joined: Mon Nov 07, 2011 12:07 pm
• "pifont-PS-PDF.pdf": The above example code compiled LaTeX→DVI→PS→PDF. View the output on your machine.
• "pifont-PDF.pdf": The above example directly compiled with PDFLaTeX. View the output on your machine (should be "correct").

Both of these displayed the "correct" dingbats in Adobe Reader on my machine.

"pifont.ps": The above example processed with LaTeX and converted to PS by dvips. Convert this as usual to PDF (ps2pdf) on your machine and view the output.
My assumption is that "pifont.ps" will show the undesired behaviour after conversion to PDF when viewed with the AR.

Well, the mystery deepens.
I converted your attached pifont.ps file (dragged and dropped it onto ps2pdf), then viewed the output PDF in Adobe Reader and the "correct" dingbats are displayed. (Yay!)

So, then I tried replicating the process exactly. I opened TeXnicCenter, copied the code you supplied then selected TeXnicCenter's "LaTeX => PS" option, saved the file (even with the same name; pifont), built the file, then manually converted it to PDF (drag-and-drop), opened the file in Adobe Reader and... the "incorrect" dingbats are displayed. (Huh?)

I tried this a few times with different files, and I always see the "incorrect" dingbats in Adobe Reader. So then I upgraded both my MiKTeX distribution to version 2.9 and upgraded my version of TeXnicCenter to the most recent stable release, and tried again. Still no luck.

I should add that when I view the properties of the PDF (with "correct" dingbats) made from your PS file it tells me the font is:

Dingbats (Embedded Subset)
Type: Type 1
Encoding: Custom

Which is expected, if it's displaying correctly.

Weird, weird, weird.

jcdus
Posts: 1
Joined: Sat Mar 15, 2014 8:57 am
or maybe not that weird... Unlike the «correct» file, the «incorrect» one does not embed the font
ZapfDingbats, which explains why there may be a difference of rendering with some readers, depending on the fonts you've got on your system, e.g. you might have a Dingbats font with a slightly different design of the original from Hermann Zapf which will get picked instead. Moreover the delta on the size of each file, whereas the source is identical, is another clue''...

$ls -sh correct.pdf 12K correct.pdf$ pdffonts correct.pdf name                                 type              encoding         emb sub uni object ID------------------------------------ ----------------- ---------------- --- --- --- ---------ZZVUNW+Dingbats                      Type 1            Builtin          yes yes no       4  0SDXKYB+CMR10                         Type 1            Builtin          yes yes no       5  0$ls -sh incorrect.pdf 4,0K incorrect.pdf$ pdffonts incorrect.pdf name                                 type              encoding         emb sub uni object ID------------------------------------ ----------------- ---------------- --- --- --- ---------OTJKZH+CMR10                         Type 1C           WinAnsi          yes yes no       9  0ZapfDingbats                         Type 1            ZapfDingbats     no  no  no       8  0