87055 - fonts look terrible in newer mozilla builds

Status: RESOLVED DUPLICATE of bug 95184

(Core :: Layout, defect)

Description

[greg]

some days ago there was something changed in the font handling of mozilla.

now the fonts look really terrible on most sites.(try www.mozilla.org)

changing the standard fontsize to 14 helps, but bigger fonts doesn't look very good.

the solution is, I think
1. setting the standard fontsize(e.g. for new profiles) to 14
2. doing something that bigger fonts look better

this problem could be linux or X-only.

Comment 1

[greg]

when I set standard font size to 15 all seems to look perfect.

so forget about this 'big fonts are ugly'

so my suggestion now would be to set this standard fontsize to 15..

Comment 2

[kmike]

confirming, just pulled and built the tree, seems like default font size in
linux has changed. switch to 90% font size (view->text size menu) helps a lot -
everything looks like it was before change.

Comment 3

[Chase Tingley]

Marking NEW.  Build 2001061914 was ok, but starting with Build 2001062008 things
were ugly (all on Linux). 

Comment 4

[James Green]

OK, I'm seeing this, or at least, sort of.

Basically, before whatever changed, the default size for proportional fonts was
16pt. Bloody huge. No idea why. On every new profile I had to change it to 12pt,
which is much more reasonable.

Now, today I saw that fixed-width fonts looked terrible. In fact as terrible as
they look in Opera 5 (linux). All other fonts appear normal. Entering the fonts
preference panel I saw that monospace fonts were set to 13pt; quite why such an
off size I have no idea, but the important bit is that I changed it to 12pt,
reloaded this bugzilla page, and now the monospace fonts in bugzilla look as
they did.

I'm sending this to preferences, since I think something was checked in to
change or add a font size pref and we're all seeing the size as bad rendering;
perhaps they can set a more sensible size such as 12pt.

Comment 5

[James Green]

bah, this time reassign.

Comment 6

[R.K.Aa.]

Attachment: sample of regressed font scaling (.gif, 11K)

Comment 7

[sairuh (rarely reading bugmail)]

->layout? or, style system? i don't think this is a prefs problem, per se... i
don't think i see this on mac or win32 --but do others?

marc, do punt as needed.

Comment 8

[Marc Attinasi]

Could this be the changes to unix.js that bstell made on the 19th? I see a block
in there that sets some sizes, and I don't understand the changes so CC'ing.
I'll try reverting that file, but I'm still building latest Linux.

Comment 9

[Dan Rosen]

Ok, adding lots of keywords. "Oh boy, the milestone is about to close... Gotta
get my patch in... Haven't tested on Linux yet. Ohhh, nobody uses Linux, I'll
just check in." *Grrr*.

Haven't gotten a chance to test backouts yet, but I think the fixes to either
74889 or 83658 are likely to have caused this.

Comment 10

[tenthumbs]

It's the patch from bug 74889.

The test at line 2971 in nsFontMetricsGTK.cpp is incorrect. It assumes
that a non-zero point_size or pixel_size implies a non-scaled bitmap
font. Not true for XFree86. See bug 34242 for what happens if you ask X
the wrong question.

You might want to look at bug 46415 where I propose a different test
method.

Comment 11

[tenthumbs]

Forget that last bit. I was wrong.

Comment 12

[Dan Rosen]

Attachment: [screenshot] another more dramatic before/after comparison

Comment 13

[Marc Attinasi]

OK - assigning to bstell - anyway I look at it, he is better able to tend to
this than I am

Comment 14

[kill this account]

this is a linux only issue.

this is related to the checkin for bug 74889

there have been a series of bugs complaining that we pick
fonts and glyphs that are much too large or much too small.

I provided per-language font scaling controls with different
settings for outline scaled and bitmap scaled fonts.

I set the controls fairly agressively to try and use the correct
size when possible rather than the previous values which used
a bitmap font if it was within 80% to 180% (almost 2x) of the 
desired size.

people may want to try setting the controls in unix.js:
http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/unix/unix.js#143

set the minimum pixel size for an outline font:

  pref("font.scale.outline.min",      6);

set the minimum pixel size for an bitmap scaled font:

  pref("font.scale.bitmap.min",       12);

choose a bitmap (non-scaled) font instead of a bitmap scaled font if the
bitmap font's size is within these precentages:

  pref("font.scale.bitmap.undersize", 90);
  pref("font.scale.bitmap.oversize",  110);

Comment 15

[kill this account]

setting these should give the old sloppy behaviour:

in unix.js change

  pref("font.scale.bitmap.undersize", 90);
  pref("font.scale.bitmap.oversize",  110);

