It looks like default line-height is 1.0em, but it's not enough for Japanese font. It should be 1.1em or 1.2em. The CSS1 specification says "A value of 'normal' sets the 'line-height' to a reasonable value for the element's font. It is suggested that UAs set the 'normal' value to be a number in the range of 1.0 to 1.2". http://www.w3.org/TR/REC-CSS1#line-height This problem was reported on Bugzilla-jp. http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=537

Since erik's dealt with line-height and font-size issues in the past, giving to erik, cc: buster and me.

KOIKE: Your commet seems pretty subjective. IS there any document/specification/ standard support your opinion ? cc pierre. Pierre: where is the place we can control the value of normal in mozilla ? I am not suggest we should change it right away, but it will be nice ot know where it is. This is a style system issue. Change the component to Stylesystem

What if we used 'normal' to include the external leading to rather than just the internal leading? Do these Japanese fonts have appropriate external leading in the font metrics? Would that break other content? (How badly? It seems like a good thing to do, anyway...)

Times New Roman at 16px gives a tmHeight of 19px, and that's what WinNav4 and WinIE use. The tmHeight value does not include the external leading, which is 1px (giving a total of 20px = 19 + 1). So, if we changed WinMoz to include the external leading, our pages would look different from the old browsers. In normal text, that might not be a problem, but in forms and tables, these small effects have a way of multiplying several fold. Ask Rod Spears. I'm sure he can give you some horror stories. Last time I checked, the Japanese fonts had a tmHeight equal to the font size, and the external leading was zero. (I may be wrong. Maybe somebody can check this.) Anyway, the only way to solve this problem is to come up with some hack for Japanese (and other) fonts, leaving Times New Roman and other Western fonts as they are. Such a hack would not be clean, since the fonts should be giving us better leading values. But Mozilla has been known to perform dirty tricks every now and then to get around legacy issues. Perhaps this is one of those areas.

Netscape's standard compliance QA team reorganised itself once again, so taking remaining non-tables style bugs. Sorry about the spam. I tried to get this done directly at the database level, but apparently that is "not easy because of the shadow db", "plus it screws up the audit trail", so no can do...

I recommend we WONTFIX this. We already have a bug with 'line-height:normal' being not quite the right height (or rather, 1.0 being not quite right).

Ian, do you mean this is a duplicate of another bug? I can't find that.

KOIKE: no, I'm saying I do not think there is a valid bug here. The bug I was referring to is bug 82422, which is related but is not quite the same issue.

I think this issue relates to the parenthetical comment I made in point (2) in my comment a few minutes ago on bug 82422. But that raises the question -- do these fonts have metrics that specify nonzero (and appropriate) recommended leading? (I'm getting my terms all mixed up... but what I mean is if the metrics have a recommended spacing that's larger than the maximum extension of the characters.)

dbaron: I think the answer to your question is yes. I think this would affect chinese fonts too. See the testcase with colored top and bottom borders

I am going to take care of this problem in 76097. Please assign this one to me.

per shanjian@netscape.com request

adding depend

oops... how did that happen?

this has been fixed by 76097.

VERIFIED FIXED using attachement 41203