Bug 107605 - Formatting fonts with bad metrics causes line height problems, e.g. Cardo
Summary: Formatting fonts with bad metrics causes line height problems, e.g. Cardo
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.2.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Khaled Hosny
URL:
Whiteboard: target:6.0.0 target:5.4.3
Keywords:
: 104216 112824 (view as bug list)
Depends on:
Blocks: Font-Rendering Paragraph-Line-Spacing Universal-Line-Spacing
  Show dependency treegraph
 
Reported: 2017-05-03 20:07 UTC by Phillip Ross
Modified: 2017-12-06 08:21 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
PDF version of a page (74.22 KB, application/pdf)
2017-05-07 12:24 UTC, Phillip Ross
Details
OTT Book Template File (219.81 KB, application/vnd.oasis.opendocument.text-template)
2017-05-07 18:29 UTC, Phillip Ross
Details
Cardo font from http://scholarsfonts.net/cardofnt.html (broken) (392.46 KB, image/png)
2017-05-15 00:36 UTC, Khaled Hosny
Details
Cardo font from https://fonts.google.com/specimen/Cardo (good) (224.23 KB, image/png)
2017-05-15 00:37 UTC, Khaled Hosny
Details
Screenshot of Futura-Book in Writer and Calc (53.60 KB, image/png)
2017-10-10 11:52 UTC, Thomas Lendo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Phillip Ross 2017-05-03 20:07:19 UTC
Description:
Formatting with Cardo font causes line height problem on screen.

Steps to Reproduce:
1. Open file using Cardo font.

Actual Results:  
Line height is squished, cannot fix with formatting.

Expected Results:
Line height should be like it used to be in former versions. I'm not sure when it began.


Reproducible: Always

User Profile Reset: Yes

Additional Info:
Version: 5.3.2.2 (x64)
Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

OS Name	Microsoft Windows 10 Home
Version	10.0.14393 Build 14393
Other OS Description 	Not Available
OS Manufacturer	Microsoft Corporation
System Name	USER-PC
System Manufacturer	Gateway
System Model	DX4831
System Type	x64-based PC
System SKU	To Be Filled By O.E.M.
Processor	Intel(R) Core(TM) i5 CPU         650  @ 3.20GHz, 3201 Mhz, 2 Core(s), 4 Logical Processor(s)
BIOS Version/Date	American Megatrends Inc. P01-A0, 11/17/2009
SMBIOS Version	2.6
Embedded Controller Version	255.255
BIOS Mode	Legacy
BaseBoard Manufacturer	Gateway
BaseBoard Model	Not Available
BaseBoard Name	Base Board
Platform Role	Desktop
Secure Boot State	Unsupported
PCR7 Configuration	Binding Not Possible
Windows Directory	C:\WINDOWS
System Directory	C:\WINDOWS\system32
Boot Device	\Device\HarddiskVolume1
Locale	United States
Hardware Abstraction Layer	Version = "10.0.14393.206"
User Name	user-PC\user
Time Zone	Eastern Daylight Time
Installed Physical Memory (RAM)	8.00 GB
Total Physical Memory	7.93 GB
Available Physical Memory	4.36 GB
Total Virtual Memory	9.18 GB
Available Virtual Memory	4.82 GB
Page File Space	1.25 GB
Page File	C:\pagefile.sys
Hyper-V - VM Monitor Mode Extensions	Yes
Hyper-V - Second Level Address Translation Extensions	Yes
Hyper-V - Virtualization Enabled in Firmware	Yes
Hyper-V - Data Execution Protection	Yes



User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.82 Safari/537.36 Vivaldi/1.9.818.44
Comment 1 Buovjaga 2017-05-07 10:22:56 UTC
What do you mean "line height is squished"? Like, the lines overlap? The line height is slightly smaller? Does it happen with fresh documents?

I had Cardo installed thanks to Google font pack and I don't see any difference between 3.6 and 5.4.

Please include screenshots of before and after.
You can install older versions in parallel: https://wiki.documentfoundation.org/Installing_in_parallel/Windows

For testers: https://fonts.google.com/specimen/Cardo

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.0.0.alpha1+
Build ID: 6e4cba99bb35e6697b94309eedd1a08ebea2dc68
CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on May 5th 2016

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the screenshots.
Comment 2 Phillip Ross 2017-05-07 12:24:13 UTC
Created attachment 133123 [details]
PDF version of a page

The fault is carried into the PDF print. This document was created in previous versions of LibreOffice and worked very well.
Comment 3 Buovjaga 2017-05-07 12:35:33 UTC
Please attach an example .odt document showing the problem.