to

  pref("font.scale.bitmap.undersize", 80);
  pref("font.scale.bitmap.oversize",  180);

Comment 16

[greg]

works perfectly for me!

what about checking in this?

Comment 17

[Christopher Blizzard (:blizzard)]

I've seen this on my laptop which doesn't have the nice fonts that I have on my
desktop installed.  My laptop is probably more representitive of what people
have installed on their system.  I'd rather have the slop installed back in by
default and have the fonts off sized rather than looking as bad as they do.  At
least they are readable if they are a little off sized.

Fonts suck on unix.  We can't make everyone happy all of the time.  At least we
have the ability to change the behaviour now.

Comment 18

[gabriel]

Please please change it back to how it was !! Mozilla looks awful with the new
fonts !!

Comment 19

[chris hofmann]

going to put this on the 0.9.2 radar until we figure out what to do.

Comment 20

[Frank Tang]

calm down. when bstell check in that code, he build in a lot of risk management 
mechanism with in that code. So now the only thing we need to tune is some good 
value in unix.js without touching cpp file. 

The root of the problem is Unix bitmap font scaler suck and TrueType is not 
popular enough yet. 

bstell did perform a lot of testing before he check the code in. However, since 
everyone one may have different font installeration, we may not see exactly what 
other people see. 

Let's calm down and work together to propose a good value in the unix.js. I will 
ask bstell on IRC today and next week. 

Comment 21

[Dan Rosen]

Given how close we are to the milestone, and since this shows up everywhere
(browser, mail, im, etc.) I'd suggest simply reverting unix.js's values back to
80/180 as soon as possible... Maybe we can come up with some good tweaks. I'll
play with the values and see if I can find a good pair.

Comment 22

[Frank Tang]

Is the problem font.scale.bitmap.undersize or font.scale.bitmap.oversize ?

Comment 23

[Dan Rosen]

Seems like both, to some extent. I'm trying with undersize=80 (the old value)
and oversize=110 (the new value), and normal serif type looks fine, but
typewriter still looks broken. I'll keep playing with the values...

Comment 24

[Dan Rosen]

Oops, the problem with my monospace font was that it was set to 13pts in prefs.
Setting it to 12pt (where it doesn't have to scale) fixes things for me. I think
values of 80/110 should be fine. Patch coming :)

Comment 25

[Dan Rosen]

Attachment: [patch] Set font undersize on unix from 90 to 80.

Comment 26

[Dan Rosen]

FYI, Japanese, Chinese, and Korean pages all look fine like this. A good
testcase for multiple languages is http://www.debian.org (see the bottom of the
page for translations).

Comment 27

[kill this account]

we may well decide to go back to the old sloppy setting.

But before we throw up ours hands and give up 


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 


   WE SHOULD AT LEAST LOOK TO SEE IF THERE IS A BETTER RANGE


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 



if there isn't a better value then lets go back to the old sloppy values

Comment 28

[Dan Rosen]

bstell: huh? isn't 80-110 a better range than 80-180? see my patch...

Comment 29

[kill this account]

Dan: yes 80-110 should produce more accurate sizes. 

Different people will prefer different choices.  Lets get a collection of 
input then try to pick the best overal choice (leaning of course toward the 
naive user as the experienced users can tweak this to their hearts content).

Comment 30

[kill this account]

to see which fonts are selected set the environment variable NS_FONT_DEBUG to 9

Comment 31

[Frank Tang]

both bstell and my system cannot reproduce the problem in mozilla.org and 
news.wideopen.com . We see some other font quality issue but that have nothing 
to do with this bug because that problem can also be reproduced by 061914 build 
which before bstell land his change. 

Let bsteall and me walk to Dan Rosen's cube to find out details.

Comment 32

[Dan Rosen]

Attachment: [shell output] Font listing with and without 100dpi fonts

Comment 33

[Frank Tang]

After walk to dan's cube, we are now understand the issue better.
In my system, I include both 75dpi and 100dpi in the font path (xset -q show 
unix/-1 and that include all the fonts dir under /usr/X11R6/lib/X11/fonts )
and for courier/helvetica/times, I have the following size of bitmap fonts:
8,10,11,12,14,17,18,20,24,25,34 
and in dan's system, he do not include 100dpi in his font path (he explicit set 
75dpi in his xset fp) and he miss 
11,17,20,25,34
these size are from the 100dpi directory.

Comment 34

[Dan Rosen]

So we figured out that one reason I'm seeing this is my utter lack of fonts. It
seems RedHat's default config (unless I tweaked it without remembering) doesn't
include 100dpi fonts (RPM name: XFree86-100dpi-fonts).

