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.
Created attachment 67882 [details] file with two math fonts, saved in TextMaker 2012
Created attachment 67883 [details] file with four fonts, saved in LibreOffice 3.6.2.1
Created attachment 67884 [details] 2fonts_kword
Created attachment 67885 [details] 2fonts_libo
Created attachment 67886 [details] 2fonts_tm2008
Created attachment 67887 [details] 2fonts_tm2012
Created attachment 67888 [details] 4fonts_kword
Created attachment 67889 [details] 4fonts_libo
Created attachment 67890 [details] 4fonts_tm2008
Created attachment 67891 [details] 4fonts_tm2012
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?!
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.
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.
(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 :)
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).
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.
...and SAL_USE_NEW_LINEHEIGHT isn't working in 4.1.0.2. Ha.
Part of this code was reverted to temporary fix bug 65132, when the real cause is identified and fixed it will be restored.
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?
Created attachment 81208 [details] LibO 4.1.0.1 with Charter and Neo Euler in text and formula
Created attachment 81209 [details] proofpic of what's showing
Created attachment 81211 [details] self-made Charter
Created attachment 81212 [details] self-made Charter Italic
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.
(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.
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.
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.
(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!
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.
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
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.
Created attachment 108675 [details] LibreOffice MATH fonts spacing
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.
*** Bug 90554 has been marked as a duplicate of this bug. ***
*** Bug 103730 has been marked as a duplicate of this bug. ***
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.
Created attachment 128525 [details] Similar problem with japanese font Problem with japanese font, added file per Khaled petition on #103730.
You can find another example on bug 98269 *** This bug has been marked as a duplicate of bug 98269 ***
*** Bug 98269 has been marked as a duplicate of this bug. ***
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.
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.
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!
@madmalkav, @Andrea: if tested, then please set to Verified (I did it here). @Khaled: please backport to 5.2 branch.
(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.
*** Bug 44784 has been marked as a duplicate of this bug. ***