Bug 88804 - Bad spacing in Monospace font
Summary: Bad spacing in Monospace font
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: urw-fonts
Version: 9
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Than Ngo
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-14 12:19 UTC by Miloš Komarčević
Modified: 2007-04-18 16:53 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-06-16 10:20:15 UTC
Embargoed:


Attachments (Terms of Use)
Nimbus Mono L font in gnome-terminal and en_GB locale (8.53 KB, image/png)
2003-04-14 17:20 UTC, Miloš Komarčević
no flags Details
Nimbus Mono L font in gnome-font-properties and en_GB locale (52.24 KB, image/png)
2003-04-14 17:21 UTC, Miloš Komarčević
no flags Details

Description Miloš Komarčević 2003-04-14 12:19:18 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313

Description of problem:
For non-english locales (such as sr_YU.UTF8) the inter-character
spacing in the "M o n o s p a c e" font in applications is huge.

Monospace Bold does not seem to suffer this problem?

This first happened in phoebe3, phoebe2 and psyche were ok.

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

How reproducible:
Always

Steps to Reproduce:

    

Additional info:

Comment 1 Mike A. Harris 2003-04-14 12:31:08 UTC
Not sure why you think this is an XFree86 bug.  Could you elaborate on
which portion of XFree86 you think is causing this problem?

Any time I've heard of these types of problems, it has been a user using
a multibyte font with an application that doesn't handle multibyte fonts
properly, or some similar issue unrelated to XFree86.

Comment 2 Owen Taylor 2003-04-14 16:24:08 UTC
Well, actually, the more important question than the above is
in which applications this is occurring.


Comment 3 Miloš Komarčević 2003-04-14 16:27:17 UTC
If I remember correctly, it appeared after I upgraded phoebe2 to
XFree86-4.2.99-something from rawhide, and that same package was
later in phoebe3 that also had this problem on fresh install, just 
like shrike.

I could be wrong of course and this very well might not be a XFree86 bug:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=80418
(any idea why I can't post to this bug anymore? - says I'm not
permitted to change the component, and I'm not trying to)

It does not seem to be application specific: I see this in gnome-terminal,
mozilla, and Gnome font preferences dialog at least.

Comment 4 Owen Taylor 2003-04-14 16:44:25 UTC
Weird. The three apps you mentioned are using quite different font
rendering technologies.

My guess is that the problem is that no monospace font on the system
is considered to have the necessary code pointer coverage for
sr_YU, so a non-monospaced font is being used, which will look
awful in gnome-terminal, but I'm suprised causes any difficulty
for mozilla or gnome-font-properties.

Can you provide a screenshots of the rendering in gnome-terminal
and gnome-font-properties?


Comment 5 Miloš Komarčević 2003-04-14 17:18:55 UTC
And it just got more weird.

I've just tried gnome-font-properties on my machine at work 
with en_GB locale and the same happens with Nimbus Mono L font instead!

As with Monospace Bold and sr_YU, Nimbus Mono L Bold looks ok.
 


Comment 6 Miloš Komarčević 2003-04-14 17:20:09 UTC
Created attachment 91126 [details]
Nimbus Mono L font in gnome-terminal and en_GB locale

Comment 7 Miloš Komarčević 2003-04-14 17:21:15 UTC
Created attachment 91127 [details]
Nimbus Mono L font in gnome-font-properties and en_GB locale

Comment 8 Owen Taylor 2003-04-17 22:31:31 UTC
Downgrading to the Red Hat 8 version of the urw-fonts package will
fix the problem.


Comment 9 Miloš Komarčević 2003-04-22 10:17:56 UTC
I can confirm that downgrading urw-fonts does the trick for now
on both sr_YU and en_GB locales.

Comment 10 Miloš Komarčević 2003-06-16 10:20:15 UTC
urw-fonts-2.1-2 from rawhide seems 
not to have this problem any more


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