I've attached the output from xlsfonts with and without 100dpi fonts installed.
You can see that with 100dpi fonts installed, I have a 17-point Times font. My
font size pref is 16-point Times, and 17-point is within 110% of 16 (the bounds
would be 14.4 to 17.6), so we use that font without scaling. Without 100dpi
fonts, the closest choices I appear to have are 14 and 18 point, neither of
which are in the 90%-110% range, so we have to scale, hence the ugliness.

It seems like the best thing to do would be to determine what fonts we get by
default on the popular linux distributions and find the lowest common
denominator... But ummm, back in the real world, I wouldn't know what to do
given the time constraints.

Comment 35

[Dan Rosen]

Note: I still do see some ugliness, even with 100dpi fonts installed. With my
default font size set to 14 instead of 16, normal text looks good, but headers
show up chunky (see the top of tinderbox, for example: <font size="+3"><b>,
which I think is the equivalent of <h1> in our UA stylesheet). It'd be nice to
get as many sizes of the default font as possible looking good...

Comment 36

[kill this account]

Attachment: patch; adjust so we do not bitmap scale Latin1 on standard Redhat dist

Comment 37

[Dan Rosen]

r=dr. 20% should be a reasonable margin of error imho.

Comment 38

[kill this account]

Attachment: html showing text at sizes 8-49px

Comment 39

[Christopher Blizzard (:blizzard)]

r/sr=blizzard

( I hate X fonts. )

Comment 40

[kill this account]

(I 'm working to move moz away from bitmap fonts to server based 
 outline fonts and client based outline font (aka: render))

Comment 41

[tor]

a=tor for 0.9.2 branch and trunk checkin

Comment 42

[kill this account]

checked in trunk and branch

Comment 43

[Miloslaw Smyk]

I'm not sure this is fixed yet. Small fonts still look wrong - too small
actually. I'll be attaching an example in a moment.

Comment 44

[Miloslaw Smyk]

Attachment: Tinderbox sidebar with its font wrongly scaled.

Comment 45

[Boris Zbarsky [:bzbarsky]]

*** Bug 87608 has been marked as a duplicate of this bug. ***

Comment 46

[Francisco León]

A little font fix-up how to:
Go into your XF86Config file
Make sure the font section looks like this:
Section "Files"
    RgbPath     "/usr/X11R6/lib/X11/rgb"
    FontPath   "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
    FontPath   "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
    FontPath   "/usr/X11R6/lib/X11/fonts/misc/:unscaled"
    FontPath   "/usr/X11R6/lib/X11/fonts/Type1/"
    FontPath   "/usr/X11R6/lib/X11/fonts/URW/"
    FontPath   "/usr/X11R6/lib/X11/fonts/sharefont/"
    FontPath   "/usr/X11R6/lib/X11/fonts/freefont/"
    FontPath   "/usr/X11R6/lib/X11/fonts/Speedo/"
    FontPath   "/usr/X11R6/lib/X11/fonts/100dpi/"
    FontPath   "/usr/X11R6/lib/X11/fonts/75dpi/"
    FontPath   "/usr/X11R6/lib/X11/fonts/local/"
    FontPath   "/usr/X11R6/lib/X11/fonts/misc/"
EndSection

You may have not all fonts listed here. I just have the first line checked in,
with  FontPath   "unix/:-1" afterwards

The fonts are loaded on a priority basis, the ones  on top receiving higher priority

Fix #2:
Go into /usr/lib/X11/xdm/Xservers and put this:

:0 local /usr/X11R6/bin/X -deferglyphs 16 -dpi 100 <other-stuff-here>
Fix #3 (optional) if you are using kde, make sure to have the newest version,
with qt 2.3, and in the control center in the style section, turn on anti-aliasing

This improves mostly X stuff, not mozilla, but people may find this interesting.
Currently i have courier size 16 at monospace, and times at size 18
I saw the ugly fonts on recent builds too. I will try the proposed fixes right now

Comment 47

[tenthumbs]

I can't say this bug is really fixed. If I have both 75dpi and 100dpi fonts then
whole blocks of sizes come out the same, e.g. 29pt to 40pt are identical for me.
If I make just one of the font sets available then mozilla goes to scaled bitmap
fonts which is no good either. Yes, the "normal" sizes look ok but "title"
sizes, i.e. somewhat larger than normal, look poor.

Comment 48

[R.K.Aa.]

XF86Config is not used for full fontpaths on RedHat systems!!

If you want to swap the mentioning of 75/100 dpi fontpaths around on a RH system
(6.* or 7*) instead change it in /etc/X11/fs/config

