102805 - fonts displayed too small compared to netscape 4.7

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, defect)

Description

[Mrten]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4+) Gecko/20011001
BuildID:    2001100103

since the landing of bug 99010, small fonts (size="2" and the likes) display a
LOT smaller than before, close to unreadable. 

i'll attach some screenshots.

Reproducible: Always
Steps to Reproduce:
1.open said URL with mozilla built AFTER 28 september
2.
3.

Actual Results:  too small

Expected Results:  bigger fonts

Comment 1

[Mrten]

Attachment: This is a screenshot displaying above URL with mozilla. As you can see fonts are nerly unreadable. (haven't touched my font settings, i even installed fresh!)

Comment 2

[Mrten]

Attachment: screenshot from netscape 4.7 displaying the same page.

Comment 3

[Mrten]

Attachment: and the same page on IE (another computer/resolution unfortunately)

Comment 4

[rbs]

The rendering comes from the fact that they are using:
<tt> <!-- i.e., -moz-fixed @13px  -->
  <font face="courrier" size="2"> <!-- i.e., size=2 of 13px -->
     ... text...
  </font> 
</tt>
Removing the <tt> causes the basesize to come from the default variable font
as in Nav4.7/IE.

hixie, want to comment?

Comment 5

[Mrten]

The same seems to be happening for <code> segments, see mozillazine.org's
buildcomments for October 3. (http://www.mozillazine.org/build_comments)

relevant code seems to be:

<font face="Verdana, Arial, Helvetica, sans-serif" size="-1">
  <code> 
   user_pref ("nglayout.debug.disable_xul_fastload", false);
  </code>
</font>

i'm going to attach YAS (yet another screenshot)

Comment 6

[Mrten]

Attachment: YAS from mozillazine's build comments using <code>

Comment 7

[rbs]

It is possible to match the renderings of Nav4.x by using the variable size as
the basesize. What has been buuging me is what will then happen with the case
size="3", say :

<tt><font face="courier" size="3"> text </font></tt> <br>
<font face="courier" size="3"> text </font>

If the code is changed to always use the variable size as the basesize, then
from the way the extrapolation is internally done, these two will now render
indentically. In Nav4.x they are rendered differently.

Comment 8

[Hixie (not reading bugmail)]

It's <font>, it's legacy, we should just do our best to emulate Nav4/IE without
breaking the Todd font scaling thingy whatsit.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

->rbs

Comment 10

[rbs]

Got more understanding into what is happening, this was a subtle one...

In Nav4.x:
<code>, <tt>, etc, (i.e., equivalent of -moz-fixed) are mapped to "Courier". 
This font is a _bitmap_ font (that's the keyword here...). It exists in a fixed 
number of pre-determined sizes. As it is usual with bitmap fonts, two different 
logical font-sizes can be mapped to the same physical bitmap font-size during 
font lookup. Result: size="2" or size="1" happen to appear bigger because the 
available bitmap size for Nav4.x to pick is simply bigger.

In Mozilla:
"Courier" is first re-mapped to "Courrier New" because the second is known to
be "better" -- this is the same aliasing process that is used to map "times" to 
"Times New Roman" for example, see:
http://lxr.mozilla.org/seamonkey/source/gfx/src/nsDeviceContext.cpp#391
So Mozilla will pass the computed font-size from size="2", or size="1" down to 
GFX, and because "Courrier New" is what is now used and is a TrueType font, the 
font is selected as-is and the resulting size is simply smaller. Because <tt>, 
<code>, etc, use "-moz-fixed" which in reality is mapped to "Courrier New", the 
same scenario applies with these elements.

If in the markup, "Courrier" is changed to "Courrier New", then Nav4.x and 
Mozilla render at the same smallish font-size. I am going to attach a testcase 
which shows that Mozilla renders "Courrier" and "Courrier New" identically
while Nav4.x renders them differently.

There is no bug here -- the "fix" would be to stop Mozilla from aliasing
"Courier" to "Courrier New", and to use "Courier" as the default fixed-width 
font.

Comment 11

[rbs]

Attachment: testcase - "Courier" vs. "Courier New"

Comment 12

[rbs]

Attachment: testcase - "Courier" vs. "Courier New"

Comment 13

[rbs]

Not sure how compatibility can be achieved under these circumstances.
Marking WONTFIX unless someone has a clue as to what to do to get out of the 
hook.

Comment 14

[rbs]

Attachment: screenshot of the rendering for interested non-Win2 users

Comment 15

[Mrten]

i just checked your testcase in IE, and noticed that they either do not render
<tt> or that they don't adjust the size of the font. 

should <tt> indeed be rendered smaller than the 'normal' font?



anyway, i think i have two options to get out of the hook:

* an user setting 'anything below this fontsize is unreadable, don't go there'

or, perhaps better but more work:

* you say that 'courier' is mapped to 'courier new'. the main difference i notice 
when i look at the testcase , in courier, is that 'size=3' is rendered the same 
size as 'size=2' and 'size=1'.

isn't it possible, when mapping, that the limitations of the mapped font are
taken into account as well? 

when courier is not able to display fonts < (say) 10px, 'mapped-courier' 
shouldn't be able to do display < 10px?

Comment 16

[Mrten]

Attachment: IE screenshot of testcase (for interested non-win32 users :)

Comment 17

[rbs]

> should <tt> indeed be rendered smaller than the 'normal' font?
That's by design - and there are prefs to change various font-sizes, in this
case: user_pref("font.size.fixed.x-western", 16) brings you to what IE is doing. 
(I have been advocating over at bug 61883 for most of these prefs to be 
exposed).

>anyway, i think i have two options to get out of the hook:
>
>* an user setting 'anything below this fontsize is unreadable, don't go there'

Already there (but still to be exposed as part of bug 61883 too - 
see bug 30910 - Pref for minimum font size). You can add this to your prefs.js:
user_pref("font.minimum-size.x-western", 40);
to block the font-size from going below 40px or some other sensible value...

>or, perhaps better but more work:
>
>* you say that 'courier' is mapped to 'courier new'. the main difference i
> notice when i look at the testcase , in courier, is that 'size=3' is rendered 
> the same size as 'size=2' and 'size=1'.

This is a consequence of the fact that the lookup in Nav4.x sticks in the bitmap 
context as I explained above (different logical sizes may end up with the same 
physical size because there are limited options to choose from).

>isn't it possible, when mapping, that the limitations of the mapped font are
>taken into account as well? 

The point of the mapping is exactly to overcome these limitaions. Indeed, it
is assumed that consumers know what they are doing, and if they asks for a
font-size < 10px and there is a font for that, GFX uses it without questions.
Maybe users really want a font-size < 10px and are glad that the code achieves
that. Maybe they expected to stick to "Courier", in which case another bug 
should be filed to ask that Mozilla stops treating "Courier" as "Courier New".

Comment 18

[Mrten]

> That's by design - and there are prefs to change various font-sizes, in this
> case: user_pref("font.size.fixed.x-western", 16) brings you to what IE is 
> doing. (I have been advocating over at bug 61883 for most of these prefs to be 
> exposed).

are they all in about:config? i think i missed font.minimum-size.* there...

the problem with the current pref-system is that there is no central database
where you can find ALL usable prefs...

but that is something for another bug, i guess :)

thanx for the pointers...

> The point of the mapping is exactly to overcome these limitaions. Indeed, it
> is assumed that consumers know what they are doing, and if they asks for a
> font-size < 10px and there is a font for that, GFX uses it without questions.

ah, the mapping is not just done because it is 'vector' instead of 'bitmap'. ok.

> Maybe users really want a font-size < 10px and are glad that the code achieves
> that. Maybe they expected to stick to "Courier", in which case another bug 
> should be filed to ask that Mozilla stops treating "Courier" as "Courier New".

well, if the user asks for it...  why would the browser not do what the user
asks for? i guess that is a design decision, a bit late perhaps to start a
discussion anew :)

Comment 19

[rbs]

I am not sure what was the reason of aliasing 'Courier' to 'Courrier New'. I
recollect that there was a time when bitmap fonts were not supported at all in 
Mozilla (Windows). I guess that this my have been the reason. But the support of 
bitmap fonts has been added a long time ago now, and perhaps the alias is not 
justified anymore.

I tried removing the alias and that caused Mozilla to render the tescase exactly 
as Nav4.x and IE. Here is the patch for that:

Index: nsFontMetricsWin.cpp
===================================================================
RCS file: /cvsroot/mozilla/gfx/src/windows/nsFontMetricsWin.cpp,v
retrieving revision 3.135
diff -u -r3.135 nsFontMetricsWin.cpp
--- nsFontMetricsWin.cpp        2001/11/06 08:00:15     3.135
+++ nsFontMetricsWin.cpp        2001/11/08 08:49:26
@@ -2672,7 +2672,6 @@
   { "times new roman", "Times New Roman" },
   { "arial",           "Arial" },
   { "helvetica",       "Arial" },
-  { "courier",         "Courier New" },
   { "courier new",     "Courier New" },

   { nsnull, nsnull }

(BTW, since the font code had internally switched to case-insensitive 
compararisons due to some other troubles with font names, that table looks 
overkill to me now).

Comment 20

[rbs]

As I noted earlier, maybe users really want a font-size < 10px and are glad that 
the code achieves that. Maybe they expected to stick to "Courier". Which of 
"font-family" or "font-size" is more important? That's the dilemma in removing 
the alias.