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+