Change after 0.9.4 made 9pt and under fonts too small

RESOLVED WORKSFORME

Status

()

Core
CSS Parsing and Computation
RESOLVED WORKSFORME
17 years ago
16 years ago

People

(Reporter: Jeremy M. Dolan, Assigned: dbaron)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(10 attachments)

(Reporter)

Description

17 years ago
Pages with 8 or 9pt fonts got a LOT smaller between 0.9.4 and the trunk a few
days later, and has remained so. At that URL, IE5/6 and Mozilla 0.9.4 show all
of the text (form fields, headers, the submit button) much bigger. Netscape 4.7
does to but that's probably it not parsing the CSS right.

Linux only?
(Assignee)

Comment 1

17 years ago
What's the current story with our various minimum font size prefs?
(Assignee)

Comment 2

17 years ago
See also bug 30910.  But what exactly should I be seeing on the testcase (other
than it not crash my browser, which it just did)?

Comment 3

17 years ago
dup of bug 84884?
(Reporter)

Comment 4

17 years ago
> But what exactly should I be seeing on the testcase

compare font size vs. 0.9.4. 0.9.4 on linux renders it the same as IE5/6 on
windows. Post 0.9.4 trunk builds render it too small. Not just this page, any
page with 8 or 9 pt fonts.
> (other than it not crash my browser, which it just did)

Hrm, never did that for me. But unfortunatly I don't use that page much in
Mozilla, since after you log in, it's just gobs apon gobs of IE-only javascript.
Kinda shoddy coming from Oracle, I have to use it for work, though.

> dup of bug 84884?
I don't think so, that's about 0.9.1. This definatly appeared a few days after
0.9.4 branched.

Comment 5

17 years ago
It looks like it's Unix only.  I compared 2-months old trunk builds and more 
recent ones on Win98 and Mac but they don't show any difference in font size.  
The editable fields are much smaller in length (now comparable to what we have in 
IE) but that's a fix from Rod.
(Assignee)

Comment 6

17 years ago
The fonts I'm seeing on the above URL are nowhere near tiny.  They're larger
than normal.

Comment 7

17 years ago
Confirming. Some time after 0.9.4 small fonts got even smaller, to the point of
becoming unreadable in some cases.

Comment 8

17 years ago
Has it got to do perhaps with the font changes from bug 99010? I find the text
to some URL's to be unreadable as well.

Comment 9

17 years ago
Created attachment 53468 [details]
image demonstrating the problems. sidebar and image caption are the most visible ones.
(Assignee)

Comment 10

17 years ago
That tinderbox sidebar panel uses 'font-size: 8pt'.  Could something have broken
a minimum font-size threshhold?  rbs?

Comment 11

17 years ago
The minimum font-size limit isn't enforced by default -- it needs a pref. BTW,
Win2K is rendering the tinderbox fine, I will attach a screenshot (note: there
is a XP open issue with absolute font-sizes, e.g., <font size="-1">, c.f. bug
102805 which was filed by Mrten who also commented above, but it doesn't seem
connected to this one which is unit-related and seems to be specific to some
linuxes -- see 
bug 84884 which was recently resolved as WFM).


Comment 12

17 years ago
Created attachment 53505 [details]
Win32 rendition of tinderbox

Comment 13

17 years ago
Actually, I remember happy times when tinderbox looked the same under Linux (I'm
using Microsoft fonts).

Comment 14

