47582 - Chrome and Linux font interaction

Status: RESOLVED INCOMPLETE

(Core :: XUL, defect, P3)

Description

[tenthumbs]

Apologies in advance if I have the wrong component.

On my Linux system, I find the urlbar difficult to use because it uses a
proportional font so I've been experimenting with monospaced fonts which is
what 4.x uses. In the course of this I noticed that Mozilla sometimes lays
out the chrome rather strangely depending on the font used. I also noticed
that it affects all the chrome not just the urlbar.

For this bug, I added the following:

window { 
  font-family: "Courier New",courier,monospace !important; 
  font-size: 12pt !important;
}

or some variant on the font-family to my user.css. My system is a 75dpi one
and I have configured the X server, the font servers, and Mozilla
appropriately. I have the standard XFree86 fonts as well as the common
Microsoft TrueType fonts available. In this test, I am using the xfsft font
server. I also have the LucidaTypewriter font as the default monospace one.

See the attached image for examples of what happens.

For the three cases in the image, Mozilla loads these fonts:

-b&h-lucidatypewriter-medium-r-normal-sans-12-120-75-75-m-70-iso8859-1
-b&h-lucidatypewriter-bold-r-normal-sans-12-120-75-75-m-70-iso8859-1

-adobe-courier-medium-r-normal--12-120-75-75-m-70-iso8859-1
-adobe-courier-bold-r-normal--12-120-75-75-m-70-iso8859-1

-monotype-courier new-medium-r-normal--13-*-*-*-m-*-iso8859-1
-monotype-courier new-bold-r-normal--13-*-*-*-m-*-iso8859-1

For the latter two fonts, the X server maps them as follows:

-monotype-courier new-medium-r-normal--13-*-*-*-m-*-iso8859-1
  -> -monotype-courier new-medium-r-normal--13-125-75-75-m-0-iso8859-1
-monotype-courier new-bold-r-normal--13-*-*-*-m-*-iso8859-1
  -> -monotype-courier new-bold-r-normal--13-125-75-75-m-0-iso8859-1

From the image, it is clear that the LucidaTypewriter and Courier fonts
work reasonably well but Courier New is badly positioned. Compare this with
the document area where the same fonts are used and where they are
positioned properly.

In the Courier New case, look carefully and you can see that the urlbar text
(and its caret) are displaced vertically upward from the apparent center
line of the urlbar. I think this is true in all the cases but I think it's
only obvious in the Courier New case.

If you want to consider only the urlbar, you can add 

#urlbar { 
  font-family: "Courier New",courier,monospace !important; 
  font-size: 12pt !important;
}

to user.css or even navigator.css.

Since Linux, and other Unix users, have config files coming out of their
ears and are used to editing them to set preferences, I expect that the
issue here will cause problems.

Comment 1

[tenthumbs]

Attachment: PNG screenshot

Comment 2

[Matthew T (active 1999-2002)]

QA --> Claudius

Comment 3

[leger]

Reassigning from bdonohoe to hangas

Comment 4

[tenthumbs]

It's not just monospace fonts. I see similarly odd layout with the Geneva font.

Comment 5

[Akkana Peck]

I've seen this effect, too.  Adding Erik since he's the font guru.

Comment 6

[tenthumbs]

Nor is it all truetype monospace fonts. Andale Mono works.

The modern2 skin does give a possible hint. See the attached image. I use 12pt
for readability and a monospaced font for the urlbar because I find it much
easier to use. Note the interesting box for Courier New.

Comment 7

[tenthumbs]

Attachment: Modern2 PNG screenshots

Comment 8

[tenthumbs]

Attachment: Same PNG without some ancillary chunks that 4.x browsers don't like. Sorry about that.

Comment 9

[Matthew T (active 1999-2002)]

[Sorry, I changed the component before but didn't reassign. Fixing up.]

Comment 10

[Peter Trudelle]

->evaughan for possible box involvement, or should Erik own this?

Comment 11

[Eric Vaughan]

It could be a box problem. A good test would be to make a <text> tag in xul put 
a border around it and then try different fonts. Does it get layout correctly? 
Is the text correctly in the borders?

Comment 12

[Peter Trudelle]

Happens in text fields, not in box. ->mjudge, per evaughan

Comment 13

[rubydoo123]

reassigning this to kin.  he is working on other font issues and will be able to
investigate this one along the way.  leaving at p3

Comment 14

[kinmoz]

Accepting bug.

Comment 15

[rubydoo123]

moving to future, this is not a must fix

Comment 16

[Robert Kaiser]

hmm, this looks to me similar to bug 78643 - what do you think?

Comment 17

[gavin long]

could this be related to bug 89783 ?