Bug 144261

Summary: Bad cursor positioning with Chinese input
Product: LibreOffice Reporter: CSLam <cslam>
Component: WriterAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED WORKSFORME    
Severity: normal CC: 79045_79045, suokunlong
Priority: medium    
Version: 7.2.0.4 release   
Hardware: x86-64 (AMD64)   
OS: Windows (All)   
Whiteboard:
Crash report or crash signature: Regression By:

Description CSLam 2021-09-02 07:49:08 UTC 
Description:
1. There are previous reports that Chinese character input is taking issue, and it is continuing so:
- apparently no issue using Times Roman font,
- snail slow when using Verdana font, which can be fixed by on-screen font substitution.

This slow issue is the sort of aggregating: starting afresh with a file is getting no issue, but as data is entered, the system will respond slower and slower, sometimes ending in a freeze requiring killing LibreOffice, because it cannot close itself.

2. Bad cursor positioning
- Where the cursor is seen at a location, new input goes to where the cursor previously was.  However, it looks it never hits when using cut-and-paste, which always places the text in the intended location;
- When entering data in Calc, Chinese characters are always grouped:
Keying: Chinese Part A - punctuation - Chinese Part B;
Result: Chinese Part A - Chinese Part B - punctuation;
- When keying in something in the search box, chance is there that the initial few characters (maybe one or two) go actually to the document, leaving the remaining in the box; it is not known if the search function is taking the entire input, or just what is remaining in the box;
- There are frequent scenarios that something that does exist in a file cannot be successfully searched (reporting not found), and recovery is closing the file and opening it again.

**

All these apparently point to a Chinese character positioning issue, which is taking great impact to normal use of LibreOffice.  I know there have been many slow reports in the past, but looks that there have no mention of a cursor position issue, which is far more serious that mere slowness.

Steps to Reproduce:
1.as described
2.
3.

Actual Results:
as described

Expected Results:
as described


Reproducible: Always


User Profile Reset: No



Additional Info:
as described
Comment 1 CSLam 2021-09-06 07:41:12 UTC 
When exporting a block of Write text for editing outside LibreOffice, take for example to Microsoft Word here, once pressing "paste" key in Word, Word will freeze for some moments, and in fact both LibreOffice and Word go to a halt together, and only after the said some moments (could be a minute) that things are back to life.  It looks LibreOffice is doing something to release the block of text.

Note:
This is way of life working with snail slow LibreOffice: editing text somewhere else, and then pasting it back to LibreOffice.  This perhaps is the last thing to do before abandoning Write, which is no longer friendly working with.
Comment 2 Roman Kuznetsov 2021-10-23 16:42:50 UTC 
Please attach some file example here
Comment 3 CSLam 2021-12-16 03:57:07 UTC 
Further to the reported, here are something more :-

1. When entering time IN A TABLE, HH:MM, it is slow response after entering ":", occasionally so slow that I would just move the cursor to the next stop waiting for the lagging ":MM" to come.  However, this sometimes ends up that "HH:MM" becomes "HH:00", and the "MM" appears in the new cursor location.

2. There are occaional occurences that timing information entered IN A TABLE, as HH:MM, will reset itself to "00:00".  This does not happen within the session, therefore things look just great.  Unfortuantely, when you open the file again, all your timing information is gone, replaced by the said "00:00".  It does not always happen, but does show up, perhaps once every 10 times.  This looks of great impact to the use of Write.

3. Everything descibed within this ticket does NOT happen when I work on the same in Linux LibreOffice: typing was just smooth no matter what fonts I am using, and I am actually using Verdana in Linux too, having this imported from my Windows folder in the same PC.  That is to say, the culprit in Windows contributes no trouble in Linux.

This points to some issue of LibreOffice settings with Windows, in particular the use of certain fonts (as said Times New Roman looks the exception, the use of which offers no trouble).  I know I have been asked to provide samples, but what has been described is something pretty straight forward, which I believe can easily be reproduced not necessarily dependant on a particular file.  After all, I cannot provide thus release the things to the public here.  My intention is to let the development team know the trouble.

I am happy enough with Linux LibreOffice, at least for the time being.
Comment 4 QA Administrators 2021-12-17 04:06:57 UTC Comment hidden (obsolete)
Comment 5 CSLam 2021-12-21 03:12:18 UTC 
The situation looks relieved following release of LibreOffice 7.2.4.1, which has a mention of "Improved font caching to speed up text rendering" in the release notes.  This perhpas is the core of all the issues.

Thank you for fixing this.
Comment 6 Kevin Suo 2021-12-21 03:15:55 UTC 
Thanks for testing and feeding back. In case we do not know the exact commit which fixed this issue, then we should mark it as RESOLVED WORKSFORME.