I think you are not quite interpreting font-size correctly on Windows 95. You should have access to exact fonts, so the inlinetest should pass. Everything's a little off. It looks to me that what you are doing for, say, a 22px font, is getting the font that Windows calls 22px, and then finding its real height (say, 24px), and using that (as you should) in later calculations. However, I think you should be using the font that is really 22px (from highest glyph top to lowest glyph bottom). I think erik@netscape.com may have been working on this, judging by his posts: http://lists.w3.org/Archives/Public/www-style/1999Mar/0096.html http://lists.w3.org/Archives/Public/www-style/1999Mar/0105.html This problem also shows up in the test http://www.fas.harvard.edu/~dbaron/csstest/linebox4 where the yellow stripes are slightly too thick.

Whatever you do, don't cause a regression in: http://www.webstandards.org/css/opera/lineheightdemo1.html which is currently correct.

Some more data from dbaron: I set GECKO_USE_COMPUTED_HEIGHT=1 and the inlinetest is still a little bit off (not as much). Image at: http://www.fas.harvard.edu/~dbaron/misc/it_uch.gif On another note, the computed height changes seem to occur on everything, and always biased the same way: 240 instead of 285 (Times) 360,390 (Times) 200,240 (Times) 216,240 (Verdana) 240,270 (the font in http://www.fas/~dbaron/csstest/ ) 204,225 (FONT element in http://www.mozilla.org/ ) This is what I was saying about funny stuff on Windows - it could be useful for debugging 4234.

The following test case also shows problems (if my memory is correct, since I'm don't have a build right now): http://www.fas.harvard.edu/~dbaron/csstest/emunit

Note that the problem to which David is referring is (presumably) not the inheritance issue (see bug 3116, fixed today) but the sizing bug. The page contains squirrel images sized to height:1em, within text which has a background specified. The problem is that the cute squirrels are not sizing to fit the whole the height of what is 1em, the font-size, but are only becoming the height of a letter "M" (approximately, anyway). See the explanation at the very top of the document. Quick example: if SPAN { font-size: 50px; background: yellow; padding: 0; } and IMG { height: 1em; } then the height of an image in the SPAN should be exactly 50px, and the background of the SPAN should be exactly 50px high too.

See a piece I'm writing at: http://www.fas.harvard.edu/~dbaron/css/fonts/sizes/

The problem is that when NGLayout is asking for a font of, say, 10px, the OS is using a different definition of font-size than the OS' definition to actually draw the text. In CSS, the font-size is the distance from the top of the tallest glyph of a font to the bottom of the lowest glyph of a font. In most OS, the font-size appears to be measureed excluding diacriticals. To get around this problem, NGLayout should find what the distance between the top of the tallest glpyh of the font to the bottom of the lowest glyph of the font is (call this value 'c'), in the font's internal units, and then find out what the font *thinks* its font-size is (call this value 'f'), also in the font's units. Then, when NGLayout requests a font of size 'x', it should actually request a font of size x*c/f. This would thus translate between the CSS and OS definitions of font-size in a simple, XP manner. The only difficult bit in all this is trying to find 'c' and 'f'. The value 'f' can probably be found easily by querying the OS (this is not XP, unfortunately) for data about the font. Finding 'c' may be more difficult. Possibly, it could be found by querying for the actual height of every glyph in the font. This is obviously not very efficient. Some font experts should be able to help here.

Oops! That formula is wrong. I meant: CSS-font-size * f/c = OS-font-size So, to get a font of font-size "x" in CSS terms from the OS, you request a font of size x*f/c from the OS.

This page: http://outlook.microsoft.com/typography/OTSPEC/recom.htm ...may be useful. In particular, the "Baseline to Baseline Distances" section. It is part of the the Microsoft Typography section on TrueType fonts: http://outlook.microsoft.com/typography/tt/tt.htm Most documents on that site are in Word format, so I have not examined them. There is a FAQ on fonts: http://www.nwalsh.com/comp.fonts/FAQ/index.html However, this document seems to only address the issues pertinent to users, not application programmers.

Actually, ignore those last three comments. I think that is what you are already doing. That is what is wrong. Lets start again. The test cases to look at are: http://www.fas.harvard.edu/~dbaron/css/fonts/sizes/ http://www.fas.harvard.edu/~dbaron/css/test/inlinetest http://www.fas.harvard.edu/~dbaron/css/test/linebox4 http://www.fas.harvard.edu/~dbaron/css/test/emunit Assuming fully scalable fonts are available, as they are on Windows: When drawing a font with font-size 'x'px, you should ask the OS for a font of with a size of 'x'px. The background should have a height of exactly 'x'px. Anything with a size of 1em should have a size of exactly 'x'px. Quick example: if SPAN { font-size: 50px; background: yellow; padding: 0; border: none; } and IMG { height: 1em; } then the height of an image in the SPAN should be *exactly* 50px, and the background of the SPAN should be *exactly* 50px high too. Any text in the SPAN should have a nominal height of 50px, but this DOES NOT mean that the distance between the bottom of the lowest glyph to the top of the highest glyph will necessarily be exactly 50px, it may be a considerably bigger or smaller value. *This means glyphs may well spill out from the background*. [1] The actual fonts may quite possibly spill into surrounding boxes, lines, text, and so forth (assuming 'overflow' is set to 'visible', anyway). An example of probably correct rendering of the first case listed above, http://www.fas.harvard.edu/~dbaron/css/fonts/sizes/ ...is Opera's rendering of the page: http://www.fas.harvard.edu/~dbaron/css/fonts/sizes/opera ...(at least, assuming it is using the correct font-size). Hopefully, we may soon have a specially designed font to examine these issues with more accuracy. If we do, then we will be able to generate much more accurate tests. Stay tuned. ([1] To prevent glyphs from spilling out of the background, a web designer would use the padding properties. To prevent glyphs from flowing into surrounding _lines_, the web designer would use the 'line-height' property. This is not important for solving this bug.)

Some more accurate test pages are now available: http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/lineheight3.html http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/lineheight4.html These test pages use a font called Ahem, designed by Todd Fahrner. Instructions for downloading the font are included on the test pages themselves. The font must be installed before passing a browser through the tests. Mozilla passes lineheight3 without any problems. All the problems are on the lineheight4 page. It appears that you are using the _actual_ size of the font rather than the size of the font that you asked for, when doing calculations with the font size (e.g., for drawing the bg behind the font).

Hey peter - can you argue with david about how we should be interpret font-size in gecko, and once you have a resolution either kill the bug or reassign it to the right person to handle the fix? thanks...

This bug has become so confused (largely due to some misunderstandings that I had about the whole issue) that I have broken out a new bug. This bug is therefore now a duplicate of bug 13072. *** This bug has been marked as a duplicate of 13072 ***

Verified dup of #13072

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...