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)

PowerPC
macOS
defect
Not set
normal

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.
Attached file test case (deleted) —
Test case using Lucida Grande.
Attached image screenshot (deleted) —
From Left to Right: Camino 20061130 Trunk build (Cairo) - Firefox 2.0 - Safari 2.0.4
Attached image screenshot using 'helvetica' (deleted) —
Using 'Helvetica' instead of 'Lucida Grande'. Still taller than Safari, but much closer. --- For all fonts tested, Opera 9.0 matches Safari.
Comment on attachment 247130 [details] screenshot using 'helvetica' Changing the MIME type
Attachment #247130 - Attachment mime type: text/html → image/gif
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.)
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.
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'.
Attached file test case #2 (deleted) —
'Lucida Grande', 'line-height:normal' and 'line-height:1.2'
Attached image screenshot, testcase #2 (deleted) —
Minefield (2006113017) on the left, Safari 2.04 on the right.
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...
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;
Or we should hack in gfx.
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; } ??
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
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.
taking this.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Attached patch Patch rv1.0 (deleted) — Splinter Review
This uses the 'leading' as external leading. This patch works fine for both western font and Japanese font.
Attachment #247330 - Flags: review?(vladimir)
Attachment #247330 - Flags: review?(vladimir) → review?(pavlov)
(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.
*** Bug 361922 has been marked as a duplicate of this bug. ***
Blocks: 363572
Attachment #247330 - Flags: review?(pavlov) → review+
checked-in.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: