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.
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
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".
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.
@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.
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
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
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Adding Cc: to Caolán McNamara
No problem with ligatures in Writer, can someone test with other LO components? Might be editeng-specific.
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".
Probably a limitation of Edit Engine that is used by modules other than Writer, since Writer handles caret inside ligatures fine.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still an issue.
Dear dE, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I still see the bug in 6.3 bibisect repository, source hash 41bdaf4a, 2019-06-04.
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
A bug inherited from OOo can't be a regression. -> back to version 4.2.5.2. Still reproducible with LO 7.3.1.0.0+ and Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 3e9975cf507e24e9c501575c501833164d217acc CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: en-US Ubuntu_20.04_x86-64 Calc: threaded Is the problem in LO or in Carlito font? Can someone do the test with another text processor with Carlito font? Best regards. JBF
(In reply to Jean-Baptiste Faure from comment #17) > Is the problem in LO or in Carlito font? Can someone do the test with > another text processor with Carlito font? The bug is not unique to the Carlito font. It also appears with other fonts using ligatures, e.g., DejaVu Sans used as replacement for Lato in the comment 16. (Compare the test ODP in that comment using Lato, which is not available on the used machine, with its PDF export using DejaVu Sans, which is the replacement font actually used on the machine. The bug occurs with it as well. Same as if one changes the font to Carlito in that test ODP, with Carlito being available on the machine.)
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/79152891824581ad765dc8518150027c417bb9a2 tdf#83581: Improve caret travelling in in Edit Engine It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
fix verified in: Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: da3dd48eaf9086f8ab28d6a6655f9a638e51433a CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded