Trouble with theme color in docx

[Regina Henschel]

Hi Tomaž,

Tomaž Vajngerl schrieb am 03.01.2023 um 12:02:
> 
> Yes, you can add the missing long keys here and map them to the 
> dark/light variant.

It turned out, that that was not the only place to change. Adding the 
missing long key gives the correct color, but the FillColorTheme 
property still has value -1.

So I have added the values too to Color::getSchemeColorIndex().

I have added all of the key variants I have seen in the ISO standard. 
But I could not produce docx documents, which uses them. If you think, 
that only those key variants should be added, for which test documents 
exists, I can remove the others. Or perhaps you know how to generate 
(other than manually) documents that use them?

To make it easier to discuss the problem I have put my suggestion into a 
patch, see
https://gerrit.libreoffice.org/c/core/+/145021

> 
>     The only kind of mapping with the long variants that I have found at
>     all
>     is TDefTableHandler::getThemeColorTypeIndex and those assignments look
>     wrong to me (e.g. using 0 for background1 and for dark1).
> 
> 
> This is indeed wrong.. background should map to light and text to dark. 
> I will fix this but it will take a while until it hits master, unless 
> you need to change this too?

That area is not touched by Fontwork.

> 
>     VML import/export is likely effected too, because it uses <w:color
>     w:themeColor=".."> too >
> 
> Yes, probably this needs to be changed also, but it's only for backwards 
> compatibility.

Unfortunately MS Word uses VML not only as fall back, but for example if 
Word opens an odf-file with a Fontwork with bitmap fill, Word converts 
it so to docx that VML is the main choice. Reason in this case is, that 
DrawingML is not able to express an 'abc Transform' with bitmap fill, 
VML can express it as WordArt.


Another question: There exists no LineColorTheme. Will it come?

Kind regards
Regina