There is a piece of code in the Windows GFX that rounds the font size in the same way as Netscape 4.X. The problem is that this code ends up rounding 9px down to 8px, which is illegible.

Removed the rounding code after discussing with Troy and testing on various "Top Sites" (such as Yahoo).

Fixed in the Jan 18th build.

I have put the rounding code back in, since removing it caused problems. (HTML font sizes 1-7 were too large, and it became difficult to see the effect of other changes like buster's min line height fix.)

Erik: is the code which makes this dependant on a pref checked in or not?

Yes, the pref code has been checked in. The default is to round. To turn it off: user_pref("font.size.nav4rounding", false); By the way, I did some more analysis of Peter's changes last night, and I found that the original check-in was indeed intended to round font sizes in the same way as Nav4. Then he added some other code that was supposedly intended to round the font size for "proper Windows font scaling", but it was commented out and the Nav4 rounding was still in effect. Then he commented out the Nav4 rounding, and turned on the "proper Windows" rounding, but even that is wrong in my opinion, because that one also rounds 9px down to 8px. I've sent some email to Peter to ask about this history, twice, but no response so far. Cc'ing RickG and SteveC, in case they are still in touch with Peter.

Here is a test case test case which demonstrates this issue: http://www.bath.ac.uk/%7Epy8ieh/m/font-size-rounding-code.html I will attach an image which shows Mozilla's current (2000021916) behaviour with the pref turned off, the pref turned on (default), Nav4's behaviour on Windows, and MSIE5's behaviour on Windows. With the pref turned off, we render: font-size: 9px as 9px text font-size: 8px as 8px text (antialiased) <font size=1> as 10px text With the pref turned on (rounding), we render: font-size: 9px as 8px text font-size: 8px as 8px text (antialiased) <font size=1> as 10px text Navigator 4 on Windows renders: font-size: 9px as 8px text font-size: 8px as 8px text (antialiased) <font size=1> as 9px text (but spaced out a little) Internet Explorer 5 renders: font-size: 9px as 9px text font-size: 8px as 8px text (antialiased) <font size=1> as 9px text (but spaced out a little) I'm *guessing*, but I may be wrong, that The Todd Fahrner Algorithm (as given in bug 18136) will fix the problem with <font size=1> displaying at a bigger size than in legacy browsers. However, it should be noted that the rounding code itself is NOT the cause of this discrepancy! I seem to recall it was being blamed for larger fonts at some point. Other bugs which say <font size=1> is too big or suchlike are: bug 14033, Extra whitespace between <FONT size=1> lines bug 21920, <font size=1> rendered too big bug 18756, Tables being drawn incorrectly, maybe <font size=1> too big After verifying that those bugs are indeed all caused by the same root cause, I will mark them as duplicated of some other bug... but what is the master bug for tracking the problem of <font size=1> being too small?

I just received 2 long emails from Peter, regarding font size rounding on Win. I need some time to read and understand them, but I thought I'd let the Cc'ees on this bug all know about it. I will paste the info into this bug report later.

Peter explained that his "proper Windows rounding" code was intended to round the point size down to the nearest integer, since he believed that all Windows apps did this. The Windows API documentation says something about using a routine called MulDiv to compute the font size (lfHeight), and that MulDiv takes integers as arguments. He also said that IE4 and Word rounded point sizes down. However, I just tried it in WinIE5, and it did not round point sizes down to the nearest integer. So I think we need to reinstate Peter's original Nav4-compatible rounding code, by uncommenting it, and commenting out the "proper Windows rounding" line. This would give our pref font.size.nav4rounding its intended meaning. This would also solve all of our current <font size="1"> problems. RickG, I hereby ask for permission to check the fix into M14. Later, we need to get Pierre to check in his code based on Todd's proposal. That is a separate issue.

The Top 100 sites look good with the Nav4 rounding code reinstated, but the UI's fonts (menus, URL bar) look too small... I tried bumping up the UI font from 3mm to 9pt, and that was better, but that would mean making a cross-platform change to compensate for a Windows change... The UI fonts' 3mm would look better if we didn't round the font sizes at all, but to make that the default, we would need Pierre's new code based on Todd's proposal... Maybe we should just wait for Pierre's code to land.

Erik wrote: > So I think we need to reinstate Peter's original Nav4-compatible rounding > code, by uncommenting it, and commenting out the "proper Windows rounding" > line. This would ... solve all of our current <font size="1"> problems. Would it? i.e., Have you checked or is this a guess? Could you provide a screenshot of: http://www.bath.ac.uk/%7Epy8ieh/m/font-size-rounding-code.html ...with the True Nav4 Rounding Code enabled?

I'm guessing that it would fix the <font size="1"> problems. I'll attach a screenshot...

I'm running NT4, not Win98, so no anti-aliasing, by the way.

It does indeed fix the problem. So we have a problem... either we wait for Pierre's code, which should presumably get <font size=1> to work the same as legacy browsers, while at the same time working without the rounding code, or we have <font size=1> bigger than legacy browsers, or we have inconsistent UI sizes. My vote is with waiting for Pierre's code and having larger <font size=1> in the meantime. (i.e., status quo) When we check in Pierre's code, I suggest we should also disable rounding by default at the same time (right?). Bug 18136 is the one which covers Pierre's coding of Todd's algorithm.

No, initially, Pierre will check in his code with the pref defaulting to true, i.e. the old HTML 1-7 system. Then we will test it with the pref set to false, to see if the new code is ready to be turned on by default: user_pref("font.size.nav4algorithm", false);

ccing - hyatt, hangas, ben, matt, german, syd We will take this change for beta - putting on PDT+ radar for beta1. We want all to review it when it goes in ASAP though to make sure UI looks good.

Erik: Right -- so Pierre's initial check-in of Todd's algorithm should have no effect except if you change the prefs, right? So if I understand this correctly the options are as follows: | Pierre's Coding of Todd's Algorithm | | Not checked | Checked in | | in (as now) | but disabled | and enabled | ---------+----------------------------+-------------+ Peter's | * <font> bad | <font> good | Rounding | UI good | UI good | (as now) | 9px bad | 9px bad | ---------+----------------------------+-------------+ Nav4 | <font> good | <font> good | Rounding | UI bad | UI bad | | 9px bad | 9px bad | ---------+----------------------------+-------------+ No | <font> bad | <font> good | Rounding | UI good | UI good | | 9px good | 9px good # | ---------+----------------------------+-------------+ where: * = where we are now # = where we would like to go Is that a correct summary of the situation?

Sorry for spam - I assume everyone is already aware that this bug affects many px sizes (odd sizes up to 13px, then even sizes thereafter), not just 9px. 18px arial is particularly bad. I made up a <a href="http://www.leafdigital.com/mozilla/pxsize.html">test case</a> with the actual current behaviour compared to a gif of IE5 output. (from Win NT)

Must fix by 03/03 to make the beta1 train.

Pierre flipped the pref, so that we don't round by default now.

Text looks fine to me in the latest build. Fixed in the Feb 29th build.