LibreOffice Writer is messing up my styles. How to fix this?

English
,
#1

Hi,

Since yesterday in a file I’m working on everytime LibreOffice is messing up a custom Style everwhere it’s used. This is getting pretty frustrating. I already updated LibreOffice to the now latest stable version, but that didn’t help either.

When this happens the only thing to restore the original state of the file seems to be to copy all (Ctrl+A) and paste it into a new file which uses the same custom styles.
But than again after a while of working in it (or opening it again in LibreOffice later) also that file has that particular style messed up again.

This is getting pretty frustrating.

Anybody here who could please help me by telling me what’s going on here and why LibreOffice is messing with my styles?
(I’m no noob and I work with LibreOffice for years now, this is the first time this is happening)

Using LibreOffice 7.6.5.2 on Win 10 pro.

#2

In which format is your file saved?

Which style is “messed up”? A *paragraph style? A character style? A page style?

Do you practice direct formatting simultaneously? Remember that direct formatting always has precedence over styles and this hides style formatting. Sometimes, unintentional direct formatting is hard to detect.

For best advice, attach a sample file.

#3

I tried making a test file for you, but when opening it it’s messed up again. So that doesn’t really help.
I think you call these styles ‘paragraph styles’.
The file format it’s saved on is Word 2007 (docx).

I don’t know what you mean with direct formatting. I use keyboard shortcuts to apply styles to paragraphs, like ctrl+1 for header 1, ctrl+2 for header 2.

The issue seems to be that styles show right until I re-open the file, than the first header style is still fine, but the second one (at least) is messed up/changed, both in the styles panel, as well as throughout the document everywhere it’s used.


[edit] I see now that when saving to .odt instead, the issue does NOT appear when re-opening the file. So it must be Word 2007 fileformat related. But I need to save to word format and I’m pretty sure I always used that word file version to save to and wouldn’t know why the 2007 format shouldn’t save these styles.


[edit 2] Just tried the Word 2010-365 export format and that has the same issue. And that must be the most up to date word version to use.

#4

Word and Writer have different founding principles. Styles are much more developed in Writer (Word knows only of paragraph styles and in a rather “simpler” form). Consequently, conversion to DOCX on save loses some information. This is made worse by the reverse conversion to ODF on open.

Since your test file is already messed up, attach it and describe as accurately as possible what’s messed up (what you intended and what you got).

I bet you also use keyboard shortcuts for bold or italics instead of using character styles.

#6

The “chapter numbering” hierarchy is all messed up. Heading 1-2 are detached from the built-in engine. I suppose this is a consequence of the cumulative effects of the open-save conversion cycles.

But there is one unexpected mishap: fill colour for Heading 2 is explicitly defined in the style but is not carried over after DOCX conversion. Heading 2 inherits Heading 1 fill colour.

This is strange. File a bug report so that developers can look at it (attach your saple file). Mention this post in the report. Add a comment with the report number in the form tdf#<bug_number>, e.g. tdf#12345.

As a general rule, always work in .odt and convert to DOCX only before sending to a recipient claiming not being able to open .odt (M$ Word can open .odt, even if M$ took liberties with the format).

#7

Sorry, but this is NOT a result of open-save conversion cycles.
The file I sent here never went to word format. It’s simply the default custom template with the styles used to create a brand new document where I only wrote these lines of text and applied these styles on them. After that I only saved it to odt. never to word.

Also I don’t use the word format to supply files to clients, I never have to send word files to clients. I need the word format because on my main system I do use Word and I need the word format, because in LibreOffice it’s still not possible to use soft shadows around images. The shadow that LibreOffice uses is super ugly and simply unusable. If LibreOffice will have a good looking soft shadow around images I’ll move to LibreOffice completely directly, but it doesn’t seem to even be in their future plans as it’s lacking for years now.

Switching over to do everything to odt, including in Word itself, is not an option, because I have a few thousand files in use and I don’t want to convert all these. And rather keep using the docx format.
Which, again, always worked fine with the exact same software (the same libre office and the same custom template), until yesterday.

The only thing I could think of that could’ve messed this up is when libreoffice is using some windows- or microsoft-provided thing to make the conversion from its format to or from word format. SOmething that is updated by the windows updates and is not prorietory to/built into libreoffice. That’s the only thing I could think of right now.

I also don’t know what you mean with ’ heading 1-2 are detached from the built-in engine’. I’m in no way an expert on LibreOffice, but looking to it with a developer-view I would think it’s still using the exact same style references, only the styles are messed up. Because when I copy the contents and paste it into a new file, which is using the exact same custom template as base, everything looks fine again. Meaning that the styles are used from the template, otherwise they should look as bad I would think.

Thanks for trying to help. I’ll file a bug.

BTW Why are comments losing their format (paragraphs etc.) on this forum. They look alright in the preview. What’s the point of having a preview if it looks different on output?! Weird

