Format of document changed after update to LibreOffice 7.6.4.1

JeffWongVR · January 30, 2024, 11:09am

header-jump-in-writer.docx (23.2 KB)
After an update from 7.3.4 to 7.6.4, we noticed that this document became scrambled if opened in LibreOffice Writer.
Opening in MS Word shows the correct output.

I can’t find back in the release notes if this is fixable through settings.
We have too many of these type of documents and we rather not alter the content if possible.

Have you guys got any ideas or insights?
I have also added the document here.

RobertG · January 30, 2024, 11:19am

Have had a look. This buggy behavior appears first in LO 7.6. With LO 7.5.5 I could see the content of the frame positioned in another way so the whole text content is positioned as you could see in Word.

Positioning is totally wrong since LO 7.6, also page style is set in another way (to default instead of “First Page”).

ajlittoz · January 30, 2024, 11:42am

Could you define precisely what the “buggy behaviour” is?

A few “instant” first-look remarks:

your document is saved DOCX and you try to edit it with Writer for which DOCX is an alien format
Consequently, the document needs conversion with approximations for concepts not present in the internal format. This causes “glitches” and formatting loss.
your document has an overly complex structure
You have nested tables inside frames. Just inserting the tables would have been enough. By using frames, you create problems with the anchor. From experience, you can easily move the anchor point if you play with the mouse over the frame.
there is too much direct formatting
You vertically space with empty paragraphs. All your document uses erroneously Default Paragraph Style overloaded with direct formatting, except in the “description table” where this is Header (which should only be used for headers repeated on every page).
In addition, all text “decorations” (italic, bold, font size changes, …) are done with direct formatting but this is inherent to DOCX because it has no style concept for that.
Also, your original document contains numbered lists and format conversion was compelled to create various list and character styles to cope with differences between Word and Writer. This will complicate your life if you want to change format/layout of your lists.

Waiting for additional information before proposing an advice. The only reliable recommendation would be to use true and neat ODF (starting from scratch to avoid “polluting” documents with Word idiosyncrasies remnants) if you have no external constraint.

JeffWongVR · January 30, 2024, 12:16pm

@ajlittoz The buggy behaviour would be that the table within the header goes over the document. In the screenshot of the post, left is the expected and version 7.3.4 display and the right is the buggy view (7.6.4)
Unfortunately our users deliver the documents and they use MS Word, and we use LibreOffice as a PDF conversion engine.
The result of the PDF will always be the same as how LibreOffice Writer views the document, which would be a bug for our users.
This leaves me with little to no control over the content. At the moment, I am looking into the options within LO for view settings and through the registrymodifications.xcu.

@RobertG That is good to know that the latest version which the correct format is 7.5.5. I will re-read the release notes from that version.

ajlittoz · January 30, 2024, 2:08pm

The problem comes from the superfluous nesting of the table inside a frame. I have no Word here to look what the primitive structure is under Word. If the nesting comes from the conversion DOCX → ODF, then nothing can be done.

Using a frame allows to “detach” the effective position of the object contained in the frame from the anchor point. Said it otherwise, the frame can be sent anywhere in the page and if wrap parameters or even positioning reference are badly chosen, the frame may end up being “invisible” to text and cause overlap and masking.

Educate your users not to use frames (or rather the corresponding feature in Word) unless absolutely necessary.

As an alternative, ask your users to deliver the documents both in DOCX and PDF. Translation to PDF by the original application is preferable because this spares an intermediate translation which can never be “exact”. In addition, this will also avoid potential font problems.

RobertG · January 30, 2024, 2:35pm

@ajlittoz : No, the problem comes from different interpretation of the original in LO. Have a look at this bug I submitted:
https://bugs.documentfoundation.org/show_bug.cgi?id=159453
PositionFrameDOCX.pdf (225.7 KB)
Attached document shows the difference in LO 7.5.5, LO 7.6.4 and LO 24.0.2

There are a lot of formatting problems in the original DOCX. But LO shouldn’t give in older versions a better result as in newer versions.