Description: Attached document has a deleted paragraph before a numbered one, with change tracking turned on. When we hide the tracked changes, the paragraph after the numbered one loses the numbering. Turning on the display of changes shows the numbering again. Steps to Reproduce: 1. Open the attachment 2. Select Edit – Track Changes – Show to turn off showing tracked changes 3. The paragraph after the deleted one loses its numbering. 4. Select Edit – Track Changes – Show to turn on showing tracked changes 5. The paragraph after the deleted one gets back its numbering. Actual Results: The paragraph after the deleted one loses its numbering when changes are hidden. Expected Results: The paragraph after the deleted one should keep its numbering. Reproducible: Always User Profile Reset: No Additional Info: LibreOffice details: Verzió: 6.2.4.1 Build az.: 170a9c04e0ad25cd937fc7a913bb06bf8c75c11d CPU szálak: 4; OS: Windows 6.3; Felületmegjelenítés: GL; VCL: win; Területi beállítások: hu-HU (hu_HU); UI nyelve: hu-HU Calc: threaded Does not happen in: Verzió: 6.1.4.2 Build az.: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3 CPU szálak: 4; OS: Windows 6.3; Felületmegjelenítés: GL; Területi beállítások: hu-HU (hu_HU); Calc: CL Bibisect log: # bad: [3f78e45c6b5375dcb0c2b26256e2510214fc3670] source 26e85974a0287ab5869e7ff0145a66b853d66a02 # good: [ea94942caaf195b8d8b2d5c2abb523359ab390e7] source a20a2d7e0d28658f2d9089da076961a599833a28 git bisect start 'origin/master' 'oldest' # bad: [93c6fa4266bae1f9aace96b57312aa8f2b1cc327] source 4faafea4f24316e75b80e6ef97c1a4d39551a0b2 git bisect bad 93c6fa4266bae1f9aace96b57312aa8f2b1cc327 # good: [6a5b123c97b20147c918b7440fd92f7c92f1a63a] source 7bbc1fd443ff0b137206ad279eaed7bd4d5ec6ec git bisect good 6a5b123c97b20147c918b7440fd92f7c92f1a63a # bad: [724fa67b9129f003687a6de2f94514d0d43a27b1] source 6bbb384bf6334eb9f207f4098820e6852e21325a git bisect bad 724fa67b9129f003687a6de2f94514d0d43a27b1 # bad: [9cbb4f310d3b2be2061f76beeb0a1785aab84900] source dc10bd5326e4985816d74659ed7d8fded50fe11f git bisect bad 9cbb4f310d3b2be2061f76beeb0a1785aab84900 # good: [ae7423b3651a39299fcc21b6bf39d9bf44992fba] source c49ea4f3155dcb3538c81734e911eb2910570553 git bisect good ae7423b3651a39299fcc21b6bf39d9bf44992fba # bad: [e916e5c35c3a1e77512def762d8875bb74d4dccc] source 78073ecfdc50e78e3ce094c1259779b7c3b88bc4 git bisect bad e916e5c35c3a1e77512def762d8875bb74d4dccc # good: [780fc628350f2f69a2537dd28f4db2c4cbb384bd] source 8c708b6b1a7f0ee3ba97c0f2270b7f88f0495a15 git bisect good 780fc628350f2f69a2537dd28f4db2c4cbb384bd # bad: [023f512a0fb6a5516a0d143413b05e99e7bf5a3e] source eb29623cf0614030a61c02b06ccbf06199c4f94e git bisect bad 023f512a0fb6a5516a0d143413b05e99e7bf5a3e # good: [f1f5dadf47a54de2bc9af1f7c0f89fdab60e8b40] source 87514172c1924492c33a8aa261b082f0ae7f9b48 git bisect good f1f5dadf47a54de2bc9af1f7c0f89fdab60e8b40 # bad: [3c02556c08d543484149b14e3f4747644b79c5fe] source 32902f66e7749b2d06d13f50416be5323a0c0ea9 git bisect bad 3c02556c08d543484149b14e3f4747644b79c5fe # good: [54536eb7095a327d28ef8992e42351e92b278ea8] source 5bc7fb209c0e6d7c6a46499d8c2e4d7abaa87bd7 git bisect good 54536eb7095a327d28ef8992e42351e92b278ea8 # good: [e01f0e01d777b202952ab38be74dc92ba8808341] source b310378e874bc8fa7005352fcd85fa64eb075f54 git bisect good e01f0e01d777b202952ab38be74dc92ba8808341 # first bad commit: [3c02556c08d543484149b14e3f4747644b79c5fe] source 32902f66e7749b2d06d13f50416be5323a0c0ea9
Created attachment 151449 [details] Example file from Word
Created attachment 151450 [details] Screenshot of the original document side by side in Word and Writer with changes shown
Created attachment 151451 [details] Screenshot of the original document side by side in Word and Writer with changes hidden
in LO 6.0, the result is differently wrong: if you go Show->Hide the document looks different than Word because the last paragraph has no numbering, and then Hide->Show will not restore the last paragraph's numbering in LO 6.1, the result is differently wrong: if you go Show->Hide the document looks like in Word, but then Hide->Show will apply the last paragraph's numbering to the deleted paragraph, so it's also buggy so clearly what LO 6.2 does is different from Word, but neither 6.1 nor 6.0 did the same thing as Word; the advantage of 6.2 is that Show->Hide->Show doesn't change the numbering LO 6.2 looks better than it did in LO 6.0, which is the latest version that doesn't have any sw_redlinehide related changes
i think this is a bit of a corner case with an impedance mismatch. when you start a deletion in one paragraph, and end in the next one, both Word and Writer will take paragraph formatting from the *start* paragraph, if it remains non-empty after the deletion, but if it becomes empty, then Word will take from the *end* paragraph, while Writer still takes from the *start* this behavior was apparently introduced in OOo 3.2 with: commit 4439427aadeaa0cb611011b46f0fa14bfa196f33 CWS-TOOLING: integrate CWS sw32bf02 2009-08-20 12:37:32 +0200 od r275172 : #i100466# correction for showing and hiding redlines in fact i've already had something like Word's behavior implemented once, due to misreading some code :), but then reverted it at some point...
unfortunately the way how Word does it is to create a separate tracked change for the formatting properties of the last paragraph. this has some interesting implications: first create a tracked change to join 2 paragraphs without deleting the first one completely, then another deletion to delete the rest of the first one -> first one's formatting wins do it in one deletion -> second one's formatting wins Writer's formatting change tracking is not up to the task... ... uploaded some draft patch at https://gerrit.libreoffice.org/72425
Workaround to show the correct numbering in Hide Changes mode: https://gerrit.libreoffice.org/#/c/72784/
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/cbd894925e6b9869baedcd6476484c14d3a3df87%5E%21 tdf#125319 DOCX track changes: don't change numbering It will be available in 6.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.
@Michael: I close this issue based on my workaround, but we all are really interesting in a better solution here. The known problem of the workaround is reported in the Bug 125311. Thanks, László
looks like an okay workaround, except that this m_bFinalizeImport flag can be set not only in Word import filters, which could be a problem...
Verified in Version: 6.3.0.0.alpha1+ Build ID: 53325b40b557cc84d8d21c1baa0ef8d3bfc00ab8 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @László Németh, thanks for fixing this issue!!
The fix can't be backported unless https://gerrit.libreoffice.org/#/c/72001/ is backported. László's call to decide whether to backport it or not
(In reply to Xisco Faulí from comment #12) Xisco, Michael: I've made the requested clean-up for the backport: https://gerrit.libreoffice.org/#/c/73043/, I hope, with this, there won't be any obstacle to back port the fixes. Thanks for your help!
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/beec1594587d0bf1ea2268f9a435c948b5580278%5E%21 tdf#125319 sw_redlinehide: handle empty paragraphs more like Word It will be available in 6.4.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.