17 years ago
please the environment variable NS_FONT_DEBUG=5, do a minimal run 
(eg: ./mozilla http://some.website.com/some_content.html), capture the output,
and attach it to this bug
(Reporter)

Comment 15

17 years ago
Created attachment 54192 [details]
NS_FONT_DEBUG=5

Comment 16

17 years ago
Created attachment 54255 [details]
NS_FONT_DEBUG=5 output with Tinderbox loaded

Comment 17

17 years ago
oops, could you redo this with NS_FONT_DEBUG=C

Comment 18

17 years ago
Created attachment 54278 [details]
NS_FONT_DEBUG=C output with Tinderbox loaded

Comment 19

17 years ago
I'd guess this is the interesting part:

> outline font:______ -microsoft-verdana-medium-r-normal--%d-*-0-0-p-*-iso8859-2
>                     desired=8, scaled=8, bitmap=0, nsFontMetricsGTK.cpp 2505
> scaled font:_______ microsoft-verdana-iso8859-2
>                     desired=8, scaled=8, bitmap=0, nsFontMetricsGTK.cpp 2536

Can you try using xfd to display 
 -microsoft-verdana-medium-r-normal--8-*-0-0-p-*-iso8859-2
and see if these are the glyphs you are seeing?

Comment 20

17 years ago
Yes, I see the same unreadable font.

BTW, all this seems like replay of bug #87055.

Comment 21

17 years ago
What I see is layout asking for an 8 pixel verdana font and the font code 
supplying an 8 pixel font.

thorgal: can you check your screen resolution?
Go to:

  Edit->Preferences->Fonts->"Display Resolution"->Other

and enter the mearurement.

Then see if layout asks for a larger font.

Comment 22

17 years ago
Well, it appears to have fixed the problem. I've just checked problematic sites
(CNN.com, tinderbox) and fonts are of proper size now. Hopefully it won't break
anything else.

Thanks.

Comment 23

17 years ago
based on these comments I'm marking the bug invalid.

If you see further problem reopen as appropiate.

Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
(Reporter)

Comment 24

17 years ago
Er... what was the fix? I don't have any microsoft fonts. Everything is still
small in todays build.

Comment 25

17 years ago
Jeremy: could you check you screen resolution also?
If the fonts are small could you redo the output with
NS_FONT_DEBUG=C 
(Reporter)

Comment 27

17 years ago
Re: res

Mozilla is set to use system resolution, xpdyinfo says:
  dimensions:    1152x864 pixels (390x293 millimeters)
  resolution:    75x75 dots per inch

Comment 28

17 years ago
Jeremy: I see it looking for a 9 pixel and getting an 8 pixel

Can you run this command and attacht the results:

> FindFont(a/0x0061), nsFontMetricsGTK.cpp 4046
>     FindStyleSheetSpecificFont, nsFontMetricsGTK.cpp 3577
>         familyName = helvetica, nsFontMetricsGTK.cpp 3590
>         TryFamily helvetica with lang group = x-western, nsFontMetricsGTK.cpp 
3525
>       TryLangGroup lang group = x-western, aName = *-helvetica-*-*, 
> nsFontMetricsGTK.cpp 3507
>       lang group = x-western, nsFontMetricsGTK.cpp 3973
>       iso8859-1 ffre = *-helvetica-iso8859-1, nsFontMetricsGTK.cpp 4003
>         TryNodes aFFREName = *-helvetica-iso8859-1, nsFontMetricsGTK.cpp 3416
>         load font adobe-helvetica-iso8859-1, nsFontMetricsGTK.cpp 2921
> bitmap font:_______ adobe-helvetica-iso8859-1
>                     desired=9, scaled=9, bitmap=8, nsFontMetricsGTK.cpp 2530

Lets see what size fonts you have. Can you run this command and attach the 
results:

  xlsfonts | grep adobe-helvetica | grep 8859-1
(Reporter)

Comment 29

17 years ago
Created attachment 54591 [details]
xlsfonts | grep -e adobe-helvetica -e 8859-1
(Reporter)

Comment 30

17 years ago
From what I understand of what you pasted, and your comments, it found an 8px
font and scaled it to 9px. But the source is requesting 9 pT, not pX. And what
I'm seeing is much smaller text, not pixelated unreadable text (a la Netscape 4)
due to scaling.

If I increase text size once (CTRL+KP_PLUS), I think that's the size I used to
see in 0.9.4, and about the size I see in IE.

I'm willing to accept this may be due to crappy fonts I have installed... Linux
isn't known for its high quality fonts, especially an old version of Slackware,
but there seem to be other issues here.

Comment 31

17 years ago
> From what I understand of what you pasted, and your comments, it found an 8px
> font and scaled it to 9px. But the source is requesting 9 pT, not pX. 

No scaling happened. The layer above the font subsystem asked for a 9 pixel
font. Point to pixel is handled above the font subsystem. The font subsystem
found the nearest font to be 8 pixel.  Your font list shows 8 and 10 pixel
fonts but no 9 pixel font. In the case of a tie it picks the smaller font.
That code has been in place since May 2000.

> what I'm seeing is much smaller text, not pixelated unreadable text (a la 
> Netscape 4) due to scaling.

The font subsystem appears to be doing as requested within the bounds of 
what it has to work with.

> If I increase text size once (CTRL+KP_PLUS), I think that's the size I used 
> to see in 0.9.4, and about the size I see in IE.

