"Save As" .docx adds page-break to a style where it shouldn't do so

English
#1

LibreOffice’s export to .epub doesn’t work at all well. So, instead, I export to .docx and then use Calibre to convert that to .epub.

The conversion works well, apart from one oddity: When I export my .odt to .docx, LibreOffice adds a page-break to one of my styles. This results in a large number of pages that are quite empty, as there shouldn’t be a page-break to that style.

This obviously carries over into the .epub, which is a problem.

It’s only the one style where this happens, which makes me think that I’ve done something wrong, but I simply cannot figure out what it might be! I would appreciate help with this, please.

I’ve attached a sample document extracted from my original (with data redacted): The original .odt and the saved .docx.
Sample.odt (47.8 KB)
Sample.docx (10.4 KB)

The style where this problem happens is called Section 3. There is no page-break defined in the style, nor have I manually added a page-break. It is correctly rendered in .odt and when I export as PDF. But, when I save as .docx, it adds a page-break before every Section 3 style.

What can I do to fix this, please?

System details

Version: 7.5.4.2 (X86_64) / LibreOffice Community
Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6
CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Flatpak
Calc: threaded

Running on Linux Ubuntu 22.04

#2

As far as I know, Calibre can handle odt files.

#3

You are correct, but it messes up some of the formatting. As counterintuitive as it seems, I haven’t yet found a more reliable way than saving as .docx and then converting to .epub with Calibre. (There might be better software than Calibre, but I’m not aware of any that would run on Linux.)

#4

I can’t guess what’s causing this mishap.

At first I suspected your overline in Font Effects because this overline is not forwarded to .docx. But removing it does not change the issue.

I wondered if .docx could be upset with your custom outline structure and removed Section 3 from outline to no avail.

I even looked at the .fodt but didn’t see anything unusual.

A remark for your information: When you want a "global" overline above your paragraph, don't use FontEffects overline. Your text may contain various character styles, among those changes in font face, size or variant like Roman/italic. FontEffects overline is linked to font metrics and the overline may then not be positioned at the same height, resulting in an ugly look. Think of such an attribute as a separator. Consequently define it as a partial **border**. In addition you control precisely the distance between this border and text.
#5

Yes, I’d also tried that.

But…

Your comments led me to the solution! Section 1 has a page-break. In the Organiser, Section 3 inherits from Section 1. When I changed the “inherit from” to “None”, this solved the problem!

So, thank you for the guidance.

Thanks for your advice. The only other place where I know to add a border to a paragraph style is in the Borders tab. But that creates a border all the way across the page; I don’t know how to create a partial border. Changing the right-padding doesn’t adjust that.

Unless you mean adding an overline to the Character style rather than the Paragraph? But then I wouldn’t know how to apply that to the paragraph style.

The alternative, for me, would be to do away with that overline altogether.

#6

Please select your own answer/comment then as solution, so this thread is shown as solved.

1 Like
#7

I think there is something else: indeed you have a page break in Section 1, but you remove it by an override in Section 3. As you can see in your .odt, this works fine as intended. Therefore, I don’t fiddle with it.

If removing the inheritance solves the issue, something is wrong in .docx out filter. You should submit a bug so that we can have the opinion of developers. Give all details of your investigation, notably the fact that removing the inheritance solved the problem. This clearly shows that ODF formatting is not correctly translated.

1 Like
#8

Unfortunately, I have to fiddle with it in order to make the resulting .docx work.

I started to create a bug report, but I found that I cannot duplicate this with a new document. This happens only in my original document (or copies of it).

So, it must be something in my document that is a relic from when it was first created, somewhere around 14–15 years ago.

If there’s a way to “clean” an old document of accumulated garbage, it might be worth trying that as an experiment. Do you know if such a process exists?

#9

I had the same problem and did not find a smart way to do it. The worst and most efficient is to paste text as unformatted in a new document and to re-build the style collection. Unfortunately, there is no way to print the style dictionary like Word could do it 30 years ago (I stopped using Word when I retired 15 years ago and don’t know if the feature still exists – I had no use for it professionally, so didn’t test at that time). If you have 2 computers, have one open on your old document and the other one on the new. Don’t try to do it with a single computer. When one instance is open on a dialog, this blocks your navigation among dialogs in the other instance (style editors are dialogs). I think it is a limitation in the OSes.

#10

There is an easier way, I hope. You can create a brand new document, then copy across all the styles: Styles > Load Styles from Template > From File > select the original file.

After that, copy and paste all the text from the original file to your empty document (keep the formatting).

You would still have to do some manual processes, such as ensuring that the page styles are correctly applied, and copying across certain items, such as from File > Properties and custom-defined Fields (I have a few of those).

Whether that will clean up any mess or merely copy the mess across, I don’t know, so I haven’t bothered to try!

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.