This bug has been opened to remind us to clean up the nsIFontMetrics API, which contains GetHeight and so on. We may want to change this to GetEmHeight, and include a comment that this is for the English font only. More ideas to come later, since this is not an M14 priority for now.

Target M16, after Beta 1 branch, in conjunction with bug 20394.

Added a few people to the Cc field. I'd like to make a proposal for the line height problem, and if you agree, I'll proceed. First, an explanation: Here are the current height-related APIs: GetHeight, GetLeading, GetMaxAscent, GetMaxDescent Basically, the problem is that GetHeight returns the max height, and we are multiplying this value by the CSS line-height property to compute the line spacing. There have been a number of long discussions about this on the www-style@w3.org mailing list, and it seems that many people believe that the line spacing should be computed by multiplying line-height by the em square height, which is different from the max height. IE and Opera also use the em square height to compute the line spacing. For line-height "normal", Mozilla currently uses the value 1.0 to multiply by the return value of GetHeight. For the default font (Times New Roman) at the default size (12pt == 16px @ 96ppi), GetHeight returns 19, and this is the same as the line spacing used by WinNav4 and WinIE in CSS-less HTML. However, this is not the line spacing recommended by Times New Roman itself. It recommends 20 (when the size is 16). I'd like to propose that we try the recommended line spacing, and see how that turns out. If we have too many compatibility problems, we can revert to using the max height as the line spacing, possibly only on Windows (where we seem to have the strictest compatibility requirements). Whether we go with the recommended line spacing or not, I'd like to propose a number of new methods, so that the new set of height-related APIs becomes: GetMaxHeight, GetMaxAscent, GetMaxDescent GetEmHeight, GetEmAscent, GetEmDescent GetLeading For line-height "normal", we should use GetEmHeight + GetLeading. Alternatively, we could have a single API that returns that sum, called GetNormalLineHeight. Initially, I'd like to add the new APIs. Then move all the callers to these new methods, and finally remove the old API (GetHeight). Please let me know whether you agree with this plan. If there is too much disagreement, we can either postpone it to Netscape 7 or cancel it all together.

Copying comments from bug 27874: Bug History: see bug 4234, bug 13072. The test case to look at is: http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/lineheight7.html Some other related test pages: 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 http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/lineheight1.html http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/lineheight2.html http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/lineheight3.html http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/lineheight4.html

*** Bug 27874 has been marked as a duplicate of this bug. ***

the API additions sound fine. the change to the calculation also sounds fine, although we may want to control it by the mode (quirks vs. no quirks) and as Erik alludes to, perhaps even by platform. Let's get it in and get some feedback.

"me too" re- Steve comments :-) However Erik, regarding GetEmHeight, GetEmAscent, GetEmDescent, I am not sure that I understand you well. Since 'm' has no descender, GetEmDescent is going to be zero? and GetEmHeight is equals to GetEmAscent? Because they are still confusing to me, I will opt for the second option GetNormalLineHeight, so that substracting GetLeading might give the other.

The "em square" is a term that refers to the units used in the font's design. TrueType fonts have a field called unitsPerEm, and the glyph outlines are defined in those units. It has no direct relationship to the letter 'm', though its history is related to the letter 'M'. However, in modern fonts, there is no direct relationship between the em square and the letter 'M'.

So the 'EmHeight', 'EmAscent', 'EmDescent' you are referring to here represent the smallest bounding-box in which all characters in that font can fit?

No, the designer is free to have some glyphs protrude outside the em square. The em square is simply the size that you request. The bounding box is the box the surrounds all glyphs, and it may be larger than the em square.

Checked a fix into nsHTMLReflowState.cpp.

Marking verified per last comments.

REOPENING. On http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/lineheight7.html one sees that line-height: 1.0 is not using the font-size as the line-height.

Forgot to add: Tested with Windows 2000 commerical build 6.0.17.2000072811.

mark it as Future and nsbeta3- per bug meeting w/ ekrock

Mark it as M23 for now.

Mark it as moz1.0 for now.

It's also visible in the testcase of bug 77067: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=32563

erik resign. reassign all his bug to ftang for now.

shanjian- this is a hard one. can you please take a look at this one ?

I probably shouldn't reopen this bug. Ian's observation seems unrelated with this bug. I traced into the program for a little while, and it seems to me that we did not interprete lineheight attribute correctly. In our layout code, nsHTMLReflowState.cpp, line-height is normal. If you change the value of line height from 1.0 to 2.0, you will not see any difference. So the problem seems to be the interpretation of CSS. I open a bug 82422 for lineheight problem and close this one. For clarification, in CSS2, it suggest to use 1.0 to 1.2 multiply the size of font to use as normal line height. Erik suggest to use em square height here. That will produce a better result when applying with different fonts than a fixed number.

Why is this WORKSFORME? This is a complicated issue where we're not sure what the right behavior really is. Going into the debugger won't help figure out how we should behave. Reopening. INVALID *may* be an appropriate resolution for this bug, but I don't see how WORKSFORME is since Ian's testcase doesn't work right now.

Please pay attention to my last comment. Bug 82422 is filed for ian's problem. We would still like to handle lineheight normal using em square height. I do not see why I can't resolve it as worksforme. I do not like the idea of put unrelated issues into one bug.

The correct resolution on this bug should be FIXED rather than WORKSFORME -- see the recent comments on bug 82422. (There was an error in Ian's test, so he shouldn't have reopened in the first place a year ago.) But I won't bother reopening and correcting since that would send me and others 6 email messages from bugzilla...

VERIFIED per comments.