What size (point/pixel) is the page requesting?
(Reporter)

Comment 32

17 years ago
When I said source in my previous comment, I meant page source, not Mozilla
source. It's requesting 9 pt. Mozilla is rendering with what appears to be an 8
PIXEL font.

Comment 33

17 years ago
> Mozilla is set to use system resolution, xpdyinfo says:
>  dimensions:    1152x864 pixels (390x293 millimeters)
>  resolution:    75x75 dots per inch

A 9 point font on a 75 DPI system would be 9 pixel which is what layout
is requesting. Seems correct to me.

The font subsystem looked for a 9 pixel font and found an 8 and 10 pixel font.
It choose the 8 pixel font (nearest size, if tied then lower). Seems correct 
to me.

Jeremy: does anything here seem wrong to you?

Are you sure your resolution is 75 DPI (not 96)?
(Reporter)

Comment 34

17 years ago
My screen is 80.2x74.9 dpi. XFree86 is set to 75x75 and no one seems to know how
to change that, but it's fairly close anyhow.

> Jeremy: does anything here seem wrong to you?

What was the change after 0.9.4 that changed the way that page and others
display? Was the smallest font size Mozilla would honor lowered/removed? Can I
still set it with a hidden pref? That page and others that use 9pt fonts are
pretty much unreadable, and before they were fine.
(Assignee)

Comment 35

17 years ago
The change after 0.9.4 was probably my checkin to nsDeviceContextGTK.cpp:

revision 1.80
date: 2001/09/05 03:15:55;  author: dbaron%fas.harvard.edu;  state: Exp;  lines:
+4 -2
Make the "browser.display.screen_resolution" pref work again.  b=69205  r=bryner
 sr=waterson


