Bug Hunting Session
Bug 83581 - caret does not enter ligature; easy to insert at wrong place
Summary: caret does not enter ligature; easy to insert at wrong place
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2014-09-07 09:39 UTC by dE
Modified: 2019-08-10 12:51 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Edit comment and follow description to reproduce bug. (11.92 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-09-07 09:39 UTC, dE
Details
PDF export to show used font replacement (483.29 KB, application/pdf)
2019-08-10 12:51 UTC, Johnny_M
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dE 2014-09-07 09:39:04 UTC
Created attachment 105855 [details]
Edit comment and follow description to reproduce bug.

In the attached document, edit the comment in the first cell.

Attempt to move the text cursor between t and i of the first world.

Now attempt to correct the spelling by inserting a 't' between i and o.
Comment 1 Terrence Enger 2014-09-07 16:30:34 UTC
Just to ease the suspense left at the end of the bug description,
using a caret to represnt the position of the caret,
(*) comment as displayed : competi^ors ate them
(*) type "t"
(*) result expected      : competit^ors ate them
(*) result observed      : competti^ors ate them

This behaviour seems to have been introduced in the ranged covered by
the daily dbgutil bibisect.  But dE reported seeing this in
LibreOffice version 4.2.5.2 release.  dE, are you sure about that?

I am setting platform to "Linux (All)", where I see the problem.  dE,
if you see it in a different environment, please set platform "All".


Bibisecting, I see from `git bisect good`:

    cbed87a20815ddd7af3afb31aa2fc7a29383ce89 is the first bad commit
    commit cbed87a20815ddd7af3afb31aa2fc7a29383ce89
    Author: Miklos Vajna <vmiklos@collabora.co.uk>
    Date:   Mon Jul 14 09:12:54 2014 +0200

        2014-07-14

    :100644 100644 e1fc757cdd55bdb9ef99cf03fa94bf273d3d4d89 31508c1bfc531c49bd73b38b184179cff25888fd M	build-info.txt
    :040000 040000 6de0846dd12d8771050276833a090bd4f845e838 98aff976032316877f486cf07bac7a0220ff532b M	opt

and from `git bisect log`:

    # bad: [df3584a60c00673e5f5b4b09bfbe1be300a144fc] 2014-09-07
    # good: [b3130c846de5cf1b4be48b48dfc780bb369549fa] 2014-05-21
    git bisect start 'origin/master' 'oldest'
    # bad: [cbed87a20815ddd7af3afb31aa2fc7a29383ce89] 2014-07-14
    git bisect bad cbed87a20815ddd7af3afb31aa2fc7a29383ce89
    # good: [35c0f684cef2fdbe270ff9d3b37169731ef61033] 2014-06-17
    git bisect good 35c0f684cef2fdbe270ff9d3b37169731ef61033
    # good: [863ef6c16b358103654ddcae453401e7a5c4a69e] 2014-06-30
    git bisect good 863ef6c16b358103654ddcae453401e7a5c4a69e
    # good: [329f284cf0438c52859ca4facd4f4950594352e1] 2014-07-07
    git bisect good 329f284cf0438c52859ca4facd4f4950594352e1
    # good: [aa277ae886d6e38dad4a356ebd6a1d6c96f5f084] 2014-07-10
    git bisect good aa277ae886d6e38dad4a356ebd6a1d6c96f5f084
    # good: [8c3f4fcfdbbd570efea0a46c219eab24fd5db44c] 2014-07-12
    git bisect good 8c3f4fcfdbbd570efea0a46c219eab24fd5db44c
    # good: [a5750a3c0c5d3b975a787f844d7ba60db53a765e] 2014-07-13
    git bisect good a5750a3c0c5d3b975a787f844d7ba60db53a765e
    # first bad commit: [cbed87a20815ddd7af3afb31aa2fc7a29383ce89] 2014-07-14
Comment 2 Andras Timar 2014-09-11 18:49:19 UTC
bisection is wrong, because the bug can be reproduced with good: [a5750a3c0c5d3b975a787f844d7ba60db53a765e] 2014-07-13, too.

The problem is that caret jumps over "ti" in one step, when you press -> once, it is "logically" after "t". When you press  ->  once more caret stands still, but the it is after "i".
Comment 3 Andras Timar 2014-09-11 20:58:06 UTC
Bisection did not make much sense in this case, it turned out that eb79c13a809c2edf99042b114ede512ebd4c2273 is the first bad commit
commit eb79c13a809c2edf99042b114ede512ebd4c2273
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Thu Oct 10 10:12:44 2013 +0100

    update local font.conf for Calibri/Carlito Cambria/Caladea
    
    Change-Id: I9391876f2b09750ad5f44483f489743581948d21

Maybe the substituted font (Carlito) reports wrong metrics to LibreOffice.
Comment 4 Terrence Enger 2014-09-11 21:46:31 UTC
@Andras

You are exactly right.  I should have been more willing to believe the
bug description.  Then I would not have reported bibisect results
which are pure noise, with "good" and "bad" depending on nothing more
than how I moved the caret before typing the "t".  Desk, meet forehad.

@all

The comment is in font Calibri, but the combination of LibreOffice and
my setup provoke the font control to show mouseover message "Font
name.  The current font name is not available and will be
substituted."  When the (substituted?) font displays "ti" with a
ligature, the caret as rendered does not move inside the ligature;
without a ligature, the bug is not evident.  In the buggy version,
text within a cell behaves the same way as the comment.

For comparison, in a bibisect version where Calc displays the bug,
Writer displays the same "... substituted." mouseover for font
Calibri, there is a ligature "ti", but the caret happily shows itself
within the ligature when it is logically within the ligature.

I have rewritten the bug summary in line with my observations here.
Improvements welcome, of course.

Terry.
Comment 5 Terrence Enger 2014-10-14 16:40:18 UTC
Further to results from daily dbgutil bibisect:

    test       date        commit   source hash
    ---------  ----------  -------  -----------
    last good  2014-07-13  a5750a3  dde00f1
    first bad  2014-07-14  cbed87a  f445ae5
Comment 6 Matthew Francis 2014-12-31 06:14:51 UTC
The below is the commit at which I see the issue appear.

(*1 Comment 5 appears to be a red herring - it's easy to mistake this, but to reproduce properly you have to make sure using the cursor keys that the actual (not visible) position of the cursor is inside the ligature)
(*2 The previous suggestion of commit eb79c13a809c2edf99042b114ede512ebd4c2273 perhaps applies if there is an externally packaged Carlito available? The end result is of course the same)


Adding Cc: to caolanm@redhat.com; Can you tell if this is our bug or somehow an issue within the font itself?


commit bde5e683286096b9255254b28a862e519d57f547
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Wed Oct 23 14:57:32 2013 +0100

    bundle Carlito and Caladea
    
    Change-Id: Ibb68ad33764bcbab88e68c35805a00287177a5c8
Comment 7 Robinson Tryon (qubit) 2015-12-13 11:11:09 UTC Comment hidden (obsolete)
Comment 8 Xisco Faulí 2016-09-26 14:53:48 UTC
Adding Cc: to Caolán McNamara
Comment 9 Khaled Hosny 2016-10-19 08:35:46 UTC
No problem with ligatures in Writer, can someone test with other LO components? Might be editeng-specific.
Comment 10 Terrence Enger 2016-12-07 16:00:27 UTC
Working in the daily Linux dbgutil bibisect repository version
2016-12-07, I see the problem still present in Calc and Impress.

In Calc, it is necessary to turn of automatic spellchecking before the
pop-up menu offers "edit comment".
Comment 11 Khaled Hosny 2017-05-17 22:51:43 UTC
Probably a limitation of Edit Engine that is used by modules other than Writer, since Writer handles caret inside ligatures fine.
Comment 12 QA Administrators 2018-05-18 02:32:43 UTC Comment hidden (obsolete)
Comment 13 Khaled Hosny 2018-05-21 11:28:46 UTC
Still an issue.
Comment 14 QA Administrators 2019-05-22 02:52:20 UTC Comment hidden (obsolete)
Comment 15 Terrence Enger 2019-06-04 20:32:02 UTC
I still see the bug in 6.3 bibisect repository, source hash 41bdaf4a,
2019-06-04.
Comment 16 Johnny_M 2019-08-10 12:51:12 UTC
Created attachment 153284 [details]
PDF export to show used font replacement

Another example in Impress (taken over from bug 116010 comment 3):

1. Open attachment 135454 [details] (bug 111681)
2. Try selecting with the mouse the individual characters "eff" of the word "effect"

Actual results:
2. Only the whole "eff" can be selected. (But when selected with Shift+Arrows, "e" and "ff" can be selected separately. While each "f" separately can't be anyway.)

Appending “:-liga” to the font name works around the issue.

Attaching a PDF export on the following, to show the replacement font used (DejaVu Sans):
Version: 6.2.5.2
Build ID: 1:6.2.5-0ubuntu0.19.04.1
CPU threads: 4; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: de-DE (en_US.UTF-8); UI-Language: en-US
Calc: threaded