Bug 55469 - Different line spacing across platforms
Summary: Different line spacing across platforms
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Khaled Hosny
QA Contact:
URL:
Whiteboard: target:4.1.0 target:5.3.0 backportReq...
Keywords:
: 44784 90554 98269 103730 (view as bug list)
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2012-09-30 12:15 UTC by Yury
Modified: 2016-12-08 21:41 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
file with two math fonts, saved in TextMaker 2012 (4.12 KB, application/vnd.oasis.opendocument.text)
2012-09-30 12:16 UTC, Yury
Details
file with four fonts, saved in LibreOffice 3.6.2.1 (12.41 KB, application/vnd.oasis.opendocument.text)
2012-09-30 12:17 UTC, Yury
Details
2fonts_kword (10.26 KB, image/jpeg)
2012-09-30 12:26 UTC, Yury
Details
2fonts_libo (20.79 KB, image/jpeg)
2012-09-30 12:26 UTC, Yury
Details
2fonts_tm2008 (18.99 KB, image/jpeg)
2012-09-30 12:26 UTC, Yury
Details
2fonts_tm2012 (16.35 KB, image/jpeg)
2012-09-30 12:27 UTC, Yury
Details
4fonts_kword (9.77 KB, image/jpeg)
2012-09-30 12:27 UTC, Yury
Details
4fonts_libo (19.86 KB, image/jpeg)
2012-09-30 12:27 UTC, Yury
Details
4fonts_tm2008 (18.54 KB, image/jpeg)
2012-09-30 12:28 UTC, Yury
Details
4fonts_tm2012 (16.32 KB, image/jpeg)
2012-09-30 12:28 UTC, Yury
Details
LibO 4.1.0.1 with Charter and Neo Euler in text and formula (15.24 KB, application/vnd.oasis.opendocument.text)
2013-06-22 11:46 UTC, Yury
Details
proofpic of what's showing (14.86 KB, image/png)
2013-06-22 11:48 UTC, Yury
Details
self-made Charter (50.41 KB, application/x-font-opentype)
2013-06-22 11:48 UTC, Yury
Details
self-made Charter Italic (38.21 KB, application/x-font-opentype)
2013-06-22 11:49 UTC, Yury
Details
LibreOffice MATH fonts spacing (114.14 KB, image/png)
2014-10-30 06:58 UTC, zeonchameleon
Details
Similar problem with japanese font (5.86 MB, application/vnd.oasis.opendocument.text)
2016-11-06 00:40 UTC, madmalkav
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yury 2012-09-30 12:15:57 UTC
Lines spacing is anomally large for some fonts strongly specialising in math glyphs (at least Asana Math, XITS Math, STIX Math, Neo Euler). This happens both in Writer and in Formula Editor.

After some testing, I believe that it doesn't matter what glyphs are actually used, only what parameters (unknown to me) are used in a fontfile. Actually, this is an old bug, I remember experiencing this problem a year ago, at least.

Ironically, other textprocessors manage better! I'm attaching two files, 1) with Neo Euler and Asana Math lines, saved in softmaker.com's TextMaker 2012, 2) with Neo Euler and Asana Math and STIX Math and XITS Math, saved in LibreOffice 3.6.2.1. Also I'm attaching screenshots with both files open in TextMaker 2008, TextMaker 2012, KWord 4.5.5 (or something), LibreOffice 3.6.2.1.
Comment 1 Yury 2012-09-30 12:16:55 UTC
Created attachment 67882 [details]
file with two math fonts, saved in TextMaker 2012
Comment 2 Yury 2012-09-30 12:17:33 UTC
Created attachment 67883 [details]
file with four fonts, saved in LibreOffice 3.6.2.1
Comment 3 Yury 2012-09-30 12:26:01 UTC
Created attachment 67884 [details]
2fonts_kword
Comment 4 Yury 2012-09-30 12:26:29 UTC
Created attachment 67885 [details]
2fonts_libo
Comment 5 Yury 2012-09-30 12:26:52 UTC
Created attachment 67886 [details]
2fonts_tm2008
Comment 6 Yury 2012-09-30 12:27:15 UTC
Created attachment 67887 [details]
2fonts_tm2012
Comment 7 Yury 2012-09-30 12:27:37 UTC
Created attachment 67888 [details]
4fonts_kword
Comment 8 Yury 2012-09-30 12:27:57 UTC
Created attachment 67889 [details]
4fonts_libo
Comment 9 Yury 2012-09-30 12:28:17 UTC
Created attachment 67890 [details]
4fonts_tm2008
Comment 10 Yury 2012-09-30 12:28:38 UTC
Created attachment 67891 [details]
4fonts_tm2012
Comment 11 Yury 2012-10-08 07:52:53 UTC
I believe the problem stems from the following:

