Bug 1037882

This may not be an evince issue as okular also exhibits the same failure.

What I find "strange" is that using the Gnome Character Map utility the ∆ is displayed correctly even when the Symbol Neu font is selected.

xpdf and acroread (from Adobe) do not fail.

lsof shows xpdf using

/usr/share/fonts/default/Type1/s050000l.pfb   and /usr/share/fonts/default/Type1/n021003l.pfb

While acroread appears to be using only  /usr/share/fonts/dejavu/DejaVuSans.ttf

Selecting Symbol Neu font in LibreOffice Word and typing ∆ results in an empty square being displayed.  This would seem to indicate that Symbol Neu doesn't have the glyph for U+2206 and somehow there is a problem when a substitute font is chosen.

Failure also exists in F19

Same problem here (F20 x86_64).

In my case "evince" uses the symbol fonts from the wine-symbol-fonts package.

Instead, xpdf and acroread work like a charm.

The strange thing is that the EPS and DVI files from which I generated the PDF file looks good with evince. So I think it's problem of the PDF rendering part of evince

To reproduce this problem:

1. Write a R script "test.R"
---[test.R]---
x <- -4:4
y <- x^2
setEPS()
postscript(paste("chart.eps",sep=""),height=4,width=6)
plot(x,y, type="b", xlab=expression(paste(Delta, t)), ylab=expression(paste(Delta, t)^2))
grid()
dev.off()
---[/test.R]---

2. Generate an EPS figure "test.eps"
Rscript test.R

(Note: if you open the EPS file with evince, you see no wrong character)

3. Write a LaTeX file "test.tex":
---[test.tex]---
\documentclass{article}
\usepackage{graphicx}
\begin{document}
\section{A Section}
See Figure \ref{fig}.
\begin{figure}
\centering
\includegraphics[scale=.80]{test.eps}
\caption{A figure}\label{fig}
\end{figure}
\end{document}
---[/test.tex]---

4. Generate a DVI file "test.dvi"
latex test.tex
latex test.tex

(Note: if you open the DVI file with evince, you see no wrong character)

5 Convert the DVI file to a PDF file "test.pdf" with "dvipdf" or "dvipdfm"
dvipdf test.dvi
(or dvipdfm test.dvi)

You are right Ed, the problem is the font. Another manifestation seems to be the bug #1132978.
I'm reassigning this bug to the package google-croscore-fonts.

*** Bug 1132978 has been marked as a duplicate of this bug. ***

I'd recommend croscore-symbolneu drop the 'symbol' alias (at least until this problem is fixed), ie, drop the contents from the existing

/etc/fonts/conf.d/62-google-croscore-symbolneu.conf

that implements it

Created attachment 933274 [details]
Compact view of SymbolNeu

This issue is happening due to incorrect mapping in SymbolNeu.ttf font.

∅ is mappen to U+2206 and there are many other mapping those are incorrect in this fonts.

I cay easily say this is non-unicode font or may be some issue with selecting encoding while building this font.

We can fix this locally by ttx and patching to fonts. But good if upstream can fix this and provide new release. This is less likely to happen.

Thanks Pravin. I will drop fontconfig for now from f20+ branches and will check with upstream.

google-croscore-fonts-1.23.0-5.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/google-croscore-fonts-1.23.0-5.fc21

google-croscore-fonts-1.23.0-5.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/google-croscore-fonts-1.23.0-5.fc20

Confirmed the fix and added karma ...  Thanks....

Package google-croscore-fonts-1.23.0-5.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing google-croscore-fonts-1.23.0-5.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-10150/google-croscore-fonts-1.23.0-5.fc21
then log in and leave karma (feedback).

google-croscore-fonts-1.23.0-5.fc20 has been pushed to the Fedora 20 stable repository.

google-croscore-fonts-1.23.0-5.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.