#8

Bug issue is here:
tdf#160201

#9

Now that you hint at using a template, can you send Wigglepixel? The problem may be there.

You played with Tools>Chapter Numbering (this may be a long time ago) and you removed Heading 1-4 from the configuration. Then they no longer participate in automatic heading recognition nor in automatic chapter numbering. To compensate, you “attached” manually your new Heading 1-3 to outline levels 1-3.

What I can’t explain is why Heading 5-10 are also eliminated once the file is converted to DOCX. I can’t explain either why fill colour (set in the Area tab of Heading 2) is wiped out during the conversion.

This is apparently a bug in the Discourse engine (not under LO responsibility). It behaves differently in Answers and Comments. It perhaps considers comments are strict HTML data where white space is made of spaces, tables and line breaks. In HTML, all white space is condensed to a single “space”. Therefore multiple line breaks end up as a single end-of-line.

Since I noticed that comments are simply HTML (with some shortcuts called “MarkDown”, I add <br> at head of my paragraphs to force a blank line between them.

#10

I made a mistake by trusting LibreOffice to not include my user data in the file, but guess that was wrong. Could you please remove your post too, I don’t like my user data to be available publicly online, no matter how insignificant.
Thank you

#11

Your user data as defined by Tools>Options>LibreOffice>User Data is not stored in any file. It is stored in your user profile, on your computer. Your user data leaks to the document only when you insert fields referencing it, which is not the case in your test file. It is perfectly safe.

Which one? I re-read them but didn’t find anywhere something looking like private data.


I remind you that I’m waiting for your Wigglepixel template. Also, your test file is imperatively needed in the bug report for developers. It is also likely that the template is necessary since your test file is based on it.

If you prefer you can privately mail me your template but be aware that the bug report may need it for complete analysis.

#12

Which one?

Both your last two posts.

If not I see no other choice than to file a complaint to the libreoffice website hoster, because it’s not offering me any way to remove this thread, while I am not offered the option to delete my own thread, even though this is mandatory under EU law.

I count on you for removing your posts here and the file from your system though and stop posting new posts in this thread.
Thanks again

#13

This is my very last contribution if you are not cooperative.

I found something weird in your Heading 1 and Heading 2 styles. Going to the Area tab, both None and Color buttons are highlighted in Heading 2, hinting that two contradictory (conflicting) attributes are active simultaneously.

I looked at the XML which confirmed my suspicion.

Heading 1 has both a background colour and something tagged as an extension to define a “fill colour” (I don’t know what it is).

In Heading 2, you only change this fill colour to white but don’t define background colour which is then inherited from Heading 1 (and is the same as the font colour).

The question is now: how did you create these “extensions” which seem to be related to drawing objects? How did you do that in your template? The template is faulty, but only you can describe which steps you followed to configure your styles as such (I know of no UI to set these “extended” attributes and I don’t even know their purpose).

Your test file is deleted on my computer (as usual because I don’t want to pollute it with useless – for me – files). Either you provide your template with full step-by-step procedure you followed and some fix can be found, or you live with your own errors and you close your bug report wwith “USER ERROR” status.

#14

I note that you deliberately ignore the content of my last post, you continue to post while I clearly asked you not to and you clearly intentially refused to delete your posts, which I have now expressly requested you to do several times.

#17

Can you accept that I am no LO official and can be busy by myself? You really arouse me with your unjustified rant. I was ready to remove my posts after finding some free time but noticing your rude injunction, I am no longer willing to proceed unless you demonstrate where I infringe your privacy. Prove with irrefutable arguments that I did so.

Yourself must be aware that posting anything here is made public. This is a voluntary decision of yours. AFAICT, there is no private data anywhere here (unless you demonstrate the contrary).

#18

If you include a sample file, either here (again) or in the issue tracker, the problem may be sensibly addressed. Without that, there is no way to reliably determine the cause of your issue.

Your user data are part of the file properties. You can remove them:

  • Open your file
  • Select menu item File - Properties
  • Select tab General
  • Untick the option to Apply user data
  • Click the button Reset Properties
  • Save your file

Your file can now safely be uploaded, no longer containing your personal information as hidden properties.

If your issue is with your user profile in this place and you simply want to “begone”, I guess you are venturing the correct path. In that case I apologize for misunderstanding your objective.

#19

@keme1: I think that user data is only stored in user progfile. The Apply user data only associates user profile with some “insertions” like track changes or fields. And even this only takes the “current” user data, i.e. if a file is sent to a recipient, recipient’s user data will be used to tag new modifications.

I can no longer check OP’s file because it has long been deleted as it didn’t address the problem.

Regarding the Reset button, its effective action is to reset the state of the tab to what it was when the dialog was opened, cancelling all modifications made. This is contradictory with changing settings.

#20

Remember that the user data may also be kept in one or more locations in meta.xml.

1 Like

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