Bug 1037882 - Wrong character displayed with google-croscore-symbolneu-fonts installed
Summary: Wrong character displayed with google-croscore-symbolneu-fonts installed
Alias: None
Product: Fedora
Classification: Fedora
Component: google-croscore-fonts
Version: 20
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Parag Nemade
QA Contact: Fedora Extras Quality Assurance
: 1132978 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2013-12-04 01:37 UTC by Ed Greshko
Modified: 2014-09-23 04:21 UTC (History)
9 users (show)

Fixed In Version: google-croscore-fonts-1.23.0-5.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-09-19 10:11:52 UTC
Type: Bug

Attachments (Terms of Use)
Contains U+2206 in a pdf (3.24 KB, application/pdf)
2013-12-04 01:37 UTC, Ed Greshko
no flags Details
Compact view of SymbolNeu (96.08 KB, image/png)
2014-09-01 08:14 UTC, Pravin Satpute
no flags Details

Description Ed Greshko 2013-12-04 01:37:54 UTC
Created attachment 832377 [details]
Contains U+2206 in a pdf

Description of problem: If google-croscore-symbolneu-fonts is installed evince will display ∆ incorrectly as ∅

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install google-croscore-symbolneu-fonts-1.23.0-2.fc19.noarch
2. evince test.pdf

Actual results: ∅ displayed 

Expected results: ∆ should be displayed

Additional info:

Comment 1 Ed Greshko 2013-12-04 12:08:17 UTC
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

Comment 2 Ed Greshko 2013-12-04 12:21:05 UTC
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.

Comment 3 Ed Greshko 2013-12-04 12:22:41 UTC
Failure also exists in F19

Comment 4 Marco Guazzone 2014-03-10 14:19:12 UTC
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"
x <- -4:4
y <- x^2
plot(x,y, type="b", xlab=expression(paste(Delta, t)), ylab=expression(paste(Delta, t)^2))

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":
\section{A Section}
See Figure \ref{fig}.
\caption{A figure}\label{fig}

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)

Comment 5 Marek Kašík 2014-08-28 13:23:40 UTC
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.

Comment 6 Marek Kašík 2014-08-28 13:26:08 UTC
*** Bug 1132978 has been marked as a duplicate of this bug. ***

Comment 7 Rex Dieter 2014-08-28 13:54:09 UTC
I'd recommend croscore-symbolneu drop the 'symbol' alias (at least until this problem is fixed), ie, drop the contents from the existing


that implements it

Comment 8 Pravin Satpute 2014-09-01 08:14:20 UTC
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.

Comment 9 Parag Nemade 2014-09-02 04:19:20 UTC
Thanks Pravin. I will drop fontconfig for now from f20+ branches and will check with upstream.

Comment 10 Fedora Update System 2014-09-03 13:03:49 UTC
google-croscore-fonts-1.23.0-5.fc21 has been submitted as an update for Fedora 21.

Comment 11 Fedora Update System 2014-09-03 13:19:53 UTC
google-croscore-fonts-1.23.0-5.fc20 has been submitted as an update for Fedora 20.

Comment 12 Ed Greshko 2014-09-03 23:43:19 UTC
Confirmed the fix and added karma ...  Thanks....

Comment 13 Fedora Update System 2014-09-06 00:57:56 UTC
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:
then log in and leave karma (feedback).

Comment 14 Fedora Update System 2014-09-19 10:11:52 UTC
google-croscore-fonts-1.23.0-5.fc20 has been pushed to the Fedora 20 stable repository.

Comment 15 Fedora Update System 2014-09-23 04:21:31 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.