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
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.
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.
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
Created attachment 133140 [details] OTT Book Template File Wherever the text wraps the line height is compressed.
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.
(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 on attachment 133140 [details] OTT Book Template File C:\Users\User\AppData\Roaming\LibreOffice\4\cache\opengl_device.log Device Index: 0 Selected: true Device Name: GeForce 315 Device Vendor: NVIDIA Corporation Device Version: OpenCL 1.0 CUDA Driver Version: 342.01 Device Type: gpu Device Extensions: cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_d3d9_sharing cl_nv_d3d10_sharing cl_khr_d3d10_sharing cl_nv_d3d11_sharing cl_nv_copy_opts cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics Device OpenCL C Version: OpenCL C 1.1 Device Available: true Device Compiler Available: true Device Linker Available: false Platform Name: NVIDIA CUDA Platform Vendor: NVIDIA Corporation Platform Version: OpenCL 1.1 CUDA 6.5.51 Platform Profile: FULL_PROFILE Platform Extensions: cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_d3d9_sharing cl_nv_d3d10_sharing cl_khr_d3d10_sharing cl_nv_d3d11_sharing cl_nv_copy_opts
Hmm.. it seems you copied the contents of opencl_devices.log :) OpenCL is used for Calc calculations, while Open Gee L is used for graphical stuff.
Did I not copy what you asked me to copy?
(In reply to Phillip Ross from comment #9) > Did I not copy what you asked me to copy? No, you copied opencl_devices.log while I asked you to copy opengl_device.log
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
Thanks, adding to the [META] VCL/OpenGL tracker bug for 5.0+
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.
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.
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.
I was also able to update to the revised font and alleviate the spacing/baseline issues. Thanks.
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.
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.
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.
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.
I think we better fix this on our side after all. https://gerrit.libreoffice.org/#/c/43095/
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.
*** Bug 112824 has been marked as a duplicate of this bug. ***
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.
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
Can you send me that font privately, seems to be seriously broken.
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.
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.
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
*** Bug 104216 has been marked as a duplicate of this bug. ***