Is there any way to set a color in LibreOffice Writer in multiple places that I can change later?

Is there any way to set a color in LibreOffice Writer in multiple places that I can change later? By this I mean, is there a plugin or setting that allows me to allocate a custom color code, e.g. “Color9746” in various places, e.g. specific character styles, paragraph styles, some boxes and backgrounds etc, and then in 1 go be able to change all those colors by changing the color allocation of Color9746 e.g. from Hex 1 to Hex 2?

Eg if this window (Format → Text Box & Shape → Area…) had an “edit” function for a color, that would be the function I mean. But it only seems to allow adding new colors, not editing them.

Just tested to create, apply and delete a color. Then create another color with the same name.

But colors are saved in documents with its Hex code.

<style:text-properties fo:background-color="#dcdcc1" loext:char-shading-value="0"/>

So, I don’t see an eassy way to change it, except to:

1 Like

Yes…create your custom charstyle →→F11 with Attribut Backcolor only … apply that charstyle to multiple selections.

If you later want to change the color, you need to change only the charstyle itself, done!

Hi,
thanks for the comment, I agree it is a workaround, but it is not an elegant solution:

  • this cannot be applied to boxes, lines, etc
  • it is not possible to use two character styles simultaneously, so this can only be applied to texts that do not already require some other character style

It would be much nicer if there was codes that you could ‘programme’ for the document, kind of like how Wordpress has recently started working with ‘programmable’ colors (instead of only fixed colors for elements) that can be changed at any time in the CSS

You can edit the file config/standard.soc in User profile to set your names for colors.
Changing the colored elements is possible with Find&Replace dialog, or via definitions of colors in Styles, or via macros.

hi thanks for your reply. So I am not looking to change names, so I think changing the User Profile is not needed, unless it allows me to change the HEX codes of default colors in LO?

Re " Find&Replace dialog, or via definitions of colors in Styles, or via macros." → It is not entirely clear to me how this answers my use case. What I am looking for is an ability to change a color that is used in multiple places in the document (e.g. in certain paragraph styles, in certain character styles, and for certain lines and boxes) - and to change them all in 1 go. Sort of like an applied color that I can edit later. Is that possible using one of your suggestions?

Yes, it is possible to change the HEX codes of default colors in the file standard.soc. Try to open this file and I think you will see immediately :slight_smile:.

Change one color in all items in document is possible with macro, but easier is if you know all type of places that has this color. It could be difficult to traverse all items in document (like text boxes, lines etc.) but it is not impossible.

Maybe next but potentially wild+unsafe way could be unzip the ODT (it is renamed ZIP) and edit the content.xml or other XMLs manually :slight_smile:.

1 Like

hi thanks for the follow up!
I just tested this: changing the standard.soc document in /usr/lib/libreoffice/share/palette/ does indeed change the standard colors. But, and a big but for my use case :), it does not change the items that have been given that color in documents. They stay the old color that the color had before changing it in the standard.soc.
Trying the xml thing next: could you explain me where to find this file?

I thought your Ask had two parts: 1st → change the definitions of colors + 2nd → change the colors in document. Of course the change of standard.soc will not change the colors in document, only in LibreOffice palette.
So now I know you need “only” to change the colors in document. Ok, backup your ODT, then rename ODT to ZIP and unzip it to see the XML files, and start to browse the content.xml (then other XMLs). Change the colors and repack it to ZIP and rename to ODT and try :slight_smile:.

1 Like

oh wow I had no idea you could do this to an ODT file :joy: !!
It worked really well, except it does not seem to change things in the footers + character styles also do not change. They are probably in other XML files.

But I think we can all agree this is a workaround :). Where would I request this to be incorporated as a regular feature? It is clearly possible.

I think the footers are in styles.xml.
See much more sophisticated work with XML structure for ODT, it seems it is possible to solve your problem without unzipping :slight_smile:.

For request you can read:

1 Like

thanks for the help!

First be aware that drawing objects like text boxes and other geometrical shapes are not controlled by styles. Also using text boxes, except in form design, does not fit in the intended workflow of Writer. Writer is supposed to manage a text flow made of paragraphs and anchored “objects” (normally frames).

Now your problem is to define some sort of “master colour” so that changing it will cascade to all its uses. You can’t do that uniformly. You must consider four cases. These four cases are related to the various style categories.

Paragraph styles

Paragraph styles can be organised in a tree-like structure where styles lower in the hierarchy inherit attributes from their ancestors (until you override an attribute).

Consequently, if this makes sense, you can create a custom style to define the colour (font colour, background, border colour, …) and have the styles sharing the colour as descendants of this custom style. This custom style being a “technical” one will not be used in your document, only the descendants will be.

But, this may be semantically incorrect. For example, if you force a common ancestor to Heading and Text Body, you end up with the colour being the same in the sub-hierarchies Heading (all chapter heading at any level) and Text Body (common text, lists). Therefore, if you want separate colour, you might as well set it in Heading and Text Body to preserve versatility. Of course, you’ll then have to set the colour in two “sub-master styles”.

Also, the inheritance is strictly tree-like: a style can have only one ancestor. This means you cannot control with a single style List (which is below Text Body) and Heading 1 (which is below Heading) because this would mean they have several direct ancestors (both your custom style anf Text Body in the former case, your custom style and Heading in the latter case).

Character styles

Character styles can inherit from each other like paragraph styles. See preceding chapter.

Page styles

Page styles cannot inherit. They are all stand alone. Therefore you must define the colour in use manually in each style.

Frame styles

Frame styles can inherit from each other. Since you’re liable to set only the background colour, it makes sense to define it in some ancestor. But usually, you use a single frame style if you design smartly your document. This also means you’re inserting your pictures, drawings, … with styling, not as direct formatting. Be aware this is difficult to master and you easily end up with direct formatting (even more frequently than with text) when yo “touch” the frame in any way. This direct formatting overlaying the frame defeats all the benefits of styles.

You need a lot of practice before feeling at ease with frame styles. So learn them (start by reading the documentation and deeply pounding about it), play with them, analyse your errors and finally adopt frame styles.

hi thank you for this extensive answer. OK so the ‘master colors’ I am looking for appears not possible indeed. I think it would make a great addition to LO!
Thanks I will work with the hierarchies you have suggested for now.

There is ongoing work in implementing “Theme colors”. You will then be able to assign a color from a palette “Theme colors”. That will store the name of the color (out of 12 possible names) but not the RGB values. You can then change the color value in the palette and all uses of the color will adapt. You can test the current state of the development in a daily build from Index of /daily/master/. Such developer build can be installed parallel to a regular version and does not interfere with it.

3 Likes

Amazing, thanks for this! I am going to try it.
If you are on the dev team: I posted this feature request before I read your post:
https://bugs.documentfoundation.org/show_bug.cgi?id=156909
But perhaps it is obsolete now, feel free to close it if that is your role.