LOffice 3.3.2 Tracked Changes (Load/Save set to ODF 1.2) damages some tracked deletions after the document is saved, leading to incorrect change-tracking if there is further editing/authoring and saving. The case arises when there are additional end tags added past the deletion point in order to balance the elements that are truncated (ending chopped off) before the deletion point. The deletion tracking and the in-text markup are initially correct. However, the showing of changes in the presentation is subsequently altered. The alteration fails to properly show the original text in context and the <text:deletion> element is altered. It appears that the problem arises in the consumer not properly recognizing that some end-tags beyond the deletion seam are synthetic and were not part of the pre-deletion document. This came up in a forensic analysis of tracked-change deletions on the ODF TC and there is a blow-by-blow analysis on the ODF TC site. The demonstration document and a PDF of it are available to the public. See http://lists.oasis-open.org/archives/office/201104/msg00008.html http://lists.oasis-open.org/archives/office/201104/msg00009.html Although this involves a moderately-intricate deletion case, it is easy to stumble on. The severity is because after the corruption, the change will be shown incorrectly and, more to the point, any rejection of the change will fail to restore the undeleted text correctly.
I should point out that this can be more serious if the saved document is saved, the signature is confirmed, but the OpenDocument Consumer presents the change-tracked deletion incorrectly.
(In reply to comment #1) > I should point out that this can be more serious if the saved document is > saved, the signature is confirmed, but the OpenDocument Consumer presents the > change-tracked deletion incorrectly. I should have said, "if the saved document is signed, the signature is confirmed, but the OpenDocument Consumer presents the change-tracked deletion incorrectly."
This bug is similar to the one in LibO 3.4.0rc2 where deleted text is turned into deleted spaces. That one is worse. The two bugs seem to be related in the sense that the deletion is recognized correctly, but as soon as anything happens, the deletion is replaced by the incorrect one.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Please, verify: in 3.5.0 problem still exist?
I redid the deletion example that crossed between a list and a paragraph following the last list element, and the change-tracking was visibly correct after saving and reloading the document in LibO 3.5.0 on Windows Vista (32-bit). When I rejected the change, the original text was properly restored. Based on that test, the defect does not appear in 3.5.0.
Thanks for additional testing