Build is from the morning of October 3, 2001 on the tip. I have grayed out folders in my IMAP folder list and the fonts are really strange. They have spaces in between them. I'll start looking at checkins and attach a screenshot in a moment.

This was caused by bstell's checkin to nsFontMetricsGtk.cpp. Brian, may I back it out or do you think that you can fix it?

let me take a look

What OS/rev? How does one grey out a folder? What theme are you using?

bstell- pleae mark it as ASSIGN if you agree to work on it.

The font in the screen shot looks very similar to 102623

Modern skin, Red Hat 7.<mumble>. These grayed out folders are directories on the imap server.

how can I grey oot a folder so I can try to reproduce / debug this?

Can you set the env. variable NS_FONT_DEBUG and see what font is used for the greyed-out IMAP folder? Is it wadalab-gothic? (ref. bug 102643). My very wild guess is that when there's NO CSS spec. for a certain element, kinda 'random' (or the first matched one)font among some 'hard-coded' family of fonts is picked. The directory name on IMAP server may not be assigned an 'style'. Neither is the email body (when fixed-width font is specified to be used. ref. bug 102643 and perhaps bug 83250)

the interesting bits from the font trace: (grep loaded bug102940.attachment52039 [details] | sort | uniq) loaded -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso8859-1 loaded -adobe-helvetica-bold-r-normal--18-180-75-75-p-103-iso8859-1 loaded -adobe-helvetica-bold-r-normal--20-140-100-100-p-105-iso8859-1 loaded -adobe-helvetica-medium-r-normal--10-100-75-75-p-56-iso8859-1 loaded -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1 loaded -adobe-helvetica-medium-r-normal--14-140-75-75-p-77-iso8859-1 loaded -adobe-times-bold-r-normal--17-120-100-100-p-88-iso8859-1 loaded -adobe-times-bold-r-normal--24-240-75-75-p-132-iso8859-1 loaded -adobe-times-bold-r-normal--34-240-100-100-p-177-iso8859-1 loaded -adobe-times-medium-r-normal--17-120-100-100-p-84-iso8859-1 loaded -alias-helvetica-medium-i-normal--12-*-0-0-c-*-iso8859-1 and (grep return bug102940.attachment52039 [details] | sort | uniq) returns -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso8859-1 returns -adobe-helvetica-bold-r-normal--18-180-75-75-p-103-iso8859-1 returns -adobe-helvetica-bold-r-normal--20-140-100-100-p-105-iso8859-1 returns -adobe-helvetica-medium-r-normal--10-100-75-75-p-56-iso8859-1 returns -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1 returns -adobe-helvetica-medium-r-normal--14-140-75-75-p-77-iso8859-1 returns -adobe-times-bold-r-normal--17-120-100-100-p-88-iso8859-1 returns -adobe-times-bold-r-normal--24-240-75-75-p-132-iso8859-1 returns -adobe-times-bold-r-normal--34-240-100-100-p-177-iso8859-1 returns -adobe-times-medium-r-normal--17-120-100-100-p-84-iso8859-1 returns -alias-helvetica-medium-i-normal--12-*-0-0-c-*-iso8859-1 shows all adobe-helvetica and adobe-times except for the alias-helvetica. Chris: can you find and temporarily disable the alias-helvetica?

chris: can you try displaying html content using -alias-helvetica-medium-i-normal--12-*-0-0-c-*-iso8859-1 ?

>------- Additional Comments From Christopher Blizzard 2001-10-03 19:19 ------- >Modern skin, Red Hat 7.<mumble>. These grayed out folders are directories on >the imap server. When will IMAP directory grayed out on Modern Skin? I cannot make it happen

I have a grayed out folder on my IMAP server since it's a directory that you can't actually put messages in.

In the font trace (attachment 52039 [details]), I found the following lines (and many more similar lines for alias-helvetica): bitmap (non-scaled) font: -alias-helvetica-bold-i-normal--17-120-100-100-c-0-iso8859-1, nsFontMetricsGTK.cpp 3224 outline scaled font: -alias-helvetica-bold-i-normal--0-0-0-0-c-0-iso8859-1, nsFontMetricsGTK.cpp 3235 bitmap (non-scaled) font: -alias-helvetica-bold-i-normal--17-120-100-100-c-0-jisx0208.1983-0, nsFontMetricsGTK.cpp 3224 font.scale.outline.min.ja = 10, nsFontMetricsGTK.cpp 2969 font.scale.bitmap.min.ja = 16, nsFontMetricsGTK.cpp 2978 font.scale.bitmap.oversize.ja = 1.2, nsFontMetricsGTK.cpp 2989 font.scale.bitmap.undersize.ja = 0.8, nsFontMetricsGTK.cpp 3001 outline scaled font: -alias-helvetica-bold-i-normal--0-0-0-0-c-0-jisx0208.1983-0, nsFontMetricsGTK.cpp 3235 I believe alias-helvetica fonts are outline fonts, but somehow XFontList() returns two entries for each of them when it's asked to come up with a list of matching '-alias-helvetica-*-*-*-*-*-*-*-*-*-*-iso8859-1' : -alias-helvetica-bold-i-normal--17-120-100-100-c-0-iso8859-1 -alias-helvetica-bold-i-normal--0-0-0-0-c-0-iso8859-1 You can check this by comparing the results of the following: xlsfonts -fd '-alias-helvetica-*-*-*-*-*-*-*-*-*-*-iso8859-1'| grep 17 and xlsfonts | egrep 'alias-helvetica.*8859-1' | grep 17 The former output has -alias-helvetica-bold-i-normal--17-120-100-100-c-0-iso8859-1 but the latter does not. I think that means '-alias-helvetica-bold-i-normal--17-120-100-100-c-0-iso8859-1' is kind of 'bogus' and should be skipped. (I gave more details in my comments to bug 94327) My patch to bug 94327 (attachment 53094 [details] [diff] [review]) takes care of skipping this 'bogus' fonts. With these 'bogus' bitmap-unscaled fonts removed, I believe, Mozilla would pick genuine bitmap-unscaled '-adobe-helvetica' at 17px even with Brian's patch. Chris, why don't you check in both Brian's patch to bug 94327 and my additional patch (attachment 53094 [details] [diff] [review]) and see what happens? Another thing to check out is whether -alias-helvetica-* fonts have indeed *wrong* spacing (that is, Latin glyphs have unusually wide width). This can be easily checked with 'xfd'. If that's the case and Mozilla happens to choose one of them for Latin rendering, there's not much Mozilla can do. The font server is to blame (e.g. truetype font server backend for XF86 4.x has this problem) and only remedy is remove those fonts from fonts.dir. (see my comment dated 2001-10-04 1:14 to bug 102623)

--> ftang

give to shanjian

push to 1.01, but hope it can be resolved sooner.

This bug was logged when bug 94327 was first checked in. Because of time constraings the code for bug 94327 was backed out then later put in. Since there was no new discussion when the code for bug 94327 when back in I assume this is no longer a problem. Thus I recommend it be closed and if someone still finds it a problem it could be reopened.

I haven't seen it in a long time.

Since this does not appear to be an issue I'm closing this bug. If anyone sees this behavior kindly reopen it.

verified. Chris (reporter) doesn't see this.