Hide Forgot
Description of problem: Space and punctuation characters are not rendered monospaced for ASCII text in Firefox or Thunderbird for East Asian locale. It is hard to read ASCII mail in a Chinese encoding since the space character used is too narrow. How reproducible: every time Steps to Reproduce: 0. install fonts-chinese 1. open for example http://download.fedora.redhat.com/pub/fedora/linux/core/6/i386/os/eula.txt 2. View -> Character Encoding -> More Encodings -> East Asia -> Traditional Chinese (Big5) 3. look at spacing between words Actual results: Space character is only 4 pixels wide compared to 10 pixels for other ascii characters Expected results: Space character to be at least of comparable width to other characters. All ASCII should be rendered correctly monospaced. Additional info: Turning off pango with MOZ_DISABLE_PANGO=1 works around the problem. I am filing this under firefox since it seems to be a moz pango issue, though it affects thunderbird more seriously.
I think it is same problem as bug #220885.
the upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=481188
Comment #1 from Behdad Esfahbod (pango developer, points: 23) 2007-09-28 23:40 UTC [reply] No Pango bug. Fix in your font.
Gecko is not using the Chinese font to render the text AFAICS.
(In reply to comment #1) > I think it is same problem as bug #220885. Yes I think so. But I don't think we can remove the ascii glyphs from cjkunifonts, right?
and the spacing in cjkunifonts looks fine to me.
fine then.
but still the problem exists I think...
Peng Huang, this is still happening in F8, right?
Right. It still happens in F8.
I checked the config of firefox. (type "about:config" in URL input area) firefox uses different fonts to render ASCII in different languages. Please check configure values: font.name.monospace.* English is using font Courier. zh-* are using font monospace. Maybe it is the problem.
What is the output of these two commands: fc-match monospace fc-match Courier ??? For me it is, [matej@viklef ~]$ fc-match monospace DejaVuLGCSansMono.ttf: "DejaVu LGC Sans Mono" "Book" [matej@viklef ~]$ fc-match Courier cour.pfa: "Courier" "Regular" [matej@viklef ~]$ which means that Courier is actually old bitmap ASCII only cour.pfa, whereas monospace is shiny DeJa font (dejavu.sf.net), which doesn't cover any Chinese (see http://dejavu.svn.sourceforge.net/viewvc/*checkout*/dejavu/trunk/dejavu-fonts/langcover.txt for more info). However, monospace is just fontconfig alias, so it would be interesting to know which actual font it points to on your machine.
$ fc-match monospace DejaVuLGCSansMono.ttf: "DejaVu LGC Sans Mono" "Book" $ fc-match Courier cour.pfa: "Courier" "Regular" It is same in my system. $ LANG=zh_CN fc-match monospace uming.ttf: "AR PL ShanHeiSun Uni" "Regular" LANG=zh_CN fc-match Courier cour.pfa: "Courier" "Regular" But if I use zh_CN locale, the output will be different. BTW, if I change font.name.monospace.zh-CN's value to Courier, ascii text will look good.
> BTW, if I change font.name.monospace.zh-CN's value to Courier, ascii text will > look good. I wonder why it only happens for zh though? ja and ko also default to "monospace" and do not have this problem. (As noted elsewhere this problem does not occur in upstream ff3 builds but I have not tested firefox3 builds for Fedora yet.)
Why do you guys even have cour.pfa? What package does it come from?
(In reply to comment #15) > Why do you guys even have cour.pfa? What package does it come from? I was wondering a bit too about it. It is from xorg-x11-fonts-Type1.
After removing xorg-x11-fonts-Type1, "LANG=zh fc-match Courier" give the Chinese font, but firefox still seems to do the wrong thing. Looking closer actually at the ja case I notice now that it is actually also using a different font (different width glyphs) for space and punctuation under Japanese. So actually the issue is not specific to Chinese. BTW xorg-x11-fonts-Type1 is a mandatory package in the @base-x package group in comps.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
Does this still happen under F9?
I can not reproduce it in my F9 test box.