The difference between 75 and 100 dpi fonts is similar to the "small" and
"normal" fonts on Windows. I run at 1280x1024 on a 17" monitor and personally i
prefer the "small" variant (75dpi fontpaths mentioned first). To avoid that
small fonts get TOO small, i lock small fonts to a minimum size in prefs.js:

user_pref("font.min-size.variable.", 10);
user_pref("font.min-size.variable.x-western", 10);

Note that while most systems come with 75dpi path mentioned first, Debian has
recently changed to mention 100dpi first. What suits the individual is partly
personal taste and partly screensize/resolution. If you run at 1024x768 on a 17"
monitor, 100dpi fonts will appear huge. I generally find them too big for
comfort even at 1280x1024.

Comment 49

[R.K.Aa.]

tenthumbs: the native bitmap fonts that are primarily USED on linux (as long as
one exists) are the ones whose fontpath is mentioned *first*, like Francisco
León points out. That's where X will go fishing for a match first.

The reason some look "jagged" is because there are simply to few of them
provided to cover for all sizes. So some "inbetweeners" and large fonts can
happen to come out as smooth as a brick.

In addition most distro's don't provide any fonts.alias to help the user out.
(At least they didn't use to.) Mozilla goes a long way to cover for this
phenomena, but if you want to tune X fonts for perfection, that is traditionally
done "by hand". You can for instance "cross-alias" so you call 100dpi fonts at
those larger sizes, even if you normally use 75dpi. Better yet: Use truetype
fonts. Some stuff (under revision) on how to do it all:

http://home.c2i.net/dark/linux.html#ttf
http://home.c2i.net/dark/linux.html#fuzzy

Comment 50

[Francisco León]

New unix.js settings don't fix the ugly fonts for me, because my regular fonts
have always worked fine. The only font that was affected in the new builds to my
eyes is the monospace font (adobe-courier)
It does not look that bad but it could look better. Attaching screenshot of this
window.
Take a special look in how the hyphen --- is drawed. Other letters like d and b
also look strange.
The hyphen is drawed "ok" but it was a lot bigger on earlier builds

Comment 51

[Francisco León]

Attachment: Monospace font, other fonts look fine

Comment 52

[Frank Tang]

Attachment: What adobe-courier 16 looks like in xfd

Comment 53

[Frank Tang]

[e-mail] 2001-06-25 09:46 :
>I can't say this bug is really fixed. If I have both 75dpi and 100dpi fonts 
then
>whole blocks of sizes come out the same, e.g. 29pt to 40pt are identical for 
me.
Sure, because even you have 100dpi, you still only have one more bitmap font >
20px. So what mozilla can do is either use that font unscaled (so you see 29pt
to 40pt as the same size) or scaled that to different size with ugly looks. The
ugly bitmap font scaler is not implemented INSIDE mozilla but the X servers
which have been ship more than 8 years. There are no fix for that unless you
have 1) true type font, or 2) a better bitmap font scaler in your x server.

>If I make just one of the font sets available then mozilla goes to scaled 
bitmap
>fonts which is no good either. Yes, the "normal" sizes look ok but "title"
>sizes, i.e. somewhat larger than normal, look poor.
Compare to the 6/18 builds before bstell land the bitmap scaler code, does that
make any difference ? If no, that mean that fix does not contribute any positive
neither negative impact to that.

Francisco Leo'n 2001-06-25 10:27:
>The only font that was affected in the new builds to my eyes is the monospace
>font (adobe-courier)
What you show is exactly what adobe-courier should look like in 16 pt.
If you don't like how to '-' look, file bug against adobe about the glyph in the 
courier font. But remember this type face have been used on the X windows 
for more than 10 years already.

Comment 54

[kill this account]

(Note: the text in the "Additional Comments:" text field in attachment 39938 [details]
does not show up when displayed on Linux)

Francisco: I cannot get my system to make the particular 'd' and 'b' glyphs
shown in your attachment. I'd like to see what fonts are being loaded so 
would you set NS_FONT_DEBUG=11, run moz as follows, and attach
the output to this bug report?

  ./mozilla http://bugzilla.mozilla.org/show_bug.cgi?id=87055

thanks

Comment 55

[kill this account]

oops, I meant "displayed on Windows" instead of "displayed on Linux"

Comment 56

[kill this account]

Miloslaw: It looks to me like the side bar is asking for an 8 pixel font.

  <head>
  <meta HTTP-EQUIV="Refresh" CONTENT="300">
  <style>
  body, td { 
          font-family: Verdana, Sans-Serif;
          font-size: 8pt;
        }
      </style>
  </head>
  <body BGCOLOR="#FFFFFF" TEXT="#000000" 
          LINK="#0000EE" VLINK="#551A8B" ALINK="#FF0000">
  <a target='_content' 
  href='http://tinderbox.mozilla.org/SeaMonkey-Ports/'>SeaMonkey-Ports is open, 
  6/25&nbsp;15:01</a><br><table border=0 cellpadding=1 cellspacing ...