1) math fonts always include some of the "tall" mathematical operators glyphs, like U+2211 summation or U+222b integral, arcs' glyphs from Misc. technicals block at U+2300 etc.; 

2) and such glyphs, not only being "tall" (I believe I've seen sizes of those doubling the usual ("header") em size of the font) as like as not are positioned "under" the baseline, either completely or partly; e.g., integral might span smth. like [+1000..-300] or [+2000..-2000] etc.

3) and such info is summarized in fontconfig cache, I guess;

4) LIBO, if built with fontconfig support, looks into these cache files and this is where things go wrong - instead of proceeding with the info from font header (em size and baseline), which also is available there, I believe, LIBO takes on the extremum dimensions of the font. (And other offices don't!)

I would greatly appreciate somebody looking into this ASAP, as this is quite a pain. None of the specialised math fonts are usable, how's that for the leading OSS productivity suite?!
Comment 12 Khaled Hosny 2012-12-26 05:29:00 UTC
The problem is that those fonts have very large WinAscent/WinDescent value in the OS/2 table (otherwise large math glyphs will be clipped on Windows). LibreOffice, erroneously, uses WinAscent/WinDescent to calculate line height instead of the, appropriate, TypoAscender/TypoDescender values in the same table.

This have been fixed a while ago, but it was later disabled by default for reasons I don’t remember, you have to set SAL_USE_NEW_LINEHEIGHT env variable to enabled the new and correct behaviour.

IMO, this should be enabled unconditionally as it affects many other fonts not only math ones.
Comment 13 Yury 2012-12-26 10:32:51 UTC
Thank you very much, Khaled! This works!

May I congratulate you on your fine work on XITS and Neo Euler, too. :)

I wouldn't close the issue as FIXED yet. Why such a major issue wasn't mentioned at least in a launching script?

And could you give #56076 a look, please? That's sort of a last major showstopper with regard to the font handling in LibO.
Comment 14 Khaled Hosny 2012-12-26 15:34:16 UTC
(In reply to comment #13) 
> I wouldn't close the issue as FIXED yet. Why such a major issue wasn't
> mentioned at least in a launching script?

I’ve no idea, I provided a fix that was enabled unconditionally, then it was disabled unless that environment variable is set.
 
> And could you give #56076 a look, please? That's sort of a last major
> showstopper with regard to the font handling in LibO.

Sorry, but I’m not really that familiar with LibreOffice internals, the code is complex and convoluted, it is a traumatizing experience overall so I try not do do it again :)
Comment 15 Khaled Hosny 2013-05-13 14:42:37 UTC
Should be fixed in master (note that STIX Math still has excessive interline space, but that is what the font is telling us to use).
Comment 16 Yury 2013-06-07 19:43:59 UTC
Are you sure it's fixed good? I've tested the 4.1.0.2 right now, and several math fonts for which I'd previously had to set the SAL_USE_NEW_LINEHEIGHT, have correct spacing now.

