Background color breaks when adding images

English
,
#1

Since the default white background hurts my eyes, I changed it to black (in Options > Application Colors > Document background). This works great.

However, I noticed that if I add an image into my file (like a book cover at the start or even a company logo) whenever I next open the file, the background has gone back to white. I looked in Options and it’s still set to black in there.

Switching to something else doesn’t work, it remains white.

I removed the image, saved the file, closed & reopened it, and it’s still white!

I also tried to save to ODT instead of DOC (my preferred format), but no change either.

I can’t figure out why it’s doing this or how to fix it.

Has anyone met with this issue before? I googled it, but couldn’t find anything relevant.

I’m attaching a sample, as requested:
test.doc (15 KB)

Any suggestions?

Thank you.

#2

I also tried to save to ODT instead of DOC (my preferred format), but no change either.

Do not expect that special formatting should work in a DOC file.

#3

Well it won’t carry over to another app, and that’s fine. But so long as I don’t add images and open the file in Libre, the background color has always remained. I’ve only had an issue with this when adding an image.

#4

My test:
I changed the background color in the page style “Default Page Style”.
There the problem does not occur with me.

80313 HB Test with black background.odt (339,0 KB)

With me:

Version: 7.3.5.2 (x64) / LibreOffice Community
Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL

Remark:

Starting with LibreOffice 7.4 there will be a dark mode for Windows.

https://wiki.documentfoundation.org/ReleaseNotes/7.4#GUI

#5

Please provide a 2-page sample file for testing. Attach a .doc file with an image though it is likely that the various configuration settings won’t persist.
Application colours in Options are used where formatting doesn’t force anything else (think of app colours as an ultimate background displayed when nothing else covers it).
Are you using a dark theme? (Not working for now)

#6

How did you do that? I looked in “Edit Style” but the closest thing I could find was setting a color under Area, but that only works within the margins, so that I still get a white border all around.

That said, I see two possible issues with this approach:

  1. wouldn’t it print black on the page? I only want the black on my screen, not on other people’s screens and much less on paper.

  2. I use multiple styles through my books, so applying this through the whole file feels like it would be a major pain.

#7

I don’t have a dark theme, no, Libre doesn’t have that yet in my version (7.0.1).

I’ve uploaded a sample file per your request and attached it to my OP.

#8

It is probably a consequence of format conversion on load and save, but I can’t explain it.

As far as I know, M$ Word has no page style concept. It uses the vague notion of section to approximately format page layout.

It appears that when you open your sample file, Default Page Style has a white background colour instead of None (see the Area tab fo Default Page Style). This page background colour takes precedence over document background defined in Tools>Options. Since page background extends from sheet edge to sheet edge, no “default” area remains. The document background which is a “deep background” is nowhere visible.

Set Default Page Style Area colour to None to fix the issue.

If the same behaviour occurs in your other page styles, then it is an artefact of format conversion. To make sure, I’d have liked a multi-page sample with several page styles.

If you’re the document author, it is much safer to work and save as .odt where all Writer features are guaranteed to work as specified. Convert to .doc or .docx only when requested by an external recipient and always keep your .odt as a reference.

#9

It’s more that I work in Word first, than move to Libre for the last touches. I suppose I could convert to ODT before I add the image, though, since I only do that in Libre. I just tested and that does preserve the background.

I’d like to find a solution for the existing file though as I still have work to do on it and seem stuck with the white background.

What I don’t get is that if the problem is with the DOC container, why does saving to ODT not let me fix it?

I tried your suggested trick of going into Edit Style > Area, but it’s already set to None in there on my end (even that sample I uploaded). I tried saving to ODT, closing the file, reopening it, and still it’s set to None. I also tried changing it to some random color (random color doesn’t show), saving, then setting it back to None. Still no joy :frowning:

This is frustrating.

#10

There is no patent remedy how to cure files that were created in Word as DOC(X) suddenly just because they were saved in LibreOffice as ODT.
Every conversion of files into another format takes place via so-called filters.
The more you convert DOC/ODT/DOC etc. back and forth, the more you will probably destroy.

Workaround
Open a DOC(X) in LibreOffice and save it immediately as ODT. You can now “fix” any discrepancies so that the document matches your expectations. Stay with ODT.

#11

I know there’s always loss in conversion, but so far it always affected the content itself. What surprises me here is that Document background is supposed to affect the way the file appears within Libre rather than the actual contents. It’s the first time I’ve had an issue like this, so it baffled me. Well, at least I know how to avoid it in the future, but it still feels odd to me.

#12

Yes sometimes practice teaches the behavior of programs and covertions.

