[Bug 923346] New: Symbols incorrectly displayed
by Red Hat Bugzilla
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=923346
Bug ID: 923346
Summary: Symbols incorrectly displayed
Product: Fedora
Version: 18
Component: google-croscore-fonts
Severity: high
Priority: unspecified
Assignee: pnemade(a)redhat.com
Reporter: jv+fedora(a)fcelda.cz
QA Contact: extras-qa(a)fedoraproject.org
CC: andreas.bierfert(a)lowlatency.de,
fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, jreznik(a)redhat.com,
kevin(a)tigcc.ticalc.org, ltinkl(a)redhat.com,
mike(a)cchtml.com, mkasik(a)redhat.com,
pnemade(a)redhat.com, rdieter(a)math.unl.edu,
richard(a)rsk.demon.co.uk, rnovacek(a)redhat.com,
stefan(a)lsd.co.za, than(a)redhat.com, tibbs(a)math.uh.edu
Depends On: 901858
I'm seeing the same problem as described in bug #901858 with
google-croscore-symbolneu-fonts-1.21.0-4.fc18.noarch package. Removing the
package solves the problem and math symbols are displayed correctly.
google-croscore-symbolneu-fonts-1.21.0-4.fc18.noarch
okular-4.10.1-1.fc18.x86_64
+++ This bug was initially created as a clone of Bug #901858 +++
Created attachment 683157
microchip pdf showing the fault
Description of problem:
When reading technical pdfs, the wrong symbols are displayed for some math
characters. e.g. pi is displayed as not equal, ohms as a vertical bar, and
micro (mu) is displayed as infinity.
Version-Release number of selected component (if applicable):
okular-4.9.5.-1.fc18
How reproducible:
Displaying a technical pdf such as
http://ww1.microchip.com/downloads/en/AppNotes/00954A.pdf
shows the wrong symbols.
E.G. In figure 1 - the value for C2 is displayed as 470 (inf) F instead of 470
(mu) F
Steps to Reproduce:
1. Display technical pdf
2.
3.
Actual results:
pi is displayed as not equals
ohms as a vertical bar
micro(mu) as infinity
Expected results:
The correct symbols should be displayed
Additional info:
Evince also has this problem, but emacs displays everything correctly.
This happens across a range of pdfs and I think is a serious bug than needs
fixing as soon as possible,. It reflects badly on fedora if we cannot display
technical specifications properly.
--- Additional comment from Kevin Kofler on 2013-01-19 12:47:09 EST ---
> Evince also has this problem
Reassigning to poppler, which is the common library used by both.
What I see is that this PDF does not embed its fonts, which means you get
whatever fonts are installed on the system. In this case, Symbol is mapped to
wine-symbol-fonts. So I'm not sure whether poppler or the font is doing the
wrong thing there.
And by the way, the PDF is bad because it uses a font outside of the PostScript
standard (Symbol) and doesn't embed it. A portable PDF MUST embed all the
non-PostScript fonts it uses.
--- Additional comment from Richard Kennedy on 2013-02-28 07:57:45 EST ---
Just a quick update.
The new embedded pdf reader in Firefox 19 displays these files correctly too.
Well, the pdf may not be correct but it was created by adobe software & there
are lots of them out in the wild, so we should do something to fix it.
Can I change the default font mapping for popper to something else ? If so how
do I go about that?
--- Additional comment from Kevin Kofler on 2013-02-28 19:00:01 EST ---
As I said, it's a bug in either poppler or wine-symbol-fonts (or both).
Unfortunately, the poppler maintainer hasn't answered so far.
--- Additional comment from Marek Kašík on 2013-03-01 07:05:38 EST ---
Hi,
this is a bug in wine-symbol-fonts package. The symbol.ttf font has wrong
mapping.
For additional info see upstream bug
http://bugs.winehq.org/show_bug.cgi?id=24099.
I'm reassigning this to wine.
Regards
Marek
--- Additional comment from Jason Tibbitts on 2013-03-01 14:45:34 EST ---
Wow, it's great news that this the cause is known, because I've been struggling
with this for some time. Unfortunately upstream bug report has been there for
quite some time with no progress, so I'm not sure what chance we have of
getting this fixed. What would break by removing this font? Can it be removed
from the dependency list of the wine-fonts metapackage?
--- Additional comment from Kevin Kofler on 2013-03-01 17:53:16 EST ---
Would that really fix the issue? I don't think the symbols can be properly
displayed if the font is entirely missing. I suspect there's no way around
fixing the font.
--- Additional comment from Richard Kennedy on 2013-03-02 11:50:34 EST ---
I've just fixed the font following the steps in the wine bug 24099 and it
works.
I only run one wine app, ltspice, and it still works after the fix, so it's all
looking good.
Both firefox & emacs can display these characters properly so they must be
using some other font, but I don't know how to find out which one. But if we
could find out can we swap the mapping to that?
--- Additional comment from Richard Kennedy on 2013-03-02 13:29:50 EST ---
Having thought about this some more, I think that is more likely that the bug
really is that poppler isn't handling unicode characters properly.
I cut & pasted the failing mu character from evince into emacs, and it says
it's unicode 0x3BC. So it seems that poppler tries to use the symbol font and
0x3BC
is something different in there because it's broken too.
emacs and firefox somehow resolve the unicode character correctly and don't end
up in the symbol font, but I haven't found out which font they do use.
I didn't realise all of this stuff was so involved and complex. At least fixing
up the font is a temporary fix.
--- Additional comment from Kevin Kofler on 2013-03-02 17:58:39 EST ---
Maybe poppler shouldn't be looking up "Symbol" in fontconfig at all, but handle
the Symbol font specially? The Window$ Symbol TTF font which WINE's font tries
to emulate is a hack which predates Unicode and maps Greek letters and other
symbol characters to plain 8-bit characters (0-255). Somebody should probably
test what happens when you use the original M$ Symbol.ttf. If it has the same
issue, it's not WINE's fault.
--- Additional comment from Richard Kennedy on 2013-03-04 12:44:39 EST ---
Just a couple of notes :-
* The poppler version here is 0.20.2 which was released on Tue July 10, 2012,
and
the latest is 0.22.1 which contains quite a number of bug fixes.
* I've reset my machine to the default state and if I run pdftohtml on this
file
the correct characters are generated in the html. (pdftohtml is a poppler
tool).
* Libre Office also can display these files correctly.
Is there any way to get poppler to use the opensymobol font to resolve these
symbols? AFAICT opensymbol contains all of the correct unicode so might make a
good replacement and it's already installed.
--- Additional comment from Marek Kašík on 2013-03-05 07:26:52 EST ---
Created attachment 705385
blacklist wine font Symbol
(In reply to comment #10)
> Just a couple of notes :-
>
> * The poppler version here is 0.20.2 which was released on Tue July 10,
> 2012, and
> the latest is 0.22.1 which contains quite a number of bug fixes.
The poppler-0.22.1 doesn't fix this.
> * I've reset my machine to the default state and if I run pdftohtml on this
> file
> the correct characters are generated in the html. (pdftohtml is a poppler
> tool).
It generates correct html because the codes for those characters are correct in
the pdf.
> * Libre Office also can display these files correctly.
Do you mean the html or the pdf? Libre Office displays me the same characters
as poppler when importing the pdf.
> Is there any way to get poppler to use the opensymobol font to resolve these
> symbols? AFAICT opensymbol contains all of the correct unicode so might make
> a good replacement and it's already installed.
Place the attached file to ~/.config/fontconfig/fonts.conf. This will blacklist
the font for all applications which use fontconfig (useful when the
wine-symbol-fonts is a dependency of a package which you don't want to remove).
I've tried to view a file with the character for the micro sign (UTF-8 code
0xC2B5) in notepad which is part of wine-common. After switching the font to
"Symbol", it showed me the incorrect symbol. I guess that there is really
something wrong with the font.
Regards
Marek
--- Additional comment from Kevin Kofler on 2013-03-05 10:00:50 EST ---
The problem is that the Symbol font was designed in a way that the 'm'
character is displayed as 'µ', and 'µ' is not mapped to anything. In fact,
Symbol was the way to get those special characters in old software which didn't
support Unicode. I don't know whether it's possible to fix this issue without
breaking that old software when people try to run it under WINE. I hope it's
possible, but I'm not sure. The WINE upstream bug report has a proposed fix,
but I don't know whether that fix doesn't break the non-Unicode apps.
--- Additional comment from Andreas Bierfert on 2013-03-05 14:55:02 EST ---
Well as a workaround we could confine wine symbol to wine for now (like with
tahoma). This would reduce the problem to wine applications.
Before resorting to this I will investigate a bit...
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ILFMitOgOk&a=cc_unsubscribe
9 years, 3 months
[Bug 708525] New: hinting turned off even for large fonts
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: hinting turned off even for large fonts
https://bugzilla.redhat.com/show_bug.cgi?id=708525
Summary: hinting turned off even for large fonts
Product: Fedora
Version: 15
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: pango
AssignedTo: behdad(a)fedoraproject.org
ReportedBy: horsley1953(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: behdad(a)fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org
Classification: Fedora
Story Points: ---
Created attachment 501397
--> https://bugzilla.redhat.com/attachment.cgi?id=501397
Screen shot of office writer document with different size fonts in same
families.
Description of problem:
On my fedora 15 system, the fonts all render terribly by default, being
completely thin and spindly. After much investigation, I find various
settings down in the /etc/fonts config files to do things like turn
off hinting for fonts smaller than 7.5 (what units 7.5 are in, I'm not
sure), but in fact hinting seems to be turned off for fonts up to
point size 13 as the attached screenshot of a libreoffice document
seems to show.
So many pieces are involved in font rendering, I don't know for sure
if pango is the right component for this, but it is my best guess.
Version-Release number of selected component (if applicable):
pango-1.28.4-1.fc15.x86_64
cairo-1.10.2-3.fc15.x86_64
fontconfig-2.8.0-3.fc15.x86_64
How reproducible:
100%
Steps to Reproduce:
1.See screenshot of office writer image
2.
3.
Actual results:
All fonts 13 points and under rendered incredibly spindly.
Expected results:
Better font rendering.
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 3 months
[Bug 1155261] New: add Requires(post): libXft
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1155261
Bug ID: 1155261
Summary: add Requires(post): libXft
Product: Fedora
Version: rawhide
Component: pango
Assignee: tagoh(a)redhat.com
Reporter: msuchy(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, tagoh(a)redhat.com
Description of problem:
Recently I seen during installation:
Installing : pango-1.36.8-1.fc22.x86_64
133/239
/usr/bin/pango-querymodules-64: error while loading shared libraries:
libXft.so.2: cannot open shared object file: No such file or directory
Installing : libXft-2.3.2-2.fc22.x86_64
134/239
pango have in spec:
%post
/usr/bin/pango-querymodules-%{__isa_bits} --update-cache || :
/usr/bin/pango-querymodules-64 requires libXft.so.2 for running, therefore
pango should have
Requires(post): libXft
or similar.
Version-Release number of selected component (if applicable):
pango-1.36.8-1.fc22.x86_64
How reproducible:
50 %chance to reproduce
Steps to Reproduce:
1. rm -rf /var/lib/mock/fedora-rawhide-x86_64/root/*
2. /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-x86_64/root/
--releasever rawhide install @buildsys-build --setopt=tsflags=nocontexts
--nogpgcheck
Actual results:
Expected results:
pango is installed before libXft and therefore %post fails.
Additional info:
no errors
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=uyop3nwgzP&a=cc_unsubscribe
9 years, 3 months
[Bug 1160132] New: new release urw-fonts-1.10-1 made lilypond package failed to build
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1160132
Bug ID: 1160132
Summary: new release urw-fonts-1.10-1 made lilypond package
failed to build
Product: Fedora
Version: rawhide
Component: urw-fonts
Assignee: than(a)redhat.com
Reporter: pnemade(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org, than(a)redhat.com
Description of problem:
After some analysis I found that in configure script of lilypond package there
is a check which is now evaluated to no
checking for New Century Schoolbook PFB files... no
This rule is executing following command actually which worked with f21
urw-fonts but failed for f22.
On F21 I get
$ fc-list "Century Schoolbook L:foundry=urw:fontformat=Type 1:lang=ru"
/usr/share/fonts/default/Type1/c059016l.pfb: Century Schoolbook L:style=Bold
/usr/share/fonts/default/Type1/c059033l.pfb: Century Schoolbook L:style=Italic
/usr/share/fonts/default/Type1/c059013l.pfb: Century Schoolbook L:style=Roman
/usr/share/fonts/default/Type1/c059036l.pfb: Century Schoolbook L:style=Bold
Italic
On F22 I get no output
$ fc-list "Century Schoolbook L:foundry=urw:fontformat=Type 1:lang=ru"
Then I checked new fonts information in fontforge=>Element=> Font Info and
found fonts now no longer provide name "Century Schoolbook L" but "Century
Schoolbook URW".
Version-Release number of selected component (if applicable):
urw-fonts-1.10-1.fc22
How reproducible:
always failed to (re-)build lilypond in rawhide
Steps to Reproduce:
1.
2.
3.
Actual results:
no font provide name "Century Schoolbook L"
Expected results:
should fonts provide name "Century Schoolbook L"? or new names are okay. If
they are then lilypond maintainer need to fix this.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=CHJjc0PTrt&a=cc_unsubscribe
9 years, 4 months
[Bug 586214] New: knm-new-fixed-fonts isn't usable
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: knm-new-fixed-fonts isn't usable
https://bugzilla.redhat.com/show_bug.cgi?id=586214
Summary: knm-new-fixed-fonts isn't usable
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: knm-new-fixed-fonts
AssignedTo: tagoh(a)redhat.com
ReportedBy: tagoh(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: tagoh(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org
Classification: Fedora
Target Release: ---
Description of problem:
knm-new-fixed-fonts is capable for Japanese font though, it doesn't have enough
glyph coverage for Japanese.
Version-Release number of selected component (if applicable):
knm-new-fixed-fonts-1.1-11.fc13
How reproducible:
always
Steps to Reproduce:
1.fc-match -v Fixed|grep -E " lang"|grep ja
2.
3.
Actual results:
No output
Expected results:
the lang spec should contains ja.
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 4 months
[Bug 485566] New: Fontconfig should select DejaVu font for rendering English, even in Japanese locale.
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Fontconfig should select DejaVu font for rendering English, even in Japanese locale.
https://bugzilla.redhat.com/show_bug.cgi?id=485566
Summary: Fontconfig should select DejaVu font for rendering
English, even in Japanese locale.
Product: Fedora
Version: 10
Platform: All
OS/Version: Linux
Status: NEW
Severity: high
Priority: medium
Component: fontconfig
AssignedTo: besfahbo(a)redhat.com
ReportedBy: ryo-dairiki(a)users.sourceforge.net
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Description of problem:
As you know, fontconfig finds proper fonts for text rendering,
depending on locales of process and text to render.
It works properly in the most cases, but there are some sever cases.
For example, if you type only "@" or "}" in gedit,
it uses glyph of VLGothic in Japanese locale.
However, if you type "a" after the first character,
it changes one's mind to choose glyphs of DejaVu fonts.
It's very annoying for Japanese users.
In the worst cases, the width of the indentations of sourcecode seems
different.
(As the width of the " " glyphs are differ between VLGothic and DejaVu)
How reproducible:
Steps to Reproduce:
1. Login X11 as a Japanese.
2. Open gedit and change the configuration to use "Monospace".
3. Type "@" on the first line, and "@a" on the first line.
Actual results:
"@" seems differ between the two lines.
Expected results:
"@" seems the same between the two lines.
The same glyph should be used for rendering the two "@".
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 4 months
[Bug 487061] New: Japanese fonts changed to less readable after update
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Japanese fonts changed to less readable after update
https://bugzilla.redhat.com/show_bug.cgi?id=487061
Summary: Japanese fonts changed to less readable after update
Product: Fedora
Version: 10
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: vlgothic-fonts
AssignedTo: ryo-dairiki(a)users.sourceforge.net
ReportedBy: mcmonster(a)o2.pl
QAContact: extras-qa(a)fedoraproject.org
CC: tagoh(a)redhat.com, ryo-dairiki(a)users.sourceforge.net,
fedora-fonts-bugs-list(a)redhat.com,
fedora-i18n-bugs(a)redhat.com
Classification: Fedora
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; pl-PL; rv:1.9.0.6)
Gecko/2009020410 Fedora/3.0.6-1.fc10 Firefox/3.0.6
I'm using irssi on gnome-terminal (Monospace font), after update Japanese fonts
changed, they're now much smaller (compared to latin), harder to read (some
ideograms are completely unreadable). It is very annoying, because I use
Japanese and sit on Japanese channel a lot. The change occured only in
terminal, in gEdit and other applications old fonts are still used for typing
(SCIM + Anthy) and displaying.
The change didn't affect everyone, some Fedora 10 still got old, simple and
readable fonts.
Reproducible: Always
Steps to Reproduce:
Just try displaying any Japanese text.
This is the update, that probably changed fonts:
Feb 14 02:31:53 Installed: vlgothic-fonts-common-20090204-2.fc10.noarch
Feb 14 02:32:39 Installed: vlgothic-fonts-20090204-2.fc10.noarch
Feb 14 02:32:42 Installed: vlgothic-p-fonts-20090204-2.fc10.noarch
Feb 14 02:33:28 Erased: VLGothic-fonts
Feb 14 02:33:30 Erased: VLGothic-fonts-proportional
]# LANG=C yum list vlgothic\*
Loaded plugins: refresh-packagekit
Installed Packages
vlgothic-fonts.noarch 20090204-2.fc10
installed
vlgothic-fonts-common.noarch 20090204-2.fc10
installed
Available Packages
VLGothic-fonts.noarch 20081029-1.fc10 updates
VLGothic-fonts-proportional.noarch 20081029-1.fc10 updates
vlgothic-p-fonts.noarch 20090204-2.fc10 updates
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 4 months
[Bug 1162341] New: Noto Color Emoji not packaged
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1162341
Bug ID: 1162341
Summary: Noto Color Emoji not packaged
Product: Fedora
Version: rawhide
Component: google-noto-fonts
Severity: low
Assignee: psatpute(a)redhat.com
Reporter: mavit(a)mavit.org.uk
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
psatpute(a)redhat.com, pwu(a)redhat.com
The Noto project includes a Makefile and scripts to build a TTF font, Noto
Emoji Color, from SVG source files.
Fedora 20 and higher supports these colour fonts (albeit by displaying them in
greyscale). Hence, we should package them.
I shall try to come up with a patch...
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=bxPzItPzS4&a=cc_unsubscribe
9 years, 4 months