Bug 83818 - Text selection highlight is incompletely rendered when using the HFW Cursive font
Summary: Text selection highlight is incompletely rendered when using the HFW Cursive ...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
Keywords: bibisected, regression
Depends on:
Reported: 2014-09-13 15:07 UTC by Yousuf Philips (jay) (retired)
Modified: 2015-12-15 11:03 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:

sample file (8.72 KB, application/vnd.oasis.opendocument.text)
2014-09-13 15:07 UTC, Yousuf Philips (jay) (retired)
LibO 4.0 (75.85 KB, image/png)
2014-09-13 15:13 UTC, Yousuf Philips (jay) (retired)
LibO 4.4 (76.52 KB, image/png)
2014-09-13 15:13 UTC, Yousuf Philips (jay) (retired)

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-09-13 15:07:00 UTC
Created attachment 106214 [details]
sample file

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.
Comment 1 Yousuf Philips (jay) (retired) 2014-09-13 15:13:15 UTC
Created attachment 106215 [details]
LibO 4.0
Comment 2 Yousuf Philips (jay) (retired) 2014-09-13 15:13:33 UTC
Created attachment 106216 [details]
LibO 4.4
Comment 3 Yousuf Philips (jay) (retired) 2014-09-13 15:15:30 UTC
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.
Comment 4 tommy27 2014-10-18 02:58:44 UTC
I don't reproduce it with LO under Win7x64 
must be Linux specific
Comment 5 Yousuf Philips (jay) (retired) 2014-10-18 09:10:20 UTC
Confirmed that this doesnt happen on Windows.
Comment 6 Buovjaga 2014-11-15 08:58:57 UTC
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:
Build ID: 5bff4b016c4b44f4123e0e6a4fd4c0c4dc0cfa2d
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-13_00:14:29
Comment 7 Yousuf Philips (jay) (retired) 2014-11-15 14:46:30 UTC
(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.

Build ID: 89db5b5b88508e55bce50240d248dd26053f4e09
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-11-12_20:58:53
Comment 8 Buovjaga 2014-11-15 15:07:25 UTC
Ok let's set to NEW, then, even though my result was a bit different with the bottom of the text being invisible.
Comment 9 Matthew Francis 2014-12-21 15:29:19 UTC
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

    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
Comment 10 Matthew Francis 2014-12-21 15:52:40 UTC
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
    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
Comment 11 Khaled Hosny 2014-12-21 21:53:37 UTC
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.
Comment 12 Yousuf Philips (jay) (retired) 2014-12-30 14:59:12 UTC
Closing according to Khaled's recommendation.
Comment 13 Robinson Tryon (qubit) 2015-12-15 11:03:08 UTC
Migrating Whiteboard tags to Keywords: (bibisected)