Fonts & Character Sets ⇒ pifont displays incorrect dingbat

[Linguist]

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

Code: Select all

\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

[localghost]

I can't spot a difference in my viewer (Okular).


Thorsten

[Linguist]

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?
Thanks for your help!

[Johannes_B]

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.

[localghost]

[…] 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).

[…] 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).

Code: Select all

\usepackage[T1]{fontenc}

It can't do any harm to use this in general. But this is no guarantee for a successful conversion.

[…] 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.

[Linguist]

Did you try any other symbols?

Thanks for you reply.

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)

Code: Select all

\begin{tabular}{|rr|rr|rr|rr|rr|rr|rr|rr|} \hline
32&\ding{32}&33&\ding{33}&34&\ding{34}&35&\ding{35}&36&\ding{36}&37&\ding{37}&38&\ding{38}&39&\ding{39} \\ \hline
40&\ding{40}&41&\ding{41}&42&\ding{42}&43&\ding{43}&44&\ding{44}&45&\ding{45}&46&\ding{46}&47&\ding{47} \\ \hline
48&\ding{48}&49&\ding{49}&50&\ding{50}&51&\ding{51}&52&\ding{52}&53&\ding{53}&54&\ding{54}&55&\ding{55} \\ \hline
56&\ding{56}&57&\ding{57}&58&\ding{58}&59&\ding{59}&60&\ding{60}&61&\ding{61}&62&\ding{62}&63&\ding{63} \\ \hline
64&\ding{64}&65&\ding{65}&66&\ding{66}&67&\ding{67}&68&\ding{68}&69&\ding{69}&70&\ding{70}&71&\ding{71} \\ \hline
72&\ding{72}&73&\ding{73}&74&\ding{74}&75&\ding{75}&76&\ding{76}&77&\ding{77}&78&\ding{78}&79&\ding{79} \\ \hline
80&\ding{80}&81&\ding{81}&82&\ding{82}&83&\ding{83}&84&\ding{84}&85&\ding{85}&86&\ding{86}&87&\ding{87} \\ \hline
88&\ding{88}&89&\ding{89}&90&\ding{90}&91&\ding{91}&92&\ding{92}&93&\ding{93}&94&\ding{94}&95&\ding{95} \\ \hline
96&\ding{96}&97&\ding{97}&98&\ding{98}&99&\ding{99}&100&\ding{100}&101&\ding{101}&102&\ding{102}&103&\ding{103} \\ \hline
104&\ding{104}&105&\ding{105}&106&\ding{106}&107&\ding{107}&108&\ding{108}&109&\ding{109}&110&\ding{110}&111&\ding{111} \\ \hline
112&\ding{112}&113&\ding{113}&114&\ding{114}&115&\ding{115}&116&\ding{116}&117&\ding{117}&118&\ding{118}&119&\ding{119} \\ \hline
120&\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} \\ \hline
168&\ding{168}&169&\ding{169}&170&\ding{170}&171&\ding{171}&172&\ding{172}&173&\ding{173}&174&\ding{174}&175&\ding{175} \\ \hline
176&\ding{176}&177&\ding{177}&178&\ding{178}&179&\ding{179}&180&\ding{180}&181&\ding{181}&182&\ding{182}&183&\ding{183} \\ \hline
184&\ding{184}&185&\ding{185}&186&\ding{186}&187&\ding{187}&188&\ding{188}&189&\ding{189}&190&\ding{190}&191&\ding{191} \\ \hline
192&\ding{192}&193&\ding{193}&194&\ding{194}&195&\ding{195}&196&\ding{196}&197&\ding{197}&198&\ding{198}&199&\ding{199} \\ \hline
200&\ding{200}&201&\ding{201}&202&\ding{202}&203&\ding{203}&204&\ding{204}&205&\ding{205}&206&\ding{206}&207&\ding{207} \\ \hline
208&\ding{208}&209&\ding{209}&210&\ding{210}&211&\ding{211}&212&\ding{212}&213&\ding{213}&214&\ding{214}&215&\ding{215} \\ \hline
216&\ding{216}&217&\ding{217}&218&\ding{218}&219&\ding{219}&220&\ding{220}&221&\ding{221}&222&\ding{222}&223&\ding{223} \\ \hline
224&\ding{224}&225&\ding{225}&226&\ding{226}&227&\ding{227}&228&\ding{228}&229&\ding{229}&230&\ding{230}&231&\ding{231} \\ \hline
232&\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} \\ \hline
248&\ding{248}&249&\ding{249}&250&\ding{250}&251&\ding{251}&252&\ding{252}&253&\ding{253}&254&\ding{254}&& \\ \hline
\end{tabular}

[Linguist]

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

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]

[…] 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.

[…] 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.

[…] 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.

Code: Select all

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

[Linguist]

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

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

Code: Select all

$ 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  0
SDXKYB+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  0
ZapfDingbats                         Type 1            ZapfDingbats     no  no  no       8  0