HOWEVER, the Charter (which I put together from Charter's Cyrillisation and TeX maths) has wrong spacing in 4.1.0.2 -- but it has correct spacing in 3.6.5.2 which I use with SAL_USE_NEW_LINEHEIGHT set.
Comment 17 Yury 2013-06-07 19:52:23 UTC
...and SAL_USE_NEW_LINEHEIGHT isn't working in 4.1.0.2. Ha.
Comment 18 Khaled Hosny 2013-06-07 20:12:29 UTC
Part of this code was reverted to temporary fix bug 65132, when the real cause is identified and fixed it will be restored.
Comment 19 Khaled Hosny 2013-06-22 10:28:18 UTC
SAL_USE_NEW_LINEHEIGHT was just a temporary solution and have been dropped, line spacing should now be “correct” by default. Where can I get the Charter font you are refering to?
Comment 20 Yury 2013-06-22 11:46:17 UTC
Created attachment 81208 [details]
LibO 4.1.0.1 with Charter and Neo Euler in text and formula
Comment 21 Yury 2013-06-22 11:48:03 UTC
Created attachment 81209 [details]
proofpic of what's showing
Comment 22 Yury 2013-06-22 11:48:43 UTC
Created attachment 81211 [details]
self-made Charter
Comment 23 Yury 2013-06-22 11:49:11 UTC
Created attachment 81212 [details]
self-made Charter Italic
Comment 24 Yury 2013-06-22 11:52:28 UTC
It might be the font, but how come fonts previously shown incorrect are shown okay now (e.g., Neo Euler)?

Now, this font exists like in single copy in the world :) I guess it's okay if I attach it.

The font was "made" by me from Sergey Sharashkin derivation of Charter, made in 1999. I've only added two or three composite ref glyphs and merged Charter math fonts PFBs from TeX site. However, those pesky math glyphs seem to strike again.
Comment 25 Khaled Hosny 2013-06-22 12:12:46 UTC
(In reply to comment #24)
> It might be the font, but how come fonts previously shown incorrect are
> shown okay now (e.g., Neo Euler)?
> 
> Now, this font exists like in single copy in the world :) I guess it's okay
> if I attach it.
> 
> The font was "made" by me from Sergey Sharashkin derivation of Charter, made
> in 1999. I've only added two or three composite ref glyphs and merged
> Charter math fonts PFBs from TeX site. However, those pesky math glyphs seem
> to strike again.

Your Charter Roman font have very large hhea metrics that is different from the italic font as well as OS/2 metrics. The OS/2 metrics are correct, and that is why it was fine before, now we give priority to hhea metrics for better compatibility with other applications (virtually any other Linux or Mac OS X application). I suggest you edit the font and give hhea the same values as OS/2 (which is best practice) and leave the Win metrics at their existing values since they are used for clipping.
Comment 26 Yury 2013-06-22 13:20:06 UTC
Thank you very much, and sorry for imposing on your time again, 
but would you coach me what to change and where, in FontForge?

I've read the http://fontforge.org/editexample5.html and http://fontforge.org/fontinfo.html but I seem to have NO 'hhea' table in the font.

In fields that actually are there, the values in the 'OS/2'->'Metrics' seem to be the same in all versions, even in version before the merge.
Comment 27 Khaled Hosny 2013-06-22 20:00:16 UTC
In OS/2 → Metrics uncheck the “Is Offset” to get the real values not the ones FontForge calculates based on font bounding box. Typo* and HHead* (that is the hhea table) should be the same for all the three fields in the two fonts.
Comment 28 Yury 2013-06-22 20:53:28 UTC
(In reply to comment #27)
> In OS/2 → Metrics uncheck the “Is Offset” to get the real values not the
> ones FontForge calculates based on font bounding box. Typo* and HHead* (that
> is the hhea table) should be the same for all the three fields in the two
> fonts.

...with HHea copying Typo values. So obvious, when someone knowledgeable explains it to you. :)

LibO 4.1.0.1 shows both that Charter and Neo Euler okay.

Thank you very much!
Comment 29 Yury 2013-06-25 04:36:23 UTC
This worked (rather, had no negative effect) with 3.6.5.2, too.

Interestingly, however, after I tried this corrected Charter on my laptop, which effectively differs only in Slackware version (3.* kernel, newer libs etc.), but has the same set of fonts and the same 3.6.5.2 LibO, I'm experiencing increased spacing there, in Charter-set text but not in Charter-set formulas.

