Bug 83145 - Wrong line height with Microsoft Yahei font (and other CJK fonts)
Summary: Wrong line height with Microsoft Yahei font (and other CJK fonts)
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.1.1 rc
Hardware: All Windows (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: CJK
  Show dependency treegraph
 
Reported: 2014-08-27 13:04 UTC by Kevin Suo
Modified: 2015-02-26 21:17 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
test odt file (17.66 KB, application/vnd.oasis.opendocument.text)
2014-08-27 13:04 UTC, Kevin Suo
Details
screenshot illustration (768.93 KB, image/png)
2014-08-27 13:14 UTC, Kevin Suo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Suo 2014-08-27 13:04:45 UTC
Created attachment 105333 [details]
test odt file

Problem Description:
In Writer, for the same font size, CJK fonts is showing much bigger/wider line height.

Steps to reproduce:
1. Apply "Libration Sans", "Libration Serif", "Times New Roman", or "Arial" to some text, set font size to 16.
2. Apply "Microsoft Yahei" to some other text, set font size also to 16.

Current behaviour:
Line height in step 2 is much wider than in step 1.
This affects many other CJK fonts.
This makes CJK document looks ugly.
Actually if you export the document to html and open in Firefox, it shows correct line height.

Expected:
Same line height when same font applied.

See attached test file for illustration.
Comment 1 Kevin Suo 2014-08-27 13:14:28 UTC
Created attachment 105335 [details]
screenshot illustration
Comment 2 Julien Nabet 2014-08-27 19:45:53 UTC
On pc Debian x86-64 with master sources updated today, I don't reproduce this.
Comment 3 Kevin Suo 2014-08-28 00:10:25 UTC
(In reply to comment #2)
> On pc Debian x86-64 with master sources updated today, I don't reproduce
> this.

I didn't test it on linux. But make sure you have "Microsoft Yahei" font installed to reproduce.
Comment 4 Julien Nabet 2014-08-28 05:24:59 UTC
Indeed, I don't have this font installed and it seems you must pay to have it, see http://www.microsoft.com/typography/fonts/family.aspx?FID=350
Comment 5 Kevin Suo 2014-08-28 06:09:51 UTC
(In reply to comment #4)
> Indeed, I don't have this font installed and it seems you must pay to have
> it, see http://www.microsoft.com/typography/fonts/family.aspx?FID=350

In fact, you can also reproduce with the free "Source Han Sans" CJK fonts and change the font in the test file accordingly:
http://sourceforge.net/projects/source-han-sans.adobe/files/
Comment 6 Julien Nabet 2014-08-29 20:44:52 UTC
Kevin: thank you for your feedback, which file must I download on the provided link to give it a try?
Comment 7 Owen Genat (retired) 2014-09-15 14:02:40 UTC
Kevin, is this extra height related to needing to cater for ruby text? Bug 44784 and this Ask thread:

http://ask.libreoffice.org/en/question/39651/

... raise a similar issue. Adding ruby text to CJK base text does not seem to increase the line height.
Comment 8 Kevin Suo 2014-09-17 14:51:50 UTC
(In reply to comment #7)
> Kevin, is this extra height related to needing to cater for ruby text?

I didn't think they are related, but the interesting thing happened:
I typed some text, applied "Microsoft Yahei" font so the bug behaviour appeared, and then I tried to apply rubby text to the chars so more extra spaces were added above the text. Then I deleted all the text. And then when I try to input text and apply "Microsoft Yahei", "Wenquanyi Zenhei" etc, the bug behaviour is gone!

I reset the libreoffice user profile, but now I can no longer reproduce the problem with "Microsoft Yahei", "Wenquanyi Zenhei" fonts.

But I still reproduce with "Source Han Sans CN" fonts.
Comment 9 Kevin Suo 2014-09-17 14:54:25 UTC
The main reason I thought they were not related is that, the bug behaviour I mentioned never happen to "SimSun" etc serif-like fonts.
Comment 10 Owen Genat (retired) 2014-09-21 14:25:13 UTC
I am not sure that this report describes a problem LO can solve, for the reasons indicated in bug 68735. Comparing text as displayed in Writer vs Firefox is probably not an equal comparison. Here are some more metrics (using the C program kindly provided by Khaled) to add to those listed in comment two from that report:

Hiragino Maru Gothic Pro	Ascent = 880, Descent = 120, Leading = 500
MS Mincho			Ascent = 859, Descent = 141, Leading = 0
Microsoft YaHei			Ascent = 1058, Descent = 262, Leading = 0
Noto Sans T Chinese		Ascent = 880, Descent = 120, Leading = 500
PMingLiU			Ascent = 801, Descent = 200, Leading = 198
SimSun				Ascent = 859, Descent = 141, Leading = 141
Source Han Sans			Ascent = 880, Descent = 120, Leading = 500
WenQuanYi Zen Hei		Ascent = 963, Descent = 297, Leading = 90

Liberation Serif		Ascent = 891, Descent = 216, Leading = 43

These are the font versions I queried:

Hiragino Maru Gothic Pro	MacOS 10.6.8 OTF
MS Mincho			MS Office 2000 TTF v2.30
Microsoft YaHei			Windows Vista TTF v5.00
Noto Sans T Chinese		website OTF
PMingLiU			MS Office 2000 TTF v3.00
SimSun				MS Office 2000 TTF v2.10
Source Han Sans			website OTF
WenQuanYi Zen Hei		website TTC v0.9.46

Liberation Serif		LOv4312 TTF v2.00.1

I think the variation in line height being observed is simply the result of varying metrics. In basic terms, older CJK fonts have a smaller Leading metric, while newer CJK fonts seem to have greater Leading metric (but other metrics are probably also influential).

Ruby text does seem to affect line spacing, but this may be a separate issue. I am unclear about this, which is partly why I raised it above as an open question.
Comment 11 Adolfo Jayme Barrientos 2014-10-15 06:59:16 UTC
(In reply to Owen Genat from comment #10)
> I think the variation in line height being observed is simply the result of
> varying metrics.

+1000
Comment 12 Robinson Tryon (qubit) 2015-02-26 21:17:06 UTC
(In reply to Owen Genat from comment #10)
> I am not sure that this report describes a problem LO can solve, for the
> reasons indicated in bug 68735.

As with the bug report mentioned above, this appears to be an issue with the fonts themselves, and as such I'm marking this as RESOLVED NOTOURBUG for the time being. If someone has an idea for how we can address this problem, we can revisit it.