Created attachment 129833 [details] Simple .doc file with justified text and section break The MS-DOC standard has a quirk where if you end a justified paragraph with a section break and no carriage return, the last line will be justified. (Normally last line is left aligned). For some reason, just before a section break (page or continuous), our exporter throws away the final return. As a result, justified .doc files with section breaks get damaged on round-trip when opened in MS Office.
Created attachment 129834 [details] Some file round-tripped missing carriage return. Looks wrong in Word
Created attachment 129835 [details] Screenshot showing missing paragraph mark and poorly formatted text in Word. Justin L, Is this export issue something you'd be interested in?
Confirmed in Version: 5.4.0.0.alpha0+ Build ID: 5a20df55ff829978c880b22e0a1f32c35d0ba30f CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); Calc: group
This comes from calling ww8atr.cxx:ReplaceCr(0xc) in wrtww8.cxx:WriteText(). The relevant parts of ReplaceCr were most recently (2002-04-04) written by Caolán McNamara. https://cgit.freedesktop.org/libreoffice/core/commit/?id=b88924a09b3932535afb177e8944fb354aacfa81 I'm not sure why ReplaceCr is used instead of just WriteChar(0xc). It is not super-trivial to find the ?HoriOrient? position of the latest paragraph, so it isn't simple to wrap that in an if clause. The comments here are mostly in German. CC'd Caolán McNamara
14 years ago is a bit of a stretch to cc me on it :-), I don't have any special insights at this distance in time
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still reproducible with Version: 6.1.0.0.alpha0+ (x64) Build ID: bf8e8cf11bc0d60ab80f5b3420dc424aec2fa626 by roundtripping attachment 129833 [details] and opening in Word.
Still Repro in Version: 6.3.0.0.alpha0+ (x64) Build ID: 082144fa0fb2021cfb41494bb6eb5bf417e58ab1
Still repro in 7.1+ The comments are no longer in German - so that might help some of us. Either my previous testing was completely wrong (most likely), or something else has changed. WriteText is NOT directly calling ReplaceCr for this document, but is calling wrtw8nds.cxx's MSWordExportBase::OutputSectionNode which is then calling ReplaceCr (which is ONLY used by GetExport().GetExportFormat() == MSWordExportBase::DOC). Unfortunately, unit tests (like ww8export3's fdo53985.doc) show it isn't as simple as changing that ReplaceCr to a WriteChar.
Created attachment 173305 [details] 104827_patch.diff: works for this document only patch Here is a potential way to handle it, but it is a LOT of checking and tomfoolery to avoid showing a buggy behaviour in MS Word. It doesn't seem worth the effort and the likely bugs and extra scenarios that need to be considered to actually try to fix the bug.
repro 7.6+
Dear Luke, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/79a41e301209eb0f15af397e10ce2838965408d6 tdf#104827 doc export: Keep CR when justified text before section It will be available in 26.2.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.
This bug's example is about CONTINUOUS SECTIONS. With a continuous section, we do NOT want to introduce an empty paragraph. That might throw off layout. So I can't just call WriteCR. (Plus, that doesn't seem to work, since ReplaceCr has special code to ignore \n\n situations.) Instead, I just called WriteChar(msword::PageBreak) in this instance (as suggested by comment 10). Note that ::PageBreak seems to be a misnomer. It seems to refer to a normal PageBreak, a section page break, or a continuous section break.
Created attachment 202520 [details] 104827_justified text before section page break.doc: page break example I had trouble making an example document using a section page break. This one is hitting the ReplaceCr in PrepareNewPageDesc.
Since I've closed this one as fixed, and the fix for "page breaks" will involve completely different code, just ignore comment 16's document. If someone wants, they can file a new bug report with a real-life example.