Bug 137677 - FILEOPEN DOCX Change tracked paragraph deletion with style change split to two changes
Summary: FILEOPEN DOCX Change tracked paragraph deletion with style change split to tw...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: DOCX-Track-Changes
  Show dependency treegraph
 
Reported: 2020-10-22 12:28 UTC by NISZ LibreOffice Team
Modified: 2024-08-10 19:02 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file from Word (13.93 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-10-22 12:28 UTC, NISZ LibreOffice Team
Details
Screenshot of the original document side by side in Word and Writer (96.10 KB, image/png)
2020-10-22 12:28 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NISZ LibreOffice Team 2020-10-22 12:28:33 UTC
Created attachment 166624 [details]
Example file from Word

Attached file was made in Word by completely deleting a paragraph that had a different stlye than the previous/next paragraph. This appears in Word as two CT entries in the sidebar.
When opened in Writer the deletion is split in two by the style change, so there are three entries in the Manage Changes dialog.

Steps to reproduce:
    1. Open attached file in Writer
    2. Open Edit – Change tracking - Manage

Actual results:
Two deletions and one style change is listed.

Expected results:
One deletion and one style change should be listed.

LibreOffice details:
Version: 7.1.0.0.alpha0+ (x64)
Build ID: e0c72e31c1d455c26110c35e8780d420e17cdea6
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: en-US (hu_HU); UI: en-US
Calc: CL

Also in:
Version: 6.0.0.3
Build ID: 64a0f66915f38c6217de274f0aa8e15618924765
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: en-US (hu_HU); Calc: CL

Version: 5.0.0.5
Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b
Locale: hu-HU (hu_HU)

Version: 4.3.0.4
Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0

In 4.2 only a deletion was shown and no style change.
Comment 1 NISZ LibreOffice Team 2020-10-22 12:28:49 UTC
Created attachment 166625 [details]
Screenshot of the original document side by side in Word and Writer
Comment 2 neuffbn 2020-11-06 22:42:16 UTC
Got the bug to reproduce in:
Version: 7.0.3.1 (x64)
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

Also in:
Version: 7.1.0.0.alpha1+ (x64)
Build ID: ccad985c5163224d669e9f0fa70fdff070fc58ca
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 3 Aron Budea 2022-10-27 04:30:14 UTC
This actually seems like a regression, or at least something was different before 4.3, as it was still only imported as a single change. Might be interesting to know what changed.

Bibisecting using bibisect-43max gave me 236c0762c14cace93deae4175073519ef67e4b48 / 05fa566b17902f76343952fb8355d576208fd097 (single commit in the bibisect repo), which are obviously wrong, though:

https://cgit.freedesktop.org/libreoffice/core/log/?id=236c0762c14cace93deae4175073519ef67e4b48
Comment 4 Buovjaga 2024-08-10 19:02:45 UTC
(In reply to Aron Budea from comment #3)
> This actually seems like a regression, or at least something was different
> before 4.3, as it was still only imported as a single change. Might be
> interesting to know what changed.
> 
> Bibisecting using bibisect-43max gave me
> 236c0762c14cace93deae4175073519ef67e4b48 /
> 05fa566b17902f76343952fb8355d576208fd097 (single commit in the bibisect
> repo), which are obviously wrong, though:
> 
> https://cgit.freedesktop.org/libreoffice/core/log/
> ?id=236c0762c14cace93deae4175073519ef67e4b48

Indeed, Linux gives that bogus result, but fortunately Windows 4.3 has better luck.

commit 69a199338a9996127f2d1fd24cb5fca89620d6a3
Author: TDF builder <tdf@tb83-bytemark.local>
Date:   Fri Dec 14 11:46:02 2018 +0000

    source 7a6ca9e81c71786b267fde8328c84bb10966c27c

    source 7a6ca9e81c71786b267fde8328c84bb10966c27c
    source 5116cd97a9dc90b2402f7e1d0c6922eedacd37ea
    source 0136616a5a005cc2237f020d46718bdb78f33c2b
    source e52f14efaa53b496599b51fb064a933183731fca
    source 0351b59aea2b87c2685c0963a57145bdc75a7a86
    source 53a3a31cf14ac35345c58553bc259130e1e70711
    source ae22d6388827958cfd89cd702b8c3c41ff9821e5
    source 1327020b6723ef988fe4e8399a87ce70e21419d7
    source c3353da0f0f3b09ae6d0dd0be734a0f889629f0c
    source ae7f8bed4bc4d7490a158c14d077c5323bd50466

Out of those, we have these interesting ones, with the import probably being relevant:

commit e52f14efaa53b496599b51fb064a933183731fca
Author: Adam Co <rattles2013@gmail.com>
Date:   Sun Dec 8 17:14:14 2013 +0200

    Export redline 'paragraph formatting changes' back to DOCX
    
    This patch adds support for the export of any redline of type
    'paragraph formatting changes' properties that were imported from
    a DOCX file under the 'pPrChange'->'pPr' XML node.

commit ae7f8bed4bc4d7490a158c14d077c5323bd50466
Author: Adam Co <rattles2013@gmail.com>
Date:   Sun Dec 8 16:56:21 2013 +0200

    DOCX Import of 'paragraph formatting track changes'
    
    This patch adds support for the import of 'paragraph formatting
    track changes' in the DOCX filter.
    It detects the 'pPrChange'->'pPr' node and stores all the properties
    that it processes in the redline object.