Bug 68735 - CJK opentype fonts rendered with unusually tall line height
Summary: CJK opentype fonts rendered with unusually tall line height
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.1.1.2 release
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-30 03:36 UTC by Yuki Kawara
Modified: 2014-08-27 13:15 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Using Adobe's Kozuka Gothic font, showing the edit window and gedit/caja side by side. (48.85 KB, image/jpeg)
2013-08-30 03:36 UTC, Yuki Kawara
Details
Using Adobe's Kozuka Gothic font, showing the edit window and gedit/caja side by side. (48.85 KB, image/jpeg)
2013-08-30 03:40 UTC, Yuki Kawara
Details
Small program to print font metrics (2.34 KB, text/plain)
2013-08-30 16:18 UTC, Khaled Hosny
Details
LibreOffice vs. Firefox vs. Chrome (124.08 KB, image/png)
2013-08-30 23:56 UTC, Khaled Hosny
Details
HTML file in the screenshot (270 bytes, text/html)
2013-08-30 23:58 UTC, Khaled Hosny
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yuki Kawara 2013-08-30 03:36:05 UTC
Created attachment 84887 [details]
Using Adobe's Kozuka Gothic font, showing the edit window and gedit/caja side by side.

CJK opentype fonts are displayed with an unusually tall line height in the edit window, making it impossible to use these fonts.

Adding a snapshot of using Adobe's Kozuka Gothic font, showing the edit window and gedit/caja side by side.

Adobe FanHeiti, Adobe Ming (Chinese)
Adobe Gothic, Adobe Mungjo (Korean) also show the same behaviour, as well as Morisawa fonts (Japanese). I haven't tested with other major japanese foundries (Fontworks, Iwata, Dynafont, Dainippon), but I bet it's the same.

Firefox and Thunderbird show the same behaviour in the UI but there is a work around if you open the advanced settings and set browser.display.normal_lineheight_calc_control to "0" (disabling it).
Comment 1 Yuki Kawara 2013-08-30 03:40:08 UTC
Created attachment 84888 [details]
Using Adobe's Kozuka Gothic font, showing the edit window and gedit/caja side by side.
Comment 2 Khaled Hosny 2013-08-30 16:18:30 UTC
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.
Comment 3 Khaled Hosny 2013-08-30 16:28:58 UTC
Pango (what GTK applications use for text layout), simply ignore the line gap, it does not take it into account at all.
Comment 4 Yuki Kawara 2013-08-30 18:14:54 UTC
What is that line gap useful for, anyway? How about an option to turn it off, like Mozilla did?
Comment 5 Khaled Hosny 2013-08-30 23:35:54 UTC
Line gap is useful for setting line gap. What Mozilla option turns it off?
Comment 6 Khaled Hosny 2013-08-30 23:56:38 UTC
Created attachment 84941 [details]
LibreOffice vs. Firefox vs. Chrome
Comment 7 Khaled Hosny 2013-08-30 23:58:57 UTC
Created attachment 84942 [details]
HTML file in the screenshot
Comment 8 Yuki Kawara 2013-08-31 03:09:14 UTC
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.
Comment 9 Khaled Hosny 2013-08-31 08:54:28 UTC
(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).
Comment 10 Yuki Kawara 2013-08-31 10:35:24 UTC
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...
Comment 11 Khaled Hosny 2013-08-31 11:56:16 UTC
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).
Comment 12 Jean-Baptiste Faure 2013-11-16 09:16:06 UTC
Due to comment #9 I close this bug report as NotOurBug.

Please, feel free to reopen if I am wrong.

Best regards. JBF