Created attachment 84888 [details]
Using Adobe's Kozuka Gothic font, showing the edit window and gedit/caja side by side.

Created attachment 84920 [details]
Small program to print font metrics

All Adobe’s CJK fonts that I can test have a very big leading, so these fonts are working as intended. Here are the values I get from these fonts, compare them to the non-CJK fonts, also from Adobe:

Adobe Heiti Std		Ascent = 880, Descent = 120, Leading = 1000
Adobe Ming Std		Ascent = 880, Descent = 120, Leading = 1000
Adobe Myungjo Std	Ascent = 880, Descent = 120, Leading = 1000
Adobe Song Std		Ascent = 880, Descent = 120, Leading = 1000
Kozuka Mincho Pr6N	Ascent = 880, Descent = 120, Leading = 1000

Adobe Arabic		Ascent = 748, Descent = 342, Leading = -1
Adobe Hebrew		Ascent = 727, Descent = 273, Leading = 250
Adobe Sans MM		Ascent = 862, Descent = 261, Leading = 77
Adobe Serif MM		Ascent = 910, Descent = 257, Leading = 33
Adobe Thai		Ascent = 760, Descent = 240, Leading = 240
Courier Std		Ascent = 627, Descent = 373, Leading = 200
Minion Pro		Ascent = 727, Descent = 273, Leading = 200
Myriad Pro		Ascent = 750, Descent = 250, Leading = 200

Attached a small C program that used to retrieve these values.

Pango (what GTK applications use for text layout), simply ignore the line gap, it does not take it into account at all.

What is that line gap useful for, anyway? How about an option to turn it off, like Mozilla did?

Line gap is useful for setting line gap. What Mozilla option turns it off?

Created attachment 84941 [details]
LibreOffice vs. Firefox vs. Chrome

Created attachment 84942 [details]
HTML file in the screenshot

Wow, I knew Firefox had a problem with Japanese OTFs, but I am surprised Chrome has it worse.

Setting browser.display.normal_lineheight_calc_control to "0" to in both Firefox and Thunderbird (Default value is 2) fixes the problem.

See http://kb.mozillazine.org/About:config_entries#Browser.

(In reply to comment #8)
> Wow, I knew Firefox had a problem with Japanese OTFs,

Firefox *does not* have problems with Japanese OTFs (and neither is LibreOffice), those Japanese OTFs are the ones at fault, so you should complain to the font vendor not the software rendering them as intended.

> Setting browser.display.normal_lineheight_calc_control to "0" to in both
> Firefox and Thunderbird (Default value is 2) fixes the problem.

I personally don’t like this 1) it is working around font issues/bugs, the proper solution is to fix the fonts not to hack every application in existence to work around their bugs 2) Options that result drastically different rendering is a portability nightmare (unless you store the option in the file, but we can not do that for every file format we support) 3) You already have control on line height, Format → Paragraph → Indents & Spacing → Line spacing (try setting it to fixed, 0.50cm, for example).

Although I couldn't compile the program you provided, I checked both Morisawa's ShinGo and Adobe's Kozuka in FontForge (OS/2 metrics) and they have the same metrics. However, on all of these fonts, the "Really use typometrics" option is off, and ascent and descent actually show as 0 and the checkbox "is offset" is off - only when I check it I see 880 and 120. It actually does make sense for CJK fonts to have no ascent and no descent.

The hover text on Typo Line Gap says it is used in MS Windows, that implies MacOS ignores it. Not sure who's right, but an option to turn it on or off would be rather handy. Fixing every paragraph by hand (method 3) means fixing them again if the fonts ever get fixed, and fixing them by hand across platforms too...

There are three sets of vertical metrics in OpenType/TrueType fonts:

1) ‘hhea’ table’s Ascender, Descender and LineGap: Those are the ones preferred by Apple, recent versions of FreeType and LibreOffice 4.1 on Linux. In those fonts ‘hhea’ LineGap is 1000 i.e as big as Ascender and Descender combined, that is the font designers choice, not us.

2) ‘OS/2’ table’s sTypoAscender, sTypoDescender and sTypoLineGap: Those are the recommended values for typographic line spacing in OpenType spec, regardless of the setting of the “Really use typo metrics” bit (this bit was introduced because some applications kept ignoring the typo metrics as a strong indication, but the spec does not require it being set for the typo metrics to be used). FreeType and LibreOffice 4.1 on Linux, fallback to this if ‘hhea’ table is missing from the font. Again, those fonts have a 1000 sTypoLineGap, so it is still the designers choice not us.

3) ‘OS/2’ table’s usWinAscent and usWinDescent: Those should only be used for bitmap clipping of the rendered text and its use in calculating line spacing is strongly discouraged by the OpenType spec, yet many Windows applications still use it regardless of this. FreeType and LibreOffice 4.1 on Linux, fallback to this if the font has ‘OS/2’ sTypoAscender and sTypoDescender set to zero.


The offset thing is just a FontForge feature to auto-calculate the values as offset from glyph heights when generating the font, fonts only contain the absolute values.

Line spacing is already a mess due to many historical and backward compatibility reasons, and I believe our current approach is the most sensible and there is no compelling reason to mess it even more by throwing more options to the mess. You should really just a) complain to font vendors, b) use other fonts or c) modify the fonts yourself (within legal constraints of course).

Due to comment #9 I close this bug report as NotOurBug.

Please, feel free to reopen if I am wrong.

Best regards. JBF