What might have gone wrong? Fonts were copied from ~/.fonts to ~/.fonts. The *SAL_NEWHEIGHT* var is used both here and there.
Comment 30 Martin Sourada 2014-06-02 15:20:44 UTC
Hello,

I stumbled on this issue in 4.2.4.2 with Neo Euler and after some playing around I noticed when I disable the compatibility option for using printer metrics the problem is fixed as you suggest in this bug. I believe that shouldn't happen (i.e. the line spacing should be correct in both cases). Should I open new bug, reopen this one, or is that actually correct behaviour?

Martin
Comment 31 zeonchameleon 2014-10-30 06:56:14 UTC
Hello.

LibreOffice 4.2.6.3. Windows 7 64 bit.

Could you describe what settings actually should be to fix this problem? I tried several settings on Tools -> Options -> LibreOffice Writer -> Compatibility. I tried to fix it for STIX MATH, XITS MATH, Cambria MATH and Latin Modern MATH, but nothing works for me.
Comment 32 zeonchameleon 2014-10-30 06:58:49 UTC
Created attachment 108675 [details]
LibreOffice MATH fonts spacing
Comment 33 Khaled Hosny 2014-10-30 18:53:59 UTC
This was fixed only on Linux, Windows will need a separate fix. I think Mac OS X never suffered from this, so changing the affected OS accordingly.
Comment 34 Khaled Hosny 2016-10-19 09:27:05 UTC
*** Bug 90554 has been marked as a duplicate of this bug. ***
Comment 35 Khaled Hosny 2016-11-06 00:32:03 UTC
*** Bug 103730 has been marked as a duplicate of this bug. ***
Comment 36 Khaled Hosny 2016-11-06 00:36:36 UTC
I changed the title of the bug to reflect the current situation.

Right now we use different font parameters to determine the line spacing between Linux (or Mac) and Windows.

What we use on Linux is most likely the correct one as far as modern fonts and applications are concerned, but we do on Windows might be the backward-compatible one.

We need to clean this up and use the exact same parameters on all platforms.
Comment 37 madmalkav 2016-11-06 00:40:01 UTC
Created attachment 128525 [details]
Similar problem with japanese font

Problem with japanese font, added file per Khaled petition on #103730.
Comment 38 Andrea 2016-11-09 11:01:32 UTC
You can find another example on bug 98269

*** This bug has been marked as a duplicate of bug 98269 ***
Comment 39 Khaled Hosny 2016-11-09 13:18:58 UTC
*** Bug 98269 has been marked as a duplicate of this bug. ***
Comment 40 Commit Notification 2016-11-22 15:33:26 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=34d7602954d4483b3bc9db700e7df2c15348947a

tdf#55469 Consistent line spacing across platforms

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 41 madmalkav 2016-11-23 10:59:43 UTC
I can confirm the test file I linked in bug https://bugs.documentfoundation.org/show_bug.cgi?id=103730 shows the same now in Linux and Windows with the latest nightly build.
Comment 42 Andrea 2016-11-24 07:16:54 UTC
YEAH!!!
Perfectly spacing. 

Tried version  5.4.0.0.alpha0+
Build ID: d9a6e0023c9a192850b9db00f8120fbcc4256ec9
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-11-23_23:32:28
Locale: it-IT (it_IT); Calc: group

Many thanks!
Comment 43 Timur 2016-11-28 10:08:35 UTC
@madmalkav, @Andrea: if tested, then please set to Verified (I did it here).
@Khaled: please backport to 5.2 branch.
Comment 44 Khaled Hosny 2016-11-28 10:17:31 UTC
(In reply to Timur from comment #43)
> @Khaled: please backport to 5.2 branch.

Since this bug is as old as this code base, I don’t see a pressing need for backport, not without enough testing at least.
Comment 45 madmalkav 2016-12-08 17:10:09 UTC
*** Bug 44784 has been marked as a duplicate of this bug. ***
Comment 46 Khaled Hosny 2016-12-08 21:41:01 UTC
*** Bug 44784 has been marked as a duplicate of this bug. ***