and the code is supplying an 8 pixel font:


  outline font:______ -ult1mo-verdana-medium-r-normal--%d-*-0-0-p-*-iso8859-2
                    desired=8, scaled=8, bitmap=0, nsFontMetricsGTK.cpp 2404
  scaled font:_______ ult1mo-verdana-iso8859-2
                    desired=8, scaled=8, bitmap=1000000000, 
aStretch->mOutlineScaled=1
                    xlfd =   
  -ult1mo-verdana-medium-r-normal--8-*-0-0-p-*-iso8859-2
                    , nsFontMetricsGTK.cpp 2464
  loaded -ult1mo-verdana-medium-r-normal--8-*-0-0-p-*-iso8859-2

Comment 57

[Francisco León]

Attachment: Font list being loaded

Comment 58

[Francisco León]

Font list on XFree 4.0.3, mandrake 8, kde 2.1.1 with antialiasing and qt 2.3,
and using the mozilla-fonts package that comes with mandrake 8, and contains
lots of fonts in the dirs:
/usr/X11R6/lib/X11/fonts/mozilla-fonts

Comment 59

[Francisco León]

Why would the text in attachment 39938 [details] not show up in windows? It's an image
Am i on painkillers? :)

Comment 60

[kill this account]

> ---- Additional Comments From [e-mail] 2001-06-25 09:46 ----
> ... whole blocks of sizes come out the same, e.g. 29pt to 40pt are identical
> for me.

That's is the way the code has been working for a long-long time. 

The old code worked like this:

  find nearest bitmap (call this 'b')
  if (b >= 80% desired size) or (b <= 180% desired size) 
    use bitmap (non-scaled)
  else 
    scale 

(Note: bitmap scaled fonts were not distinguished from outline scaled fonts)

So a 34px font *could* be used from 18px to 42px. You probably did see the
34px font below 29 because your system has fonts in the 20-30 range.

 The new code works like this:

  find nearest bitmap (call this 'b')
  if (b == desired size)
    use bitmap (non-scaled)
  else if (have outline scaled font) and (b != desired)
    use outline scaled font
  else if (b >= undersize_pref% desired size) or (b <= oversize_pref% desired
size) 
    use bitmap (non-scaled)
  else
    use bitmap scaled (ugly)

Comment 61

[kill this account]

(its a NS 4.7x PNG bug)

Francisco: could you attach a screen shot of this:

  xfd -fn -adobe-courier-medium-r-normal--16-*-0-0-m-*-iso8859-1 &

Comment 62

[kill this account]

oops, got the logic wrong:
(should have been  "if (b >= 80% desired size) && (b <= 180% desired size)"
 instead of        "if (b >= 80% desired size) or (b <= 180% desired size)"

(corrected) old logic:

  find nearest bitmap (call this 'b')
  if (b >= 80% desired size) && (b <= 180% desired size) 
    use bitmap (non-scaled)
  else 
    scale 



(corrected) new logic:

  find nearest bitmap (call this 'b')
  if (b == desired size)
    use bitmap (non-scaled)
  else if (have outline scaled font) and (b != desired)
    use outline scaled font
  else if (b >= undersize_pref% desired size) or (b <= oversize_pref% desired
size) 
    use bitmap (non-scaled)
  else
    use bitmap scaled (ugly)

Comment 63

[kill this account]

(dang, hit the submit too soon)

(corrected-corrected) new logic:

  find nearest bitmap (call this 'b')
  if (b == desired size)
    use bitmap (non-scaled)
  else if (have outline scaled font) and (b != desired)
    use outline scaled font
  else if (b >= undersize_pref% desired size) && (b <= oversize_pref% desired
size) 
    use bitmap (non-scaled)
  else
    use bitmap scaled (ugly)

Comment 64

[Francisco León]

Attachment: Screenshot of the whole courier font

Comment 65

[Francisco León]

Attachment: Screenshot of the whole courier font

Comment 66

[Francisco León]

Darn bugzilla buzzed the attachment. Sorry about that
Am i just complaining too much? It looks somewhat ok but the "b" letter still
looks "recharged" in its left side

Comment 67

[R.K.Aa.]

xfd has nothing to do with Mozilla - it just an X font-display applet.

Comment 68

[Francisco León]

He may have wanted to know if mozilla was loading the font in a bad way so he
wanted to see how X would draw it by itself, i dont know :P

Comment 69

[R.K.Aa.]

Oh.. i thought *you* had misunderstood something, since it sounds like you
expect mozilla to improve on fonts that look bad to begin with.

Comment 70

[kill this account]

Attachment: xmag of adobe courier 16 glyphs b and d

Comment 71

[kill this account]

The b and d are from your adobe-courier 16px font

Isn't that what is supposed to happen?

Comment 72

[Francisco León]

dark: no, i expect xfree to improve those ugly fonts :)
brian: i dont know, i guess the only way for me to know is to get an older fuild
and do a screenshot from it

