Created attachment 52816 [details]
A screenshot to show the extra space above characters when Malgun Gothic font is used

pl->hdu: please have a look. This is probably some kind of ascend/descend
confusion where we take different tables from the font than the system ?

This seems to be caused by
http://gsl.openoffice.org/source/browse/gsl/vcl/win/source/gdi/salgdi3.cxx?r1=1.42.4.1&r2=1.42.4.2
The heuristic introduced by that change probably became obsolete for new fonts.

(hdu reminder: the font file metrics look sane, what is different from older fonts is OS2.typo_gap==0)

@hdu: I am checking this issue with DEV300_m10 and I found the following code in
vcl/win/source/gdi/salgdi3.cxx. When I commented this code out and tried my
build, I could confirm the extra space was gone.

Now, I am trying to get more information on the reason we introduced this hack,
but the issue number 107888 seems to be Sun internal. May I get more information
on it?

    // #107888# improved metric compatibility for Asian fonts...
    // TODO: assess workaround below for CWS >= extleading
    // TODO: evaluate use of aWinMetric.sTypo* members for CJK
    if( mpWinFontData[0] && mpWinFontData[0]->SupportsCJK() )
    {
        pMetric->mnIntLeading += pMetric->mnExtLeading;

        // #109280# The line height for Asian fonts is too small.
        // Therefore we add half of the external leading to the
        // ascent, the other half is added to the descent.
        const long nHalfTmpExtLeading = pMetric->mnExtLeading / 2;
        const long nOtherHalfTmpExtLeading = pMetric->mnExtLeading -
nHalfTmpExtLeading;

        // #110641# external leading for Asian fonts.
        // The factor 0.3 has been confirmed with experiments.
        long nCJKExtLeading = static_cast<long>(0.30 * (pMetric->mnAscent +
pMetric->mnDescent));
        nCJKExtLeading -= pMetric->mnExtLeading;
        pMetric->mnExtLeading = (nCJKExtLeading > 0) ? nCJKExtLeading : 0;

        pMetric->mnAscent   += nHalfTmpExtLeading;
        pMetric->mnDescent  += nOtherHalfTmpExtLeading;

        // #109280# HACK korean only: increase descent for wavelines and impr
        if( !aSalShlData.mbWNT )
            if( mpWinFontData[0]->SupportsKorean() )
                pMetric->mnDescent += pMetric->mnExtLeading;
    }

@ssa: you introduced the "30% extra for CJK" heuristic after a careful investigation of the original problem. 
Since the fix needed to solve jeongkyu's issue has the great danger to reintroduce the original problem, 
we'd be very thankful if you would comment and point out some caveats that you noticed while you 
investigated the problem.

jeongkyu: issue #109280# had the title "The wave lines for auto-spellchecker are chopped off and should 
be redrawn" and SSA solved it by introducing the heuristic you found.

Created attachment 53289 [details]
a screenshot to show font & wave line rendering without the extra 30% of external leading

@hud & ssa: I did some experiment with my own build of DEV300_m10. Please have a
look at the second picture.

I commented out the code which adds the extra 30% external leading for CJK fonts
and Malgun(Clear) Gothic font renders properly now – it does not have too much
space above characters.

I also checked the wave line issue with 4 major Korean fonts which shipped with
Korean version of Windows. As you can see in the second picture, none of the
fonts shows the wave line problem even without the extra 30% of extra leading.
In addition, I checked the wave line issue with variety of settings such as
different font size, but I could not find any problem so far.

I'd like to propose to raise priority of this issue because possible fix will
give totally different layout if clear gothic font is used with current version.
Some users may take the current leading for granted or try to adjust it with
negative leading. Once they creat a document with those settings, such document
may suprise them later when they open it with new version.

The clear gothic font was introduced in Vista and it is still new to many users.
However, the more people start to use it with OO.o, the bigger the problem would be.

@hdu: I found that Linux version also has the same issue and the guilty code
could be easily located by the issue number #110641#. Please have a look at
vcl/source/glyphs/gcach_ftyp.cxx.

With my own build of BEA300_m2 on Ubuntu Linux, I could confirm that this issue
goes away if I commented out the following code.

(In vcl/source/glyphs/gcach_ftyp.cxx)
/* 
// #110641# external leading for Asian fonts.
// The factor 0.3 has been verified during experiments.
const long nCJKExtLeading = (long)(0.30 * (rTo.mnAscent + rTo.mnDescent));

if ( nCJKExtLeading > rTo.mnExtLeading )
    rTo.mnExtLeading = nCJKExtLeading - rTo.mnExtLeading;
else
    rTo.mnExtLeading = 0;
*/

@ssa: Even though I took out the code for 30% external leading, I failed to
reproduce the wave line issue. Would you explain the wave line issue in detail
and give me steps to reproduce it? Thanks!

@hdu: Recently, the biggest internet portal in Korea released two clear type
fonts for celebrating Hangul(Korean character) day. They are called Nanum
MyoungJo and Nanum Gothic for each and can be freely used and distributed. 

http://hangeul.naver.com/index2.jsp#

Unfortunately, I found this issue happens with the fonts as well as with the
earlier mentioned font Malgun Gothic. Considering the growing popularity of
those clear type fonts, I'd like to suggest to remove the extra 30% leading now.
If we later figure out the exact reason of the extra leading then we have to
apply it with more sophisticated approach.

FYI, here it the link for downloading the fonts:

http://static.campaign.naver.com/file/2008/10/hangeul0721/NanumFont_Windows_Manual.zip

Reset assigne to the default "issues@openoffice.apache.org".