Bug 133356 - [FILESAVE] Saving as .docx changes pagestyles & can't round-trip
Summary: [FILESAVE] Saving as .docx changes pagestyles & can't round-trip
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.2.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-24 22:08 UTC by Luke Kendall
Modified: 2020-05-29 14:48 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Zip file with two short sample documents (7.24 MB, application/zip)
2020-05-24 22:08 UTC, Luke Kendall
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kendall 2020-05-24 22:08:34 UTC
Created attachment 161245 [details]
Zip file with two short sample documents

Please see the attached source document WTKDP-BadDocxGen.odt and the bad .docx file generated by Save As from:

Version: 6.4.3.2
Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: x11; 
Locale: en-GB (en_AU.UTF-8); UI-Language: en-US
Calc: threaded

This relates to a separate bug, 133334, now fixed I believe for 6.5.

The additional aspects seem to be separate bugs, so I'm filing this bug report.

I believe that because page styles are important, when Writer produces a .docx it should produce a file that when it reads it back in, should be basically the same.  Even if that requires some additional OOo-only XML attributes need to be written into the file that only Writer knows how to interpret, to preserve the information.

I also believe the page styles set should be preserved. I feel that if my document only uses four page styles, then the .docx should be laid out using those four styles, and when read back in to Writer, it should recreate those same four styles with the same dimensions and properties.

Instead, saving to .docx generates more page styles than are used, as well as making unexpected changes to the page layouts.

Some examples:
1) All my page sizes are set to the same dimension, 360 x 576 pts (for a 5"x8" book).
When converted, all converted page sizes are 360 x 575 pts.

2) Most pages are set with margins Inner, Outer, Top, Bottom: 66 36 24 21
   In the .docx these are mostly changed to: 66 36 0 0

3) Pages with footers in the original are set with Spacing 14.2pt and Height 14.2 pt, and dynamic spacing and autofit height off.
   In the converted .docx, these are changed to Spacing 21.1pt and Height 2.9 pt, and dynamic spacing and autofit height ON.

4) I have a no-header-or-footer style for the first page of a chapter.
   These pages generally convert across incorrectly and gain a header and footer.
   However, even the page styles that have no header or footer visible, appear in the Manage Styles with Header and Footer turned ON

I don't understand why the conversion doesn't embed enough information so that when writer's .docx is read back by Writer, the page styles are preserved - both the settings, and the names, and the number.

In my book, I have just 4 page styles defined and used. After saving to .docx and reopening, not only are all the page styles altered, but there are now 149 plus the default style.
Comment 1 Luke Kendall 2020-05-24 22:16:46 UTC
It might also be worth checking to see if Writer generates spurious empty column breaks when it creates a .docx, too?

I raise that just as a possibility based on my reading (quite likely, misunderstanding) of https://bugs.documentfoundation.org/show_bug.cgi?id=133334

I was puzzled by the mention of docx-defined column breaks in the analysis of the required bug fix, since I provided none in my source .odt file.
Comment 2 Telesto 2020-05-26 15:29:27 UTC
Again to many bugs in one report :-). Point 1-4 in a different report please.

And also a separate report about page style names not preserved. Calling every converted is probably wrong
Comment 3 Dieter 2020-05-29 14:15:23 UTC
(In reply to Telesto from comment #2)
> Again to many bugs in one report :-). Point 1-4 in a different report please.

I agree. So let's close this bug as RESOLVED INSUFFICIENTDATA, because it's not possible to handle several issues in parallel. Luke, I hope you can understand this and agree.
Comment 4 Luke Kendall 2020-05-29 14:48:17 UTC
No problem.

For now (since my deadline looms), I'll simply add this to my file of bugs to report after my deadline.

I'm happy to submit multiple bugs for this one hopefully next week.