155063 - Consistency in font sizing in Chimera

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, defect)

Description

[Jeffrey Cho]

The following observations are premised on my belief that in Chimera, as in
Mozilla supposedly, relative font sizes are determined using the same em
settings by which headings are presently defined, so in terms of size:

h1 = font size 6 = xx-large = 2em
h2 = font size 5 = x-large = 1.5em
h3 = font size 4 = large = 1.17em
h4 = font size 3 = medium = 1em
h5 = font size 2 = small = 0.83em
h6 = font size 1 = x-small = 0.67em

In addition, font size 7 (HTML 3.2) is equivalent to 3em.

Based on the above, and assuming that Chimera will eventually allow users to set
their preferred font sizes from a given range, I have these observations to make:

a.
Heading level H5 (presently set to 0.83em) will render more accurately at base
font size 12 (base 12), if its font-size is set to 0.833em instead. (The added
decimal place does make a difference.) With this change, headings will appear
consistent throughout the range of font settings.

b.
Font size 7 (HTML 3.2) renders incorrectly at base 13 & 12; it should be 3em, or
exactly 3 times the base font size.

c.
Font size 5 (HTML 3.2) and x-large (CSS) renders incorrectly at base 15 & 13; it
should be 1.5em.

d.
Font size 4 (HTML 3.2) and large (CSS) renders incorrectly at base 14 & 13; it
should be 1.17em.

e.
The default minimum font size should be set to 9px, ie:
pref("font.minimum-size.x-western", 9); to allow fonts defined as xx-small to
render correctly at fonts settings higher than 14, as well as the fact that the
Mac can render fonts properly down to a size of 9px.

Comment 1

[Jeffrey Cho]

Attachment: headings/font sizes comparison with em settings

This html page demos the comparison between headings and relative font sizes
with em settings and the inconsistencies arising at certain base font size
settings in Chimera

Comment 2

[Greg K.]

Jeffrey, is this not a Mozilla bug?

Comment 3

[Jeffrey Cho]

It may very well be. But I have been unable to trace a similarly reported bug in
Mozilla.

Comment 4

[Greg K.]

Jeffrey, I meant that if you're reporting something that is the same in Chimera
and Mozilla, then this bug should be changed to Mozilla instead of Chimera.

Comment 5

[Jeffrey Cho]

Sorry, Greg. I haven't a copy of Mozilla with me to check if this is the case.
Should I switch the product name then?

Comment 6

[Greg K.]

Jeffrey, yes, but only if you're sure it happens in Mozilla also. Problems with
web content layout usually belong on Mozilla, but not always.

Comment 7

[Mike Pinkerton (not reading bugmail)]

sounds like a moz bug

Comment 8

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

->style

Comment 9

[Felix Miata]

Attachment: attachment screenshot in 1.4 in Mandrake 9.1 96 DPI 1024x768 16px adobe-helvetica default

Note size mismatches in large and x-small groups. 1.583em != 1.5em and .75em !=
.67em. Some sizes actually match due to available font size step granularity.

Comment 10

[Felix Miata]

Attachment: attachment screenshot in 1.5a in OS/2 120 DPI 1024x768 16px mswbfnts arial (ttf) default

Note size several mismatches: 1.583em != 1.5em, 1.25em != 1.17em !=
large/size=4, .833em != .83em, & .75em != .67em != x-small/size=1. OS/2 here is
serving up fonts with inconsequential size granularity.

Reporter, maybe you should supply a screenshot on a current/recent Chimera
version.

Note that at the sizes at issue, 16px and under default, sizes other than e.g.
%, px, pt or em, are provided not by the percentage scale at
http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsStyleUtil.cpp#330
but by the tables at (standards mode)
http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsStyleUtil.cpp#265
and (quirks mode)
http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsStyleUtil.cpp#297


In both these tables you can see that for many defaults, xx-small = x-small and
even = small. There is a proposal to change this in bug 187256.

Comment 11

[Felix Miata]

Attachment: testcase for 16px default

Except as noted, the sizes are according to:
http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsStyleUtil.cpp#265

Comment 12

[Felix Miata]

Attachment: testcase screenshot in 1.4 in Mandrake 9.1 96 DPI 1024x768 16px adobe-helvetica default

Note here that all sizes match except the sub-default % sizes, which is
expected, since table values are used for the others rather than the scale
percentages, and the small table values don't match the scale at all.

Comment 13

[Felix Miata]

Attachment: testcase screenshot in 1.5a in OS/2 120 DPI 1024x768 16px mswbfnts arial (ttf) default

This is similar to the previous attachment, except that the scale percentage
for large/size=4 also doesn't match.

Comment 14

[Samuel Sidler (old account; do not CC)]

Is this still a problem in Camino?

Comment 15

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

I don't see what leads to the expectation that the named font sizes (which were probably a bad idea to begin with) should be the sizes used for HTML h1..h7.  So I think our behavior here is fine.