Closed
Bug 362428
Opened 18 years ago
Closed 18 years ago
[Cairo] 'normal' keyword for line-height is too tall with 'Lucida Grande'.
Categories
(Core :: Graphics, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: phiw2, Assigned: masayuki)
References
Details
Attachments
(6 files)
The Computed value for 'line-height' using the 'normal' keyword is too large, resulting in a line box that is too tall.
This affects the 'Lucida Grande' font mostly. Other fonts are on par with Safari 2.0, although different from Firefox 2.0.
Reporter | ||
Comment 1•18 years ago
|
||
Test case using Lucida Grande.
Reporter | ||
Comment 2•18 years ago
|
||
From Left to Right: Camino 20061130 Trunk build (Cairo) - Firefox 2.0 - Safari 2.0.4
Reporter | ||
Comment 3•18 years ago
|
||
Using 'Helvetica' instead of 'Lucida Grande'. Still taller than Safari, but much closer.
---
For all fonts tested, Opera 9.0 matches Safari.
Comment 4•18 years ago
|
||
Comment on attachment 247130 [details]
screenshot using 'helvetica'
Changing the MIME type
Attachment #247130 -
Attachment mime type: text/html → image/gif
Assignee | ||
Comment 5•18 years ago
|
||
Are the line-height:1.3 cases same result? If so, the patch of bug 353185 changes this behavior. That patch needs for Japanese system font, because they don't have suitable metrics. In the XP code, we are resolving this problem for Win too. (Windows has same issue.)
Assignee | ||
Comment 6•18 years ago
|
||
And the line-height: normal; is UA default. And it depends on UA. We are setting the line-height to 1.2 if the font doesn't have suitable internal leading.
Reporter | ||
Comment 7•18 years ago
|
||
Masayuki,
* I know 'line-height:normal' is the UA default. And there absolutely no problems with Japanese Fonts on Mac (since the patch for bug 353185, thank you for that one).
* when you look at the screenshot for 'Lucida Grande' (attachment #247128 [details]), you can see how with Cairo/Mac the line-height is much larger than in Safari (or Opera).
* with any other value for 'line-height' (number, %, ems,..) there are no problems.
I'll attach another testcase, using line-height:normal and line-height:1.2. There is a huge difference when using 'Lucida Grande'.
Reporter | ||
Comment 8•18 years ago
|
||
'Lucida Grande', 'line-height:normal' and 'line-height:1.2'
Reporter | ||
Comment 9•18 years ago
|
||
Minefield (2006113017) on the left, Safari 2.04 on the right.
Assignee | ||
Comment 10•18 years ago
|
||
Um.. looks like the line-height: normal and line-height: 1.2 are different results. By this results, we can know the 'Lucida Grande' has non-zero internal leading. Therefore, Gecko uses em height + internal leading + external leading(always zero on Mac) for normal line-height...
Assignee | ||
Comment 11•18 years ago
|
||
http://lxr.mozilla.org/mozilla/source/layout/generic/nsHTMLReflowState.cpp#2218
> 2218 case eCompensateLeading:
> 2219 if (!internalLeading && !externalLeading)
> 2220 normalLineHeight = NSToCoordRound(emHeight * NORMAL_LINE_HEIGHT_FACTOR);
> 2221 else
> 2222 normalLineHeight = emHeight+ internalLeading + externalLeading;
> 2223 break;
This is current calculating code, should this be:
case eCompensateLeading:
preferredLineHeight = NSToCoordRound(emHeight * NORMAL_LINE_HEIGHT_FACTOR);
if (!internalLeading && !externalLeading)
normalLineHeight = preferredLineHeight;
else {
normalLineHeight = emHeight+ internalLeading + externalLeading;
if (normalLineHeight > preferredLineHeight)
normalLineHeight = preferredLineHeight;
}
break;
Assignee | ||
Comment 12•18 years ago
|
||
Or we should hack in gfx.
Assignee | ||
Comment 13•18 years ago
|
||
http://lxr.mozilla.org/mozilla/source/gfx/thebes/src/gfxAtsuiFonts.cpp#132
> 132 if (mMetrics.maxHeight - mMetrics.emHeight > mMetrics.internalLeading)
> 133 mMetrics.emHeight = mMetrics.maxHeight - mMetrics.internalLeading;
if (mMetrics.maxHeight - mMetrics.emHeight > mMetrics.internalLeading) {
gfxFloat emHeight = mMetrics.maxHeight - mMetrics.internalLeading;
if (emHeight * 1.2f < mMetrics.maxHeight)
mMetrics.emHeight = emHeight;
}
??
Comment 14•18 years ago
|
||
If you do anything special for Lucida Grande, you probably need to do the same for Lucida Sans Unicode. I don't think there's any significant difference between them other than the names and what platforms you find them on. Check it out with this testcase: http://mrmazda.no-ip.com/auth/Font/font-lsansuni-lh.html
Assignee | ||
Comment 15•18 years ago
|
||
Wow, we have a mistake. We treat the 'leading' as internal leading. But it's wrong. The leading of Mac means external leading. We need to check the current logic.
Assignee | ||
Updated•18 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 17•18 years ago
|
||
This uses the 'leading' as external leading.
This patch works fine for both western font and Japanese font.
Attachment #247330 -
Flags: review?(vladimir)
Assignee | ||
Updated•18 years ago
|
Attachment #247330 -
Flags: review?(vladimir) → review?(pavlov)
Reporter | ||
Comment 18•18 years ago
|
||
(In reply to comment #17)
> Created an attachment (id=247330) [edit]
> Patch rv1.0
I've used this patch on my home-made Camino build. It fixes all issues, and while visiting webpages, haven't seen or found any problems.
Comment 19•18 years ago
|
||
*** Bug 361922 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Attachment #247330 -
Flags: review?(pavlov) → review+
Assignee | ||
Comment 20•18 years ago
|
||
checked-in.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•18 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•