What I'd like to do in the near future is make the pref work consistently across
platforms and then get the default value of the pref as part of the UI (yep,
it's not in the UI -- the default is max(96dpi,System Setting).  The max is that
way for a reason - many web pages were designed by ignorant web designers on
Windows systems with 96dpi logical resolution who assumed 7pt (for some faces)
and 8pt fonts were legible (which they aren't even for normal users at a logical
resolution of 75dpi, and certainly aren't for users with poor vision).

Comment 36

17 years ago
*** Bug 104747 has been marked as a duplicate of this bug. ***

Comment 37

17 years ago
try adding this to unix.js:

  pref("font.min-size.variable.x-western", 16);
  pref("font.min-size.fixed.x-western", 16);

Comment 38

17 years ago
Adding those lines did make the affected web page have bigger fonts, but it also
made the fonts in the user interface bigger than normal and pixilated.

Comment 39

17 years ago
No point sticking to these old prefs. Try this one instead (from bug 30910):
pref("font.minimum-size.x-western", 16); // or 10

This one is known to not suffer the problems that you mentioned above.
bstell, sounds like it is time to get rid of the old prefs and swicth to this pref
as it has no pending issues now.
QA Contact: ian
Summary: Change after 0.9.4 made 9pt and under fonts too small
(Reporter)

Comment 40

17 years ago
Don't use that build.
Restoring sum/qa/url
QA Contact: ian
Summary: Change after 0.9.4 made 9pt and under fonts too small

Comment 41

17 years ago
min-size is still in use.

Comment 42

17 years ago
I added pref("font.minimum-size.x-western", 16); to my unix.js and it took care
of the font being too small and isn't changing the font in the, but now the font
inside <PRE> tags has gotten much larger and in some cases is causing the text
to not fit in a viewing window horizontally.

Comment 43

17 years ago
16 is way too large for normal browsing - 9 or 10 might be better if you want to
keep the pref on for good.

Comment 44

17 years ago
10 doesn't solve the problem of the font being too small.  12 seemed to run all
the letters together, as if the space between them wasn't being included.  At 14
the text seemed a little distoreted, but the size was big enough, but at that
point the text in <PRE> tags is already too big.  Is there a way for the
monospaced fonts to be treated seperatly?

Comment 45

17 years ago
> Is there a way for the monospaced fonts to be treated seperatly?
No. It was decided in bug 61883 not to do so (but compelling reasons can lead to
a revision of the decision).

Seems that you need other fonts or a proper fix for this bug (since the
minimum-size itself is still under the effect of your original DPI problem).
Feel free to file a bug against dbaron (see comments of "2001-10-22 22:33") to
get the ball rolling for what he mentioned above.

Comment 46

17 years ago
I'm not familiar with the Mozilla codebase so I'm not really sure what the code
is that causes this problem.  Why do we need another bug besides this one?

I still don't understand why this one was marked invalid.  Are you saying that
the fonts are being displayed as the size they are asked to be, but we have
wrong expectations for what that should be?  Or is it that Mozilla is getting
the wrong dpi from the system and thus displaying the fonts too small?  ('You'
here is collective)

Comment 47

17 years ago
A combination of that.
-> Re-opening
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
*** Bug 108378 has been marked as a duplicate of this bug. ***

Comment 49

17 years ago
I recently reported a dup bug on this, as mentioned in the above comment.  I'm
seeing this problem really dink up my web site at http://www.testequity.com/ for
nearly all my fonts.  I'm running Mozilla on a FreeBSD laptop for testing.

On 0.9.4 this site renders exactly as I would expect it too.  Anything later
than that, to include an 11/7 build, goofs things up.  I tried working some of
the suggested prefs tweaks mentioned here, but they aren't really helping. 
While they do make the fonts bigger, the relative sizes to eachother are wrong.

For a reference, Communicator 4.78 still renders this page properly on FreeBSD,
if you no longer have an older version of Moz installed.  In particular, note
the fonts along the left hand menu and the ad copy in the middle of the page. 
The default font size I have in the style sheet is 10pt, and the menu on the
left is set to an 8pt.  It almost starts looking right when you zoom the text to
120%.

I'll be the first to admit I'm not a style sheet expert, and I may have an error
in what I've done.  Thing is, the latest builds of Mozilla are the only ones
presently having problems with my styles.  rbs was kind enough to do up a
viewable link to this style sheet for review.

http://webtools.mozilla.org/web-sniffer/view.cgi?url=http://www.testequity.com/Styles/TQSite.css

I'd be more than happy to modify this style sheet off-line with any
recommendations that come across this bug to see if it can be narrowed down a
bit.  Additionally, I can do up some screen shots if requested.

Comment 50

17 years ago
> I tried working some of the suggested prefs tweaks mentioned here, but they
> aren't really helping. While they do make the fonts bigger, the relative sizes
> to eachother are wrong.

The DPI problem really needs its fix since the minimum font-size stuff is not
meant to be a substitute for that problem.

Comment 51

17 years ago
i'm seeing the same on:
https://bankieren.rabobank.nl/rib/qsla.htm?Abs-Pad=rib/rib.cgi&Niv=3&Aanmeld-rdn=971&X009=&X010=0020&X015=REKSAL
(a banking site)

the text is unreadable small (OK with IE, NS 4.77)
changing font prefs has no effect.

PC linux (RH 7.1)
0.9.5

Comment 52

17 years ago
*** Bug 104850 has been marked as a duplicate of this bug. ***

Comment 53

17 years ago
Some DPI pointers: bug 83060, bug 83061

Comment 54

17 years ago
Watch out if the fix for bug 104576 also fixes this. There was apparently a
problem in nsDeviceContext[GTK | Xlib]::SetDPI(PRInt32 aDpi).

Comment 55

17 years ago
The fix for bug 104576 was checked in last night. I downloaded this morning's
build and the problem still exists. Did the fix actually make it into this
morning's build?

Comment 56

17 years ago
*** Bug 107260 has been marked as a duplicate of this bug. ***

Comment 57

17 years ago
I don't know if this helps or not, but hitting ctrl + on sites where the fonts
are too small seems to bring them up to the proper (0.9.4) size. Of course, then
all the sites that don't share this problem display far too big.

Ars Technica http://www.ars-technica.com does a great job of demonstrating this
problem. The links on the nav bar on the left side of the page display the same
in 0.9.4 and 0.9.5+ because their size is defined in pixels. The text of the
news items and the headlines appear smaller in 0.9.5+ than they do in 0.9.4
because their size is defined in points. This is true even though they are
defined > 9pt (thus this bug seems to affect more than the summary would indicate).

Is Mozilla just having some problems with figuring out the proper point sizes
with arial / Verdana / helvetica style fonts?

Comment 58

17 years ago
Created attachment 59066 [details] [diff] [review]
patch; prefer fonts over 8 pixels

This code selects the nearest size between two fonts. The rule has been to
pick the smaller size when they are equal distant from the correct size.
Because in the past the line height was not measured but assumed that the
font would be the correct size an oversized glyph could lead to text
overlapping with the text in the line above or below. Since we now measure
the text the overlap problem has been solved (bug 99010) and either size
would be okay.

This patch continues the previous behavior as before (minimal disturbance)
with the one change that when the smaller size is small (<9 pixel) chose
the larger size.

Comment 59

17 years ago
this issue people are seeing has several parts:

 1) Older moz code got the desired size wrong and this has been fixed
    leading to requests for font size 9 pixel; ie: an old bug that made
    moz look good has been fixed.

 2) When picking font we always leaned toward the smaller font to
    avoid text overlap. This problem has been fixed hence the choice of
    a smaller font is not always a better choice.

