Bug 221361 - [pango] [zh_CN] ascii text space and punctuation is narrow
Summary: [pango] [zh_CN] ascii text space and punctuation is narrow
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: pango
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Behdad Esfahbod
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: bzcl34nup
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-01-04 02:09 UTC by Jens Petersen
Modified: 2018-04-11 17:35 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-04-11 06:27:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 481188 0 None None None Never

Description Jens Petersen 2007-01-04 02:09:28 UTC
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.

Comment 1 Peng Huang 2007-02-12 03:15:56 UTC
I think it is same problem as bug #220885.

Comment 2 Liang Zhang 2007-09-28 07:51:17 UTC
the upstream bug:
http://bugzilla.gnome.org/show_bug.cgi?id=481188

Comment 3 Liang Zhang 2007-09-29 03:10:41 UTC
 Comment #1 from Behdad Esfahbod    (pango developer, points: 23)
2007-09-28 23:40 UTC [reply]

No Pango bug.  Fix in your font.



Comment 4 Jens Petersen 2007-10-01 00:53:14 UTC
Gecko is not using the Chinese font to render the text AFAICS.

Comment 5 Jens Petersen 2007-10-23 06:50:09 UTC
(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?

Comment 6 Jens Petersen 2007-10-23 07:03:44 UTC
and the spacing in cjkunifonts looks fine to me.

Comment 7 Behdad Esfahbod 2007-10-23 18:27:15 UTC
fine then.

Comment 8 Jens Petersen 2007-10-24 00:33:50 UTC
but still the problem exists I think...

Comment 9 Jens Petersen 2007-10-24 00:35:11 UTC
Peng Huang, this is still happening in F8, right?

Comment 10 Peng Huang 2007-10-24 02:08:58 UTC
Right. It still happens in F8.

Comment 11 Peng Huang 2007-10-24 02:33:53 UTC
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.

Comment 12 Matěj Cepl 2007-10-24 06:54:18 UTC
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.

Comment 13 Peng Huang 2007-10-24 07:14:59 UTC
$ 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.

Comment 14 Jens Petersen 2007-10-24 08:09:21 UTC
> 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.)

Comment 15 Behdad Esfahbod 2007-10-24 23:39:19 UTC
Why do you guys even have cour.pfa?  What package does it come from?

Comment 16 Jens Petersen 2007-10-25 00:13:24 UTC
(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.

Comment 17 Jens Petersen 2007-10-25 01:59:14 UTC
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.

Comment 18 Bug Zapper 2008-04-03 18:50:58 UTC
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.

Comment 19 Jens Petersen 2008-04-10 07:22:59 UTC
Does this still happen under F9?

Comment 20 Peng Huang 2008-04-10 08:40:10 UTC
I can not reproduce it in my F9 test box.


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