font size 9px rounded down to 8px {font} {ll}

VERIFIED FIXED in M14

Status

()

defect
P1
critical
VERIFIED FIXED
20 years ago
14 years ago

People

(Reporter: erik, Assigned: erik)

Tracking

Trunk
x86
Windows NT
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] Must fix by 03/03 - dependent on 18136, )

Attachments

(2 attachments)

Assignee

Description

20 years ago
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.
Assignee

Updated

20 years ago
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M14
Assignee

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
Target Milestone: M14 → M13
Assignee

Comment 1

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

Comment 2

20 years ago
Fixed in the Jan 18th build.
Status: RESOLVED → VERIFIED
Assignee

Updated

20 years ago
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Assignee

Comment 3

20 years ago
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.)
Assignee

Updated

20 years ago
Target Milestone: M13 → M15
Assignee

Updated

20 years ago
Status: REOPENED → ASSIGNED
Erik: is the code which makes this dependant on a pref checked in or not?
Summary: font size 9px rounded down to 8px → font size 9px rounded down to 8px {font} {ll}
Assignee

Comment 5

20 years ago
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? 
Assignee

Comment 8

20 years ago
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.
Assignee

Comment 9

20 years ago
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.
Severity: major → critical
Keywords: beta1
Priority: P2 → P1
Target Milestone: M15 → M14
Assignee

Comment 10

20 years ago
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?
Assignee

Comment 12

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

Comment 14

20 years ago
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.
Assignee

Comment 16

20 years ago
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);

Comment 17

20 years ago
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.
Whiteboard: [PDT+]
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?
Blocks: 28766
Blocks: 21950

Comment 19

20 years ago
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)

Updated

20 years ago
Depends on: 18136
Whiteboard: [PDT+] → [PDT+] dependent on 18136

Comment 20

20 years ago
Must fix by 03/03 to make the beta1 train.
Whiteboard: [PDT+] dependent on 18136 → [PDT+] Must fix by 03/03 - dependent on 18136
Assignee

Comment 21

20 years ago
Pierre flipped the pref, so that we don't round by default now.
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: --- → FIXED

Comment 22

20 years ago
Text looks fine to me in the latest build. Fixed in the Feb 29th build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.