The commits 0c13e476 and 1868dea8 have introduced 'fill-theme-color', 'fill-color-lum-off' and 'fill-color-lum-mode' attributes. They are written to files in ODF format in loext namespace. The new attributes need to be documented in "ODF Implementer Notes" https://wiki.documentfoundation.org/Development/ODF_Implementer_Notes/List_of_LibreOffice_ODF_Extensions
Yes, all 3 TODO(vmiklos) in schema/libreoffice/OpenDocument-v1.3+libreoffice-schema.rng is about the theme topic, because it's a huge one and I can't decide what's the right moment to standardize this. We now have shape fill color and shape text color support in Impress themes. That's at least two areas, but I expect many more will be needed (about everywhere, where colors can be specified). I can write up some more formal spec on this if you think it's not too early. Anyhow, I've now added rows for the following elements / attributes in that monster table at <https://wiki.documentfoundation.org/Development/ODF_Implementer_Notes/List_of_LibreOffice_ODF_Extensions#LibreOffice_ODF_extensions>: - loext:theme - loext:fill-theme-color - loext:fill-color-lum-mod - loext:fill-color-lum-off - loext:theme-color - loext:color-lum-mod - loext:color-lum-off The idea is hopefully not too complicated. Instead of working with raw RGB values in direct formatting, theming allows referring to colors by name (e.g. "accent 1"). The theme has a hardcoded set of 12 colors, so you can also refer to these names by an int in code. When you refer to such a color, you can also make it lighter/darker, luminance modulation/offset allows this (this concept is modeled after OOXML).
Thank you Miklos for adding the information to the ODF_Implementer_Notes. I think more is at this point not needed. The feature is not yet finished. From point of implementation, SmartArt is missing (bug 151882) and copy&paste behavior is not clear. From point of ODF I wonder about the loext:name attribute. Can there be more than one loext:theme element? If yes, I would expect a reference with that name in the graphic-properties. If not, what is the purpose of loext:name? And, why is the theme definition in the master-page? List, number format, gradient and table template are elements in <style:style> for examples. A theme could be handled similar.
> From point of ODF I wonder about the loext:name attribute. Can there be more than one loext:theme element? OOXML themes can have a name, it sounds like a good idea to preserve this. We may have a UI later that selects a theme by name + preview in the future, see bug 151900 and bug 151902. The idea is to have one theme per master page in Impress, which would match the presentationML markup (so import/export is simple). > And, why is the theme definition in the master-page? The Writer can will be simpler, just one theme per document (it's what wordprocessingML has). But Impress needs a theme per master page to have a 1:1 mapping from/to presentationML. You can see this in action if you create 2 master pages in powerpoint, with different themes. Once you change the master page of a slide, the shapes on the slide are automatically updated to the new theme. The goal would be to have the same in Impress at the end. Also, themes work in parallel to styles. A style has a set of formatting then direct formatting can refer to it and optionally override parts of it. A color from a theme is just a name, but otherwise still direct formatting. I can say that I want fill color to be "accent 1", and I can say this both from direct formatting and from a style. At least that's how I understand OOXML's theme concept, which looks mostly reasonable (and probably a good idea to model our theme support after that).
Miklos, thanks for your explanations.