Bug 104827 - FILESAVE DOC: Justified Text with Section Breaks Incorrectly Exported
Summary: FILESAVE DOC: Justified Text with Section Breaks Incorrectly Exported
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:doc
Depends on:
Blocks: Section
  Show dependency treegraph
 
Reported: 2016-12-21 05:04 UTC by Luke
Modified: 2025-05-19 03:10 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Simple .doc file with justified text and section break (22.00 KB, application/msword)
2016-12-21 05:04 UTC, Luke
Details
Some file round-tripped missing carriage return. Looks wrong in Word (9.50 KB, application/msword)
2016-12-21 05:05 UTC, Luke
Details
Screenshot showing missing paragraph mark and poorly formatted text in Word. (108.25 KB, image/png)
2016-12-21 05:10 UTC, Luke
Details
104827_patch.diff: works for this document only patch (2.38 KB, patch)
2021-07-01 12:17 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2016-12-21 05:04:10 UTC
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.
Comment 1 Luke 2016-12-21 05:05:00 UTC
Created attachment 129834 [details]
Some file round-tripped missing carriage return. Looks wrong in Word
Comment 2 Luke 2016-12-21 05:10:04 UTC
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?
Comment 3 Xisco Faulí 2016-12-21 09:41:50 UTC
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
Comment 4 Justin L 2016-12-21 14:07:39 UTC Comment hidden (obsolete)
Comment 5 Caolán McNamara 2016-12-21 15:10:58 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2017-12-22 03:35:42 UTC Comment hidden (obsolete)
Comment 7 Luke 2017-12-27 04:58:55 UTC
Still reproducible with Version: 6.1.0.0.alpha0+ (x64)
Build ID: bf8e8cf11bc0d60ab80f5b3420dc424aec2fa626

by roundtripping attachment 129833 [details] and opening in Word.
Comment 8 QA Administrators 2018-12-28 03:45:58 UTC Comment hidden (obsolete)
Comment 9 Luke 2019-01-01 00:32:09 UTC
Still Repro in Version: 6.3.0.0.alpha0+ (x64)
Build ID: 082144fa0fb2021cfb41494bb6eb5bf417e58ab1
Comment 10 Justin L 2020-11-10 15:01:21 UTC
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.
Comment 11 Justin L 2021-07-01 12:17:32 UTC
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.
Comment 12 Justin L 2023-05-19 14:57:02 UTC
repro 7.6+
Comment 13 QA Administrators 2025-05-19 03:10:28 UTC
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