The patch is something of a (minor) hack but since many people find they have
8 pixel and 10 pixel verdana fonts and a 10 pixel far more readable (since
it is about 50% bigger) than an 8 pixel the patch avoids the tiny font.

I'm not especially excited about this patch but it is a minor change and people
have been complaining for some time.
(Reporter)

Comment 60

17 years ago
Would eaither a much better selection of bitmaped fonts, or a
truetype/opentype/type1 font in the correct face solve the issue as well?

It's good to fallback as gracefully as possible, but perhaps Linux distributions
should be made aware from the mozilla project what fonts are sorely needed. No
other apps really need a specific font face and size, except web browsers, where
you need to match fonts with what the designer had in mind (yelch).

Mozilla's font rendering is already 1000 times better then NS4.x's on Linux, but
if fonts are the bottleneck now, maybe blizzard and others can get something
done in that area.

Comment 61

17 years ago
> Would eaither a much better selection of bitmaped fonts, or a
> truetype/opentype/type1 font in the correct face solve the issue as well?

Yes, better fonts would help.

At small sizes outline scaled with/without anti-aliasing produce
mediocre results. Hand tuned fonts look the best.

Right now blizzard is suggesting we wait until Xft is usable and as such
has been vetoing my attempts to add FreeType2 without Xft.

Sadly, by the time Xft is ready I will be long gone and no one will be around
that understands how the font system works. Something will get put in by 
someone that does not understand how the font system work. I feel very sorry 
for the i18n engineer that gets stuck with trying to keep it working. But,
hey, it won't be my problem.
(Reporter)

Comment 62

17 years ago
> by the time Xft is ready I will be long gone and no one will be around
> that understands how the font system works

Start documenting now :)

> But, hey, it won't be my problem.

It's open source... it can be. :)

Comment 63

17 years ago
I'm a little confused by some of the comments on this bug.  I'm seeing this 
problem on a site asking for 8pt Arial font, and I have the actual Microsoft 
fonts installed on this FreeBSD machine.  0.9.4 renders fonts perfectly in 
line with what a user sees on a Windows box.  Something changed in the Mozilla 
code, not in the fonts.

Why can't the dpi code go back to the way things were at 0.9.4 until other 
factors not allowing Mozilla to work properly get corrected?  I guess I'm just 
not seeing the up side to the changes that were made, only an unusable browser 
here.

Comment 64

17 years ago
> Why can't the dpi code go back to the way things were at 0.9.4 until other 
> factors not allowing Mozilla to work properly get corrected? 

It seems like a bad idea to reintroduce a bug into the font code to cover
up a bug in some other part of the code.

Comment 65

17 years ago
> It seems like a bad idea to reintroduce a bug into the font code to cover
> up a bug in some other part of the code.

Since when?  If a bug fix causes additional problems down the line because 
other components weren't yet ready, you pull the first bug fix.  Especially 
true of the new bug created is worse than the first.  Prior to the last "fix" 
to the font code Mozilla appeared to be flawless in it's rendering for any of 
the pages I wrote or browsed to.  As of 2 milestones later Mozilla still can't 
get a plain Arial font right when called from a stylesheet.  This has kept me 
at 0.9.4 due to the problem, because everything after that provides me totally 
unreliable, and unreadable text.

Aside from the principle of the matter, why can't the new font code introduced 
post 0.9.4 be reverted back and have it set aside until the xft or freetype 
issues are sorted out?

Comment 66

17 years ago
Why would an engineer want spend time to make the font code function 
incorrectly?

You need to be pushing to get the other code fixed.
(Assignee)

Comment 67

