Created attachment 185293 [details] The formatting change. On both my home (Linux) and work (Windows) computer, adding a comment to a document causes virtually all numbering, new lines, and spacing rules to reset in the lines afterwards. The same bug is present in files saved in an older version of LibreOffice or Microsoft Word. The documents look completely normal in Word, however.
What do you mean by afterward? In the current state of my understanding, I cannot reproduce the bug on my computer. Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: CL threaded
(In reply to Sophie Sipasseuth from comment #1) > What do you mean by afterward? > > In the current state of my understanding, I cannot reproduce the bug on my > computer. > > Version: 7.5.0.3 (X86_64) / LibreOffice Community > Build ID: c21113d003cd3efa8c53188764377a8272d9d6de > CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: > win > Locale: fr-FR (fr_FR); UI: fr-FR > Calc: CL threaded I mean any text below the comment. So to reproduce the bug, create a few lines of text with newlines, as if you were writing a numbered list. Add a comment to one of the text bodies in the middle; then save, close, and reopen Writer. You won't see any newlines or numbers below that comment.
Update: Rendering is correct when the file is saved as ODT. Just not DOCX.
No repro with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b052ec2f2fbe0f3044ba824c064a280a5ee9cd7f CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Can you prepare test file without comments? Then I should insert comment, save, and see loosing the numbering.
Created attachment 185318 [details] File with no comment Here is an outline that I regularly use and add comments to for work.
Created attachment 185319 [details] Same file with a comment Here is the same file with a comment. You should see the bug in Writer 7.5, but not Microsoft Word.
[Automated Action] NeedInfo-To-Unconfirmed
confirm with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 14844d835cc5d6dfde499a0b1074aea5dcff4fc7 CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded works in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
This seems to have begun at the below commit. Adding Cc: to Justin Luth ; Could you possibly take a look at this one? Thanks 35908e41a2428fe1c4130c34ae4062c3f0705215 is the first bad commit commit 35908e41a2428fe1c4130c34ae4062c3f0705215 Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Jul 11 22:14:26 2022 +0200 source cf02b94bc513ee1b742b4c5d7174632b568e8b72 https://git.libreoffice.org/core/+/cf02b94bc513ee1b742b4c5d7174632b568e8b72
OK - this is absolutely bizarre. When we have a ParaStyleName property assigned to a comment, it raises an exception. But if I remove the property, then we get this problem. It will be interesting trying to find the root of all this... So, the problem in my commit comes from avoiding inserting an illegal property into the top context in the case of IsInComments in lcl_startParagraphGroup. So what? Things don't work unless an exception handler is run?
I see. The original exception prevented m_xPreviousParagraph from being changed. Now we run into another exception trying to read NumberingRules from an editeng component which gives an exception because there is no mpEditSource->GetTextForwarder(), even though it does report hasPropertyByName.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dbbfcb7e098c1c16f932785ef62ef7d3d819ad1a tdf#153526 writerfilter: catch exception from no NumberingRules It will be available in 7.6.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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/bf9e8ce3a810e2989fb0b486b3398d523f69da97 tdf#153526 writerfilter: catch exception from no NumberingRules It will be available in 7.5.2. 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.
Formatting inconsistencies and disruptions like numbering, new lines, and spacing rules being reset can occur when documents https://bitlifeonline.com/ are shared or opened across different word processing software. Each software may interpret and handle formatting rules differently, leading to discrepancies in how the document appears.