Description: Text moving is only recognized in simple cases, but not when the moved text was modified later. Steps to Reproduce: 1. Open the attached file. 2. See that the string is displayed at both the original position, as well as the new position. Actual Results: The change is not visible. Expected Results: Should be the change visible with green after the move. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community Build ID: a0a38b88dc3a61d212d784f41a27f97d9c2d7f32 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: default; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: threaded
Created attachment 176286 [details] Example file from Word with DOCX import: support MoveTo/MoveFrom completely
Created attachment 176287 [details] Screenshot of the original document side by side in Writer DOCX import: support MoveTo/MoveFrom completely
Green color and double strikethrough or underline show already simple text moving, see tdf#145233. Note: The attached test file is duplication of the second test document of tdf#104797.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f51fa7534421a195a58b4a737a2e836d8c25ba81 tdf#145718 sw, DOCX import: complete tracked text moving It will be available in 7.3.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.
tdf#145718 sw, DOCX import: complete tracked text moving Add IsMoved bit to SwRangeRedline, and keep it in both parts of a split Delete/Insert redline. Set this bit during DOCX import, fixing incomplete import of moveFrom/moveTo elements. Details: - Search text moving only at redline Insert() and AppendRedline() instead in the layout code (which was much slower, because triggered by also mouse hovering): - detect text moving in Hide Changes mode, too; - Insertion inside or directly after tracked text moving keeps "moved text" layout of the original moved text parts (before and after the insertion). - at detection of text moving, invalidate (update) layout of the redline pair, too. - fix DOCX import: extend makeRedline() with property RedlineMoved to keep all moveFrom/moveTo stored in DOCX instead of losing them (joining them with normal redlines) in the case of missing Delete/Insert pair (see unit test document); Follow-up to commit ec577f566fa3e6d2666069180f8ec8474054aea9 "tdf#145233 sw track changes: show moved text in green color", commit bcdebc832b272662d28035007a4796e42d1305ae "tdf#104797 DOCX change tracking: handle moveFrom and moveTo" and commit d32d9a2b3c5e3963f4a18f6c7bbf50fab2e9b2be "tdf#123460 DOCX track changes: moveFrom completely".
Verified in: Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 3a61cce54277fd12570103a191c50d9b37ef3dd3 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: CL
Bug reproduced in: Version: 7.0.6.2 Build ID: 00(Build:2) CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Ubuntu package version: 1:7.0.6-0ubuntu0.18.04.1_lo1 Calc: threaded And verified as fixed (showing green highlight, cut and paste actions in Manage Changes) in: Version: 7.3.0.1 / LibreOffice Community Build ID: 840fe2f57ae5ad80d62bfa6e25550cb10ddabd1d CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded