137817 - Need to include external leading for normal Line-height, Mac only

Status: RESOLVED INVALID

(Core :: Internationalization, defect)

Description

[Shanjian Li]

This is a bug split from bug 76097, which only handles windows.

For truetype font and opentype font, font api provides several font metrics,
like ascent, descent, internal leading, external leading, etc. When calculating
normal line height, we did not include external leading. After bug 76097 was
fixed, this external leading is returned to layout and was used to calculating
normal line height. Some of the fonts do not have either internal or external
leading, and they looks too compact. To handle such situation, I implement a
option to calculate a compensate external leading if font vendor does not
provide one. 

To be specific, here is what need to be done:
1. Find out if it is possible to figure internal leading and external leading. 
2. Add implemenation  for : 
    GetInternalLeading(nscoord &aLeading)
    GetExternalLeading(nscoord &aLeading)
   and remove:
    GetLeading(nscoord &aLeading)
    GetNormalLineHeight(nscoord &aHeight)
3. Add mac platform to nsIFontMetrics.h FONT_LEADING_APIS_V2 define list.

Comment 1

[Frank Tang]

any test cases and verification suites?

Comment 2

[Frank Tang]

rbs- I want to work on this. But do you have any test cases ?

Comment 3

[rbs]

No, I don't have any testcases. Perhaps shanjian still have the testcases that 
he has been using for bug 76097.

Comment 4

[Shanjian Li]

bug 76097 has a bunch of testcases. 

Comment 5

[Phillip Oertel]

Attachment: xhtml strict document. mozilla ignores line-heights smaller 1em.

Comment 6

[Phillip Oertel]

the attachment belongs to bug 125502. dont know why it came here. bugzilla bug?
sorry for the spam

Comment 7

[Phillip Oertel]

now i know - bugzilla behaviour has changed. after posting a comment, instead of
returning to the same bug it sends me to the next bug on my 'list'. i didn't notice.

Comment 8

[Frank Tang]

rbs, did you finish this work for us already or not ? Do I still need to work on
it ?

Comment 9

[rbs]

Work is still needed (as per comment 1). In fact, only Windows is up to speed at 
the moment, following shanjian's successive iterations over there to 
special-case CJK fonts (bug 156943).

Comment 10

[nhottanscp]

reassign to nhotta

Comment 11

[Samir Gehani]

i18n triage team: nsbeta1-

Comment 12

[Jungshik Shin]

Mac OS APIs and Win32 APIs are not compatible (they use the same terms
differently). It seems like an XP-way is to poke directly 
sTypoAscender/sTypoDescender/sTypoLineGap(?) of OS/2 table. A trouble with that
is not all truetype fonts have them set correctly. For that reason, Freetype2
(used in GFX:Gtk both by FT2 and Xft) doesn't rely on them (the code is there
but #if 0'd). It's a while ago that I looked at FT2 and Xft code so that I don't
remember what FT2 does instead(ref. bug 218032). Anyway, we can do what it does
here. Needless to say, if we can figure out formulae to translate MacOS 'API
values' to  Win32 'API values' (that we used in 76097), we don't have to look
into truetype tables directly.  

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:m_kato, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 14

[Greg Tatum [:gregtatum]]

Closing old bugs as invalid.