I have also noticed some more bugs in font rendering but these have been present
always. Sometimes the fonts looks jagged and when you hightlight them with the
mouse the jaggies get fixed. Has someone noticed this? Has a bug been filed
already? If not tell me to get some screens right away

Also when writing mails (they get written with the courier font) sometimes when
highlighting some lines of text and combining scrolling and deleting blocks of
them, the text "dissapears" or appears cut in half until you highlight them again.

Please tell me if both of these bugs have reported already and if they are
really the same bug (to file only 1 if this is the case)

Comment 73

[Francisco León]

This is the "second bug" i am talking about
Attaching 2 screenshots
The first one shows a jagged first line, with some dirt below some words. The
window gets messy. Look at that straight line above the yahoo text! Not even a
drunk would see that line straight

Now look at the second one. The straight line is fixed, the dirt in the middle
(above "gracias") is cleaned
Look at the first line. Words that contain a p and a g show up complete and
nice, without broken sections

Comment 74

[Francisco León]

Attachment: Ugly and dirt message window with courier font

Comment 75

[Francisco León]

Attachment: Same window after highlighting (cleans it)

Comment 76

[Dan Rosen]

Francisco: Please file a new bug on the issue you're describing. Thanks.

Comment 77

[Francisco León]

bug 87738 was filed due to font breaking 

Comment 78

[Francisco León]

I did a special test. I installed 0.9.1 on /usr/local/mozilla91
Came here and saw my typing and other text. It looks great!
 
Exited and came back here with may 23's build. Looks ugly
However i cant make a screenshot of this. Anytime i do this both images get
a little screwed, maybe due to compression. unix.js file is very different
in both builds

So i copied the 0.9.1 unix.js on top of the new one and came back here (right
now) and guess what: it still looks ugly

So, to me, the new unix.js patch below does _not_ fix the problem

Please consider reopening this

Comment 79

[kill this account]

Francisco: the previous unix.js will not help as it does not have the any
of the new prefs. As mentioned earlier in this bug report you can 
get the old bitmap scaling thresholds by changing:
  pref("font.scale.bitmap.undersize", 90);
  pref("font.scale.bitmap.oversize",  110);
to
  pref("font.scale.bitmap.undersize", 80);
  pref("font.scale.bitmap.oversize",  180);
in unix.js. 

To say something is "ugly" is not specific enough for me to be able to work 
on. There is no way for me to proceed. Hence, screen captures are very 
important.

The screen capture attachments 40015/40015 look like a layout problem, not a
font problem. However, if you put the url in this bug I will see if I can
duplicate the same behavior on my system.

Comment 80

[Francisco León]

Brian: Like i said , 0.9.1 looks perfect, like dark's attachment on bug 87738
and 0.9.1+ looks jagged. As you could see in xmag in my attachments, letters are
not all at the same level, with ugly letters v, b, etc.

So i wanted to attach you a 0.9.1 and a 0.9.1+ of the same text, but gimp screws
up the image quality on them. Any recommendation of what format to use to make
WYSIWYG screens?

Comment 81

[Francisco León]

Yes! I was able to get 2 nice shots. The first one is how 0.9.1 looks in courier
font (perfect) and the second one shows how 0.9.1+ looks (even with the new
unix.js file!)
This should suffice to say the bug does not look fixed to me. Without touching
anything but the unix.js file in 0.9.1+ to try and get good results, this is was
it get. Screenshots following

Comment 82

[Francisco León]

Attachment: Clean looking 0.9.1

Comment 83

[Francisco León]

Attachment: Clean looking 0.9.1

Comment 84

[Francisco León]

Please discard attachment 40085 [details] 
Another one coming up

Comment 85

[Francisco León]

Attachment: Ugly looking 0.9.1+

Comment 86

[Francisco León]

Ok that's it. Look at the hyphens --- to compare how ugly the new one looks to
the old one. Look at the b, the ", in fact, all letters!
What did happen with that font?

Comment 87

[kill this account]

Probably the page asked for a adobe-courier 16px font and the code now gives 
a outline scaled adobe-courier 16px font instead of a adobe-courier 17px bitmap 
font.

Please run wiht NS_FONT_DEBUG=9 and attach the output

eg:
$ setenv NS_FONT_DEBUG 9 
$ ./mozilla http://bugzilla.mozilla.org/show_bug.cgi?id=87055 2>&1 | tee moz.out

If you want to disable outline/bitmap scaled fonts over bitmap fonts set 
"font.scale.outline.min" and "font.scale.bitmap.min" to some high number like
43:

eg: in
http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/unix/unix.js#144

    pref("font.scale.outline.min",      43);
    pref("font.scale.bitmap.min",       43);

and live with wrong sized but better looking glyphs.

Comment 88

[Francisco León]

Attachment: Debug info requested, mozilla 0.9.1+

Comment 89

[Francisco León]

Attachment: Debug output, mozilla 0.9.1

Comment 90

[Francisco León]

I included an extra attachment of same debug output of 0.9.1 so you could see
the difference between the 2. I think you were right. New build is putting 16
size font first and old build is getting 17 loaded up first.

So, what's the conclusion? I must also say that the commit button looks jagged
in 0.9.1 too, until i click it, as i exposed in attachment 40082 [details]

Comment 91

[kill this account]

> So, what's the conclusion? 

When a correctly sized bitmap is available we use it and it looks as
good (or bad) as before.

When a correctly sized bitmap is not available we have a choice:

 1) wrong sized (but better looking) bitmap

 2) right sized (but so-so looking) outline scaled bitmap

I would really like to see the X world using better font technology.
Users that care can:

 1) set the "font.scale.outline.min" to effectively disable outline scaling
 2) add better outline fonts
 3) add more bitmap sizes.

Thus, right now I am leaning toward right sized outline scaled fonts as this
will encourage the transition to better fonts.

Comment 92

[Francisco León]

pref("font.scale.outline.min",      43);
pref("font.scale.bitmap.min",       43);

this fixes THIS problem, but creates a new one:
whenever i see "bug xxxxx", it shows up on size 43
so this fix is no good for me

Why, why can't we get the fonts looking like 0.9.1? Why the change?

Comment 93

[kill this account]

Is your question: 

   "Why use the requested size font instead of some nearby size?"

Comment 94

[Miloslaw Smyk]

In response to Brian Stell 2001-06-25 15:17:

Yes, the sidebar may be asking for size 8 font, but why does it render it so
poorly? I am attaching a screenshot of how gfontsel renders

-microsoft-verdana-medium-r-normal-*-8-*-*-*-p-*-iso8859-2

It definitely looks much better - and actually is identical to mozilla 0.9.1
rendering of this font.

Comment 95

[Miloslaw Smyk]

Attachment: how the font that's wrongly rendered looks in gfontsel

Comment 96

[kill this account]

Could you add an attachment (screen capture and moz.out with NS_FONT_DEBUG=9)
for this:

> whenever i see "bug xxxxx", it shows up on size 43

Comment 97

[kill this account]

Miloslaw: Probably the microsoft font is nicer looking than the ult1mo font

  -ult1mo-verdana-medium-r-normal--8-*-0-0-p-*-iso8859-2
  -microsoft-verdana-medium-r-normal-*-8-*-*-*-p-*-iso8859-2

Right now we do not have a way to specify one foundry over another.
(Can that be done in the CSS?)

Could you try ordering your font path to put the microsoft font earlier
in the font patch?

Comment 98

[Francisco León]

