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
