Created attachment 106214 [details] sample file Steps: 1) Download and install HFW cursive font - https://www.dropbox.com/s/q9bwhyvzlmi825o/HfW%20cursive.TTF?dl=0 2) Open attached file 3) Select the text. Tested in 4.1.6 and 4.3.3 on Linux. It works correctly in 4.0.6.
Created attachment 106215 [details] LibO 4.0
Created attachment 106216 [details] LibO 4.4
After making the selection with only the upper half selected, if you scroll down and then back up, the bottom part of the word wont be rendered unless you which to another app and then back.
I don't reproduce it with LO 4.3.2.2 under Win7x64 must be Linux specific
Confirmed that this doesnt happen on Windows.
You tried on Ubuntu? Maybe this is an Ubuntu bug or an issue with the font itself. The Font viewer displayed it with lines overlapping. Writing in LibO, only the upper half of the text is visible. Line spacing setting does nothing to the situation. Ubuntu 14.10 64-bit Version: 4.4.0.0.alpha2+ Build ID: 5bff4b016c4b44f4123e0e6a4fd4c0c4dc0cfa2d TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-13_00:14:29
(In reply to Beluga from comment #6) > You tried on Ubuntu? Maybe this is an Ubuntu bug or an issue with the font > itself. The Font viewer displayed it with lines overlapping. Writing in > LibO, only the upper half of the text is visible. Line spacing setting does > nothing to the situation. I run on Linux Mint, which is pretty much Ubuntu. Doubt its a problem with the font if it works correctly in 4.0.6 and doesnt after that. Just checked now and it works correctly in Calligra Words as well, so definitely a LO problem. Confirmed that its in master as well. Version: 4.4.0.0.alpha2+ Build ID: 89db5b5b88508e55bce50240d248dd26053f4e09 TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-11-12_20:58:53
Ok let's set to NEW, then, even though my result was a bit different with the bottom of the text being invisible.
Bibisect results from 43all: e2a9149a7723f4e00eb3cafe466e204e5da19e9c is the first bad commit commit e2a9149a7723f4e00eb3cafe466e204e5da19e9c Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Thu Oct 17 05:01:44 2013 +0000 source-hash-2ede6c95e6481c92cc199e7d74fd36c841636304 commit 2ede6c95e6481c92cc199e7d74fd36c841636304 Author: Khaled Hosny <khaledhosny@eglug.org> AuthorDate: Sun May 12 17:59:50 2013 +0200 Commit: Khaled Hosny <khaledhosny@eglug.org> CommitDate: Sun May 12 18:47:36 2013 +0200 Some logging Change-Id: I4515d4d6760e22ce4d77fbb3cbce93e3ce097b98 # bad: [c2069a369d738078124812312d51f21ea1ce2421] source-hash-f160e4935c474a5293b3d3c11b3d538efb4767a0 # good: [a71a4447320f177181c9cff9f7c6fd93802cbd8e] source-hash-9afb6e1e38c362a768e8e981f7b03cf8bcaf22cf git bisect start 'last41onmaster' 'last36onmaster' # good: [7fa43e1a1b181ccdcb395c16788a66c591b63045] source-hash-41c2b0375773b2d2945d75e255ea6bb6c7fd378d git bisect good 7fa43e1a1b181ccdcb395c16788a66c591b63045 # good: [beaf8d511be9863b1369a1889151302498fb63c9] source-hash-1890f4ba4c0b345a73185adf320d06d0974f644b git bisect good beaf8d511be9863b1369a1889151302498fb63c9 # good: [fa884dc86639e1925692df2117e53599726e366d] source-hash-86fd1240bbbb8ee72899abc24daf5e4402a61add git bisect good fa884dc86639e1925692df2117e53599726e366d # good: [ba45b2fb759b79ac39d73851bacc5ce216531318] source-hash-2b449f5f9ad126618ec85d442ec149c5864853de git bisect good ba45b2fb759b79ac39d73851bacc5ce216531318 # good: [3894c5d4955cdef8187b35e8d3eeb37ecdf8d7b7] source-hash-a2c34b3d9ac2d7e43e52846308cc63447fd51f23 git bisect good 3894c5d4955cdef8187b35e8d3eeb37ecdf8d7b7 # bad: [38e06ae137e1dcaaaf82127b977869499742bd94] source-hash-3fb33e3e04c7f339e1e15d24529e8ea1d4dbe321 git bisect bad 38e06ae137e1dcaaaf82127b977869499742bd94 # bad: [e2a9149a7723f4e00eb3cafe466e204e5da19e9c] source-hash-2ede6c95e6481c92cc199e7d74fd36c841636304 git bisect bad e2a9149a7723f4e00eb3cafe466e204e5da19e9c # good: [7735ac016add3b7e4b96d6017919a828e3271a0a] source-hash-923312f67fbf120158f01c2c0e588af38fc22364 git bisect good 7735ac016add3b7e4b96d6017919a828e3271a0a # first bad commit: [e2a9149a7723f4e00eb3cafe466e204e5da19e9c] source-hash-2ede6c95e6481c92cc199e7d74fd36c841636304
Within the above bibisect range, I would say that the following two commits are strong candidates Adding Cc: to khaledhosny@eglug.org. Could you possibly shed any light on this one? Thanks commit f9560c8f9982eaef09b74baa479c187f049c4f9e Author: Khaled Hosny <khaledhosny@eglug.org> Date: Sat May 11 07:07:29 2013 +0200 Cleanup FreeType ascender/descender handling a bit Change-Id: I9734f15811020ce1a7b761688d602c7e244167c7 commit 5e77c9e17ba7dd9d296c9b755093f01e7eb4f514 Author: Khaled Hosny <khaledhosny@eglug.org> Date: Sat May 11 00:50:59 2013 +0200 Revert 052f181dad89ad34d90513bc9dcd3e3239727933 Which in itself was effectively a revert of 3364fefe1e2dec522211040f2f9ea37bf5cd7466 Keeping the old broken line height calculation code is just masking of the real problem; there are some code elsewhere that have fragile workarounds to the real bug here (the removed code here shows a good example of such workarounds). On Mac we use the correct metrics as well, so we need to find the quirks and fix them, instead of pretending they do not exist. This fixes fdo#55469, among others. Change-Id: I36f13b28eaba022b7c388feae7e0bfd0ed1c3e89
The font is broken, it has a positive OS/2 sTypoDescender but this must be negative for values below base line (http://www.microsoft.com/typography/otspec/os2.htm#std), the same for hhea Descender (http://www.microsoft.com/typography/otspec/hhea.htm). It worked before the mentioned change because LibreOffice was incorrectly using usWinDescent (http://www.microsoft.com/typography/otspec/os2.htm#wd) and there positive means below baseline. I’d close this as NOTOURBUG, nothing for us to fix here.
Closing according to Khaled's recommendation.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]