1 Like
#13

@ajlittoz Here’s a multi-page sample. It has as many styles as it has pages (4). It’s basically my original fiile stripped down to 4 pages with all the text removed and saved here to ODT, though the issue remains, even with the image removed.

If you somehow manage to set a Document background to something else than white, I’ll owe you a meal or something lol.

sample2.odt (14.2 KB)

#14

I’d have preferred checking the .doc but I get the same syndrome here. All the Convert x page styles have a forced white area colour.

There are 107 Convert x page styles (your real document is therefore 107 or 108 pages long). This number shows that the document original structure is damaged beyond easy repair by the conversion process or iterations (iterations amplify the phenomenon).

In addition you don’t seem to style your paragraphs as they are all Default Paragraph Style. Without proper styling, you won’t be able to reformat easily.

Side question: what is Edit Style>Area? I have no such menu item, even with right-click. It is then possible that you don’t query the right style.

#15

@ajlittoz The original is actually 460 pages (it’s a novel). I’m not a huge fan of styles (and perhaps this is a mistake, but I’ve never really taken the time to look into them) and just format by using in-built Word 97 styles which I then motify as needed (for instance, I’ll click on “Heading 1” then center it for chapter titles–that’s where that extra dot got added, incidentally).

What I’ve noticed about those “Convert XX” styles though is that they are how Libre converts section breaks created in Word. I would have expected them to show as sections in Libre as well, but apparently not.

I can live with it, as long as it looks OK in the exported PDF (which it does). Only real issue I have is that background thing. Ah well. Guess I’ll have to put up with it (too late to backtrack with all the formatting I’ve already done) and do things differently next time.

Oh, and to answer your question, if you go in the Styles menu, toward the bottom, there’s “Edit Styles”. From there I go into “Area” and I see it set as None already. Am I doing this wrong?

#16

Definitely. In Writer the concept of styles is pushed far beyond. They are everywhere (paragraph, character, page, frame, list but not yet in table). They allow to fine-tune your formatting and layout in a very comfortable manner. When used appropriately (what I call “semantic styling”), you separate contents from appearance. This means you never need to reread your text to check that your formatting change is applied only to the expected element. Really nice.

Sections in Writer are fundamentally different from “sections” in Word. In the latter you simply break the page sequence to change page layout. A Word section does not necessarily imply a page break. In Writer, page layout, including header and footer contents, is changed by applying a page style. This page style takes effect between two explicit page breaks (the head one requesting the application of the style). Thus page style change implies a page break.
A Writer section is a temporary change of page geometry within a zone controlled by a page style. Only attributes within the printing area of the page style are affected. Header and footer don’t change. Usually a section is inserted to modify the number of columns for a few paragraphs. At the end of the section, you revert to the page style geometry.

OK, I never use it with my styling procedure. The problem is it applies to the current style at the cursor position. What you didn’t notice is it targets the current paragraph style, not the page style. And effectively, area for Default Paragraph Style in None.

1 Like
#17

Aaaaahh! I found it! I see it now. Under Format>Page Style. Awesome. That DOES work. Though only on the current style. Even selecting the entire document doesn’t work. So it looks like I’ll have to go through every section to change them individually. But at least it’s a solution :wink: Thank you so much! I owe you a meal LOL.

One thing I struggled with while formatting the book was re-setting all my headers and footers between sections. I’m sure there must be an easier way to do this using hierarchical styles. Sounds like I’ll be looking into this in the near future :wink:

Thanks again for the help!

#18

In Writer (not in Word), if your header and footer contents can be deduced from “notable” elements (like echoing chapter title, author name or book title), this can be done with Insert>Field>… (various possibilities). The header or footer is no longer static but dynamically adapts to the current chapter (for example; possibilities are nearly infinite). The consequence of this dynamic behaviour is you then only need a single page style for all your chapters. Chapter heading in the header automatically changes when a new Heading 1 paragraph is met. I am not sure that this procedure survives reliably across DOC save. This is why it is always wise to save documents in native format and use alien formats (with care) for outside end-of-process usage.

1 Like
#19

That sounds great! Thank you. Will definitely look into this. Since Libre is my last step before exporting to PDF and EPUB, I’ll save to ODT from now on before I import images. Should make things easier.

On a side note, I just noticed that the black dot is added by Libre in front of chapter titles when I convert from DOC to ODT. Weird.

#20

Not necessarily. Have a look at Tools>Chapter Numbering. In the Numbering tab, you may request that Separators be inserted before or after the number. It is possible that one of the separator is set to a dot. Erase it. This may be a roll-over from Word.

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