Never mind. I had:
pref("font.scale.bitmap.oversize",  120); instead of 180 ( i just updated to
today's build)

I put back the line with the 43 and the font looks good again, and "bug xxxxx"
looks fine
This fixes my problem.
Commit button still looks jagged, but as you know this has been marked as a new bug

Comment 99

[Miloslaw Smyk]

Brian,

The only *-verdana-* I have here is the Microsoft one. It is shown correctly (at
size 8) by gfonsel and incorrectly by mozilla from these newer builds. Exactly
the same font is looking ok in 0.9.1

Comment 100

[Francisco León]

That would mean fonts are getting loaded wrong by mozilla?
That's what i have been experimenting all this time.

You should try the unix.js fixes described by brian (the 43 size thing)
that should fix it

Comment 101

[kill this account]

> You should try the unix.js fixes described by brian (the 43 size thing)
> that should fix it

Setting the scaling min to 43 effectively *disables* scaling which is *not* the 
same as fixing it.

Miloslaw: what is your "Display Resolution" set to?
(Edit->Preferences->Fonts)

Could you set the environment variable NS_FONT_DEBUG=9, capture moz's output
when displaying this page, and attach it to this bug report?

thanks

Comment 102

[Miloslaw Smyk]

Attachment: debug output when displaying broken sidebar's tinderbox

Comment 103

[Miloslaw Smyk]

First, the "43" trick did not help here.

My "Display Resolution" is set to "system setting" (75dpi), but I've also played
with setting it to other values. Above 75 DPI bigger fonts kick in and sidebar
problem is fixed (sizes are like in 0.9.1), but then menu font is too big.

Another hint: when using gfontsel and selecting verdana-8, font information box
looks like follows:

Requested Font Name:
-microsoft-verdana-medium-r-normal-*-8-*-*-*-p-*-iso8859-2

Actual Font Name:
-microsoft-verdana-medium-r-normal--9-90-72-72-p-46-iso8859-2

Comment 104

[kill this account]

can we get an image of:

  xfd -fn -microsoft-verdana-medium-r-normal--8-*-0-0-p-*-iso8859-2

Comment 105

[kill this account]

What does this mean:

> Requested Font Name:
> -microsoft-verdana-medium-r-normal-*-8-*-*-*-p-*-iso8859-2
> 
> Actual Font Name:
> -microsoft-verdana-medium-r-normal--9-90-72-72-p-46-iso8859-2

Comment 106

[Miloslaw Smyk]

Attachment: xfd -fn -microsoft-verdana-medium-r-normal--8-*-0-0-p-*-iso8859-2

Comment 107

[Miloslaw Smyk]

Brian, I don't know much about X way of handling fonts. I can only suspect that 
"Requested Font Name:" is something that the app asked for and "Actual Font
Name:" is something it was handed.

But this is as good as anyone's guess.

Comment 108

[Chris Petersen]

Based on the comments provided, marking verified

Comment 109

[Francisco León]

Brian: with the "43" workaround, i get big fonts on this page:
http://getright.com/beta45.html
scroll down until you see [url1]

Comment 110

[Francisco León]

also when someone types an unix dir in my mail (/home/something) font looks
extra big

Comment 111

[kill this account]

Francisco: please attach moz output with NS_FONT_DEBUG=9

Comment 112

[Francisco León]

Attachment: Attachment of big text in getright page

Comment 113

[Francisco León]

Attachment: Debug output requested

Comment 114

[Francisco León]

I can't reproduce the /home/dir big text

Comment 115

[kill this account]

Attachment: patch; user pref to forget if a font is an outline font

Comment 116

[Colin Blake]

*** Bug 90034 has been marked as a duplicate of this bug. ***

Comment 117

[Boris Zbarsky [:bzbarsky]]

*** Bug 93379 has been marked as a duplicate of this bug. ***

Comment 118

[Morten Brix Pedersen]

Sorry, but can someone please do a quick sum up of what the fix is for this?
Pages look TERRIBLE now - I just upgraded from 0.9.1 to 0.9.3, and I'm forced to
stay with 0.9.1 until I know how to fix it.

I also think this issue should be stated in the release notes...

Comment 119

[Morten Brix Pedersen]

Attachment: Slashdot on my machine with 0.9.3...

Comment 120

[Randell Jesup [:jesup] (needinfo me)]

Based on the comments here (and a new patch from the patch author being added,
and recent dup's from 0.9.3, reopening.  At the very least this is quite
confusing, and the controls are not user-visible.  The result is that user
reaction is "Mozilla looks horrible in X!" out of the box, and they can't figure
out how to fix it.

Comment 121

[kill this account]

Morten: would you try the following change:

In unix.js change

   pref("font.scale.bitmap.min", 12);

to

   pref("font.scale.bitmap.min", 16);

Comment 122

[Francisco León]

The only way i can get my fonts to look like 0.9.1 did is:
pref("font.scale.outline.min",      43);
pref("font.scale.bitmap.min",       43);
pref("font.scale.bitmap.undersize", 80);
pref("font.scale.bitmap.oversize",  180);

However, that breaks some webpages and some mails that come on my inbox with the
text /home/something in it

Now this would be a lot harder to fix
I still dont understand why the code was changed and the changes not reversed
when this regression appeared. It KILLS the monospace font. We have enough
problems on linux in fonts to resolve this one

Comment 123

[kill this account]

I believe there is more than one issue reported in this bug and I want to
address those without all the existing clutter in this bug report.

I believe that the issue seen in attachment 44589 [details] is bitmap scaling.
I opened bug http://bugzilla.mozilla.org/show_bug.cgi?id=95184 to address this.

I believe the issue raised by Francisco León is outline scaling.
I opened bug http://bugzilla.mozilla.org/show_bug.cgi?id=95183 to address this.

Please follow the discussion in those bugs.



*** This bug has been marked as a duplicate of 95184 ***