Bug 120586 - Editing a number with Track-Changes on can split it into two lines
Summary: Editing a number with Track-Changes on can split it into two lines
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: RTL-CTL Track-Changes
  Show dependency treegraph
 
Reported: 2018-10-14 14:34 UTC by Eyal Rozenberg
Modified: 2023-10-19 09:15 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Example of the bug manifesting with RTL, not with LTR (47.44 KB, image/png)
2018-10-14 14:34 UTC, Eyal Rozenberg
Details
Document with the bug manifesting (used for the earlier screenshot) (11.05 KB, application/vnd.oasis.opendocument.text)
2018-10-14 14:36 UTC, Eyal Rozenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2018-10-14 14:34:45 UTC
Created attachment 145708 [details]
Example of the bug manifesting with RTL, not with LTR

The line breaking logic LO Writer uses prevents numbers from being split in two at line breaks: Either the number fits on the earlier line, or, in its entirety, moved to the next line.

Now, if you're writing LTR text, and are in Track Changes mode, and edit a digit in the middle of a number which just exceeds the line length and has been moved to the next line - it will stay on the next line.

If, however, it's RTL text (I've tested with Hebrew) - the number will be broken up into two parts - before and after the the changes, with the latter part placed on the next line and the former part on the first line; see attached screenshot.
Comment 1 Eyal Rozenberg 2018-10-14 14:36:57 UTC
Created attachment 145709 [details]
Document with the bug manifesting (used for the earlier screenshot)

If font changes make the text look different on your system, type in or delete a few characters (but not in track changes mode) to make it so that the "1234" just exceeds the capacity of the first line, in each of the four paragraphs.
Comment 2 Eyal Rozenberg 2018-10-14 14:44:11 UTC
I've seen this with:

Version: 6.2.0.0.alpha0+
Build ID: ad6adb1bfadf49af3187a0bb3ceffbf355e9eed1
CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-09-29_02:45:20
Locale: en-US (en_IL); Calc: threaded

And Lior Kaplan reports reproduction with v5.1.6.2 . So - would appreciate a confirmation.
Comment 3 Shai Berger 2018-10-15 17:51:38 UTC
Reproduced as reported.

Version: 6.1.2.1
Build ID: 1:6.1.2-1
CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3; 
Locale: he-IL (en_IL); Calc: group threaded

(Debian Testing, from repository)
Comment 4 Xisco Faulí 2018-10-16 15:39:30 UTC
Reproduced back to

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 5 QA Administrators 2019-10-17 02:36:30 UTC Comment hidden (obsolete)
Comment 6 Eyal Rozenberg 2019-10-17 16:26:24 UTC
Still seeing this issue with

Version: 6.3.2.2
Build ID: 1:6.3.2-1
CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk3; 
Locale: he-IL (en_IL); UI-Language: en-US
Comment 7 QA Administrators 2021-10-17 03:54:39 UTC Comment hidden (obsolete)
Comment 8 Eyal Rozenberg 2021-10-17 06:33:13 UTC
Bug still manifests with:

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: c998691e22ceda15c89d55cf7005201f0392dadb
CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: en-US (en_IL); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-10-14_11:54:20
Comment 9 QA Administrators 2023-10-18 03:14:55 UTC Comment hidden (obsolete)
Comment 10 Eyal Rozenberg 2023-10-19 09:15:05 UTC
Bug still manifests with:

Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-IL (en_IL); UI: en-US