I cannot reproduce even on Windows:
Version: 5.3.3.1 (x64)
Build ID: 46360c72c4823cefeaa85af537fba22bd568da7e
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
Locale: fi-FI (fi_FI); Calc: grou
Comment 4 Phillip Ross 2017-05-07 18:29:49 UTC
Created attachment 133140 [details]
OTT Book Template File

Wherever the text wraps the line height is compressed.
Comment 5 V Stuart Foote 2017-05-08 11:43:40 UTC
On Windows 10 Home 64-bit en-US with Cardo Regular downloaded and installed with
Version: 5.3.3.2 (x64)
Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448
CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

Sorry, can not reproduce using Dummy Text (DT -> f3) nor using the provided .ott

The "_Body" style of the template correctly composes paragraphs, with no "squish" evident in the paragraphs rendered, including copying text from the PDF and paste special.

The PDF does look to be composed with Cardo (T, C, O) so assume the font is installed and active.
Comment 6 Buovjaga 2017-05-08 19:55:26 UTC
(In reply to Phillip Ross from comment #4)
> Created attachment 133140 [details]
> OTT Book Template File
> 
> Wherever the text wraps the line height is compressed.

Yep, this works for me on Windows as well.

As you have OpenGL enabled, I wonder if it's something to do with it.

Can you open this file in a text editor and copy and paste the contents to a comment: C:\Users\User\AppData\Roaming\LibreOffice\4\cache\opengl_device.log
Comment 7 Phillip Ross 2017-05-08 20:56:01 UTC Comment hidden (obsolete)
Comment 8 Buovjaga 2017-05-09 05:23:04 UTC Comment hidden (obsolete)
Comment 9 Phillip Ross 2017-05-09 13:35:09 UTC Comment hidden (obsolete)
Comment 10 Buovjaga 2017-05-09 13:38:44 UTC Comment hidden (obsolete)
Comment 11 Phillip Ross 2017-05-09 13:45:26 UTC
Oops, my bad.

Here it is:

DriverVersion: 21.21.13.4201
DriverDate: 11-14-2016
DeviceID: PCI\VEN_10DE&DEV_0A22&SUBSYS_1141174B&REV_A2
AdapterVendorID: 0x10de
AdapterDeviceID: 0x0a22
AdapterSubsysID: 0x1141174b
DeviceKey: System\CurrentControlSet\Control\Video\{48D7E5FD-2E88-4EBC-A9F2-E2583CDBE6DB}\0000
DeviceString: NVIDIA GeForce 315
Comment 12 Buovjaga 2017-05-09 13:50:58 UTC
Thanks, adding to the [META] VCL/OpenGL tracker bug for 5.0+
Comment 13 lilmax88 2017-05-14 01:16:53 UTC
I also had this line height issue (perhaps better called a baseline issue?) I would describe it as the Cardo text was "rendering" hidden 50% below the evident baseline. 

I use a small number of fonts on a regular basis and this is my go-to body text font. I'm not sure whether others are affected. A random sample of 10 other fonts showed none.

Version: 5.3.2.2 (x64)
Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

--
Since you were talking about OpenGL, my Options shows:
Hardware acceleration: yes
anti-aliasing: yes
use openGL for all rendering: no
ignore opengl blacklist: no
"GL is currently disabled"

--
Would any of the Writer compatibility settings for space around paragraphs have an impact here? A few of them were ticked, but no change when I cleared them.

--
An interesting behavioral note: the effect of hiding some portion of a line of text is more severe when zoomed in more. But there is still no zoom level at which the paragraphs look like what their formatting says they should look like (e.g. single line spacing with .08 inch below the paragraph).

Happy to follow up and help solve this.
Comment 14 V Stuart Foote 2017-05-14 03:38:24 UTC
Folks reporting this are on GPUs not capable of running OpenGL, so does disabling "Use hardware acceleration" to render with CPU only affect things with rendering Cardo?

Tools -> Options -> View show nothing checked in the Graphics Output section.
Comment 15 V Stuart Foote 2017-05-14 05:21:47 UTC
So I was able to reproduce effect on Windows 10 Pro 64-bit en-US with
Version: 5.3.3.2 (x64)
Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default or GL; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

Using the v 1.045 build of Cardo Regular from http://scholarsfonts.net/cardofnt.html  the Font metrics are bad. Confirmed they render readable through the 5.2 builds.

I was able to correct them with FontCreator forcing use of Typo Metrics for spacing.  But otherwise the FontSquirrel offering of Cardo Regular 1.0451 has metrics functional at 5.3.

Believe this manifests now because we used to handle fonts differently by platform. Corrected with Khaled's work on bug 55469, see commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=34d7602954d4483b3bc9db700e7df2c15348947a 

@Khaled?  Could you have a look at the metrics for these versions of the Cardo font and at how they render at 5.3 on Windows builds. Would say it is not our bug--but how many fonts like this are out there to annoy users? Could the line spacing work be tweaked further to guard against this?

=-links-=

This set has unusable metrics and mapping with the 1.045 build:
http://scholarsfonts.net/cardo104.zip

This set seems has correct metrics and Unicode mapping with the 1.0451 build: https://www.fontsquirrel.com/fonts/download/cardo

assume there are other sources of the font with functional metrics.
Comment 16 lilmax88 2017-05-14 18:21:52 UTC
I was also able to update to the revised font and alleviate the spacing/baseline issues. Thanks.
Comment 17 Khaled Hosny 2017-05-15 00:35:18 UTC
The font is broken, there is nothing we should do about this. There are already fixed versions of the font, like the one available from Google Fonts (https://fonts.google.com/specimen/Cardo). LibreOffice is not the only application suffering from this brokenness.
Comment 18 Khaled Hosny 2017-05-15 00:36:39 UTC
Created attachment 133317 [details]
Cardo font from http://scholarsfonts.net/cardofnt.html (broken)

Here is how the font from http://scholarsfonts.net/cardofnt.html looks like in the font viewer.
Comment 19 Khaled Hosny 2017-05-15 00:37:53 UTC
Created attachment 133318 [details]
Cardo font from https://fonts.google.com/specimen/Cardo (good)

Here is how the version from https://fonts.google.com/specimen/Cardo looks like in the same font viewer.
Comment 20 Khaled Hosny 2017-05-15 00:40:21 UTC
if someone really cares about this, please contact the upstream author to fix the font metrics, the fix should be a 5 minutes job and everyone would be happy, instead of carrying a work around in LibreOffice and any other affected application forever.
Comment 21 Khaled Hosny 2017-10-03 18:02:09 UTC
I think we better fix this on our side after all.

https://gerrit.libreoffice.org/#/c/43095/
Comment 22 Commit Notification 2017-10-03 19:40:42 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9bc39be417a4c436cbe18391fc87e5e835551b07

tdf#107605: Fix line height cslculation for broken fonts

It will be available in 6.0.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 23 Khaled Hosny 2017-10-03 21:13:05 UTC
*** Bug 112824 has been marked as a duplicate of this bug. ***
Comment 24 Commit Notification 2017-10-04 15:00:58 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=538ea38afafb3d69cf5f492f783ca97caefce384&h=libreoffice-5-4

tdf#107605: Fix line height cslculation for broken fonts

It will be available in 5.4.3.

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 25 Thomas Lendo 2017-10-10 11:52:34 UTC
Created attachment 136892 [details]
Screenshot of Futura-Book in Writer and Calc

It seems that it got worse in current master builds for "Futura-Bold" font. See attachment. In Writer the font is completely invisible(? - in the screenshot there is no list item 4.) and in Calc it's at least visible that there is something.

Version: 6.0.0.0.alpha0+ (x64)
Build ID: 3343d0d4d80933f1436dc73ff84fc959f1bee050
CPU threads: 8; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-10-10_01:06:42
Locale: de-DE (de_DE); Calc: group
Comment 26 Khaled Hosny 2017-10-10 18:15:23 UTC
Can you send me that font privately, seems to be seriously broken.
Comment 27 Commit Notification 2017-10-13 21:42:07 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":

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

tdf#107605: Fix reading version 0 OS/2 font table

It will be available in 6.0.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 28 Commit Notification 2017-10-13 23:11:58 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e056ff15aa371dca9b887471846a537e13c4214c&h=libreoffice-5-4

tdf#107605: Fix reading version 0 OS/2 font table

It will be available in 5.4.3.

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 29 Thomas Lendo 2017-10-31 13:10:59 UTC
Khaled, thank you very much for your patch!

Set to VERIFIED FIXED.

Version: 6.0.0.0.alpha1+ (x64)
Build ID: 13c5dd1d98a480cb01ca8f24242c80e326e4ade8
CPU threads: 8; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-10-31_01:03:30
Comment 30 Volga 2017-12-06 08:21:28 UTC
*** Bug 104216 has been marked as a duplicate of this bug. ***