16 years ago
Could the people who are seeing this problem see if they have the
"browser.display.screen_resolution" pref set to a non-default value?  If so,
could you try removing the line from your prefs.js (in
~/.mozilla/<Profile-Name>/<random letters>/prefs.js" to see if it fixes the
problem?  See comment 35.

Comment 68

16 years ago
I see the problem and I have no browser.display.screen_resolution
 setting in prefs.js at all. I'm using the 2001121006 build.

Comment 69

16 years ago
Using build 2001122207 here now, and it looks like this problem is now gone. 
Well, gone if you go into the prefererences and change the font resolution
setting to 96dpi.  Mind you, this setting only really takes effect after a
restart of Mozilla.  This had me puzzled for a bit as the browser screen "looks"
like it's refreshing with the new dpi setting.

I'd hesitate to actually call this bug fixed as I'm pretty sure this laptop I'm
running on here isn't set to 96dpi.  Certainly its importance in getting fully
resolved has dropped quite a bit in my mind.

Comment 70

16 years ago
I just tried the same thing that #69 suggested. I didn't need a restart. Once I
switched to 96 dpi, all the sites that I have problems with started displaying
correctly again. This is with 0.9.7. FWIW, xdpyinfo reports that my screen
resolution is set to 81x81. Was there some DPI checkin recently?

Comment 71

16 years ago
My real screen DPI is 92 and I have set that in mozilla too, but I still need to
use user_pref("font.minimum-size.x-western", 13); to get decent size in
tinderbox sidebar and on some sites.

Comment 72

16 years ago
Andre, have you tried moving the setting to 96dpi just to see?  Also, which 
sites are you still having problems with?  Be curious to see if the rest of us 
still see those same problems.

Comment 73

16 years ago
Michael, no it didn't make a difference. Even if it did it would have been wrong
since my Xservers setting is 92 dpi. I will attach two screnshots comparing how
the sidebar looks with and without the minimum-font pref.

Comment 74

16 years ago
Created attachment 62662 [details]
Screenshot of tinderbox WITHOUT font.minimum-size.x-western set

Comment 75

16 years ago
Created attachment 62663 [details]
Screenshot of tinderbox WITH font.minimum-size.x-western set to 13

Comment 76

16 years ago
We have clearly seen that some users would prefer that the glyphs
not be below a minimum size. We should address this.

Why are the glyphs so small?

What should we do to help the user?

I believe that this is the URL the screens shots came from:
http://tinderbox.mozilla.org/SeaMonkey-Ports/panel.html

Here is part of the source for this: 

 <style>
   body, td { 
          font-family: Verdana, Sans-Serif;
          font-size: 8pt;
        }

The glyphs in the 1st attachment 62662 [details] are at least 10 pixels tall.

If the screen resolution is 81 DPI then wouldn't 

  8 point => 8 * 81/72.5 = 9 pixel?

Assuming I am calculating this correctly, doesn't this mean that the glyphs 
in the 1st attachment are already *bigger* that the HTML/CSS specifies?

If so, then perhaps we should consider a UI to let the user easily
specify minimum font size.

Perhaps the issue is that web content that is tuned for a 96DPI display
is too tight for a 75-81 DPI display.

Perhaps the issue is that the web content designer's system is mis-configured
and what looks good on the designer's system looks bad on a correctly
configured system.

Comment 77

16 years ago
Andre, assuming that the shot in question is specifying an 8pt font, that
graphic you attached has exactly what I would expect out of an 8pt font. 
Originally this bug was due to fonts being so small that the letters literally
fell in on each other and were totally unreadable.

Unless there's something I'm missing, it seems that you're asking for more of a
feature, or usability, request in dealing with small fonts like Konqueror has. 
The real question is whether or not the fonts look different when viewed on a
Windows box with IE or Netscape 4.7x, or if the fonts are legibly displayed.
(Assignee)

Comment 78

16 years ago
It seems like many of the comments indicate that this bug no longer exists. 
Because of that, and since this bug is way too confusing anyway (it doesn't
describe a single bug, certainly), marking as WORKSFORME.  Bugs that still exist
should be filed as separate bug reports.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 79

16 years ago
May I recommend: since users will continue to "confuse the issue"(1) 
we have a bug open that this one references. Lacking this we should
expect this bug to continue being reopened.

1:
Users assume that when they see the new/smaller fonts that the new size
is a bug since they (justifiably) don't like the new size. The confusion is 
that the older/bigger fonts were actually wrong and the newer/smaller fonts
are (nearer) the document specified size.
You need to log in before you can comment on or make changes to this bug.