<div dir="ltr"><div dir="ltr">Hi Regina,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 24, 2023 at 7:01 PM Regina Henschel <<a href="mailto:rb.henschel@t-online.de" target="_blank">rb.henschel@t-online.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
There is ongoing development on theme colors and on multi-color <br>
gradients. These require additions to the API and additions to ODF. The <br>
current solutions are not sufficient (I think) or do not exist. <br>
Therefore I suggest a concept of "extended color". Such "extended color" <br>
has information about the type of the color, a color value and <br>
transformations of the color.<br>
<br>
Currently in API, the gradient2 misses theme colors and XThemeColor <br>
misses color transformations. rng additions for theme color misses that <br>
color transformations in OOXML can be combined with any kind of color <br>
type, not only with theme colors, and thus ODF should be extended <br>
accordingly.<br></blockquote><div><br></div><div>Right, well actually XThemeColor doesn't miss transformations - they just aren't exposed through the UNO type.The wrapped model::ThemeColor has the transformations, but anyway - I'm aware of this issue and I have been thinking to add at least a UNO type to represent something like a "extended" color.</div><div><br></div><div>For the theme definition in OOXML we already need a complete extended colors - you can find it in [1] as ColorDefinition class, but the requirement of that is completely the same as in other cases. We could make create a UNO interface for that first and a wrapper, then use it at all places where XThemeColor is used now, and also add it to the gradient. <br></div><div><br></div><div>[1] <a href="https://cgit.freedesktop.org/libreoffice/core/tree/include/docmodel/theme/FormatScheme.hxx" target="_blank">https://cgit.freedesktop.org/libreoffice/core/tree/include/docmodel/theme/FormatScheme.hxx</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
More concrete descriptions of my idea are below.<br>
<br>
Kind regards,<br>
Regina<br>
<br>
For the API in css::awt or in css::util or mixed, here written for awt<br>
struct ExtColor<br>
css::awt::ColorType Type<br>
string Value<br>
sequence<css::awt::ColorTransform> Transform<br>
<br>
enum ColorType {RGBHex, Theme, RGBZeroToOne}<br>
<br>
The ColorType determines how the string in Value has to be interpreted.<br>
Examples:<br>
Type="RGBHex" Value="#ffcc00". Value is a color in #rrggbb notation.<br>
Type="Theme" Value="7". Value is an index into ThemeUnoRepresentation[2] <br>
(="ColorScheme") or css::util::XScheme::ColorSet, respectively.<br>
Type="RGBZeroToOne" Value="1.0 0.8 0"<br>
<br>
struct ColorTransform<br>
css::awt::ColorTransformType Type<br>
short Value<br>
<br>
enum ColorTransformType {LumMod, LumOff, Alpha}<br>
<br>
The ColorTransformType determines how the number in Value has to be <br>
interpreted.<br>
Examples: Type="LumMod" Value="6000" means to modify the luminance of <br>
the color with 60% as specified in OOXML.<br></blockquote><div><br></div><div>I much prefer to just provide an interface - XExtendedColor or something that is better named mainly, because that allows you to just transport the underlying class through UNO much easier as there isn't really any need for any kind of mapping (just like css::uno::XThemeColor with model::ThemeColor, and css::uno::XTheme with model::Theme). That was my plan generally. <br></div><div><br></div><div>Don't understand why transport the color value around as a string - this is not really needed as there aren't that many different possibilities here. There are many more ColorTransformTypes available in OOXML too - especially tinting and shading are important, also satmod and satoff and others. As for the value types of the transformations - those could probably be floating points as mostly they represent some kind of percentage, but it may not necessarily be that.<br></div><div><br></div><div>I would also think about if there is a better name than "extended color" - this in itself doesn't say much about it. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
struct ColorStop<br>
double StopOffset<br>
css::awt::ExtColor StopColor <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
These can be straightforward transported to ODF.<br>
Examples:<br>
<rng:define name="draw-gradient"><br>
<rng:element name="draw:gradient"><br>
<rng:ref name="common-draw-gradient-attlist"/><br>
<rng:ref name="draw-gradient-attlist"/><br>
<rng:optional><br>
<rng:ref name="style-gradient-stop" /><br>
</rng:optional><br>
</rng:element<br>
<br>
<rng:define name="style-gradient-stop"<br>
<rng:element name="style:gradient-stop><br>
<rng:attribute name="style:color-offset><br>
<rng:ref name="zeroToOneDecimal" /><br>
</rng:attribute><br>
<rng:element name="style:color-stop"><br>
<rng:ref name="style-extended-color"/><br>
</rng:element><br>
</rng:element><br>
</rng:define><br>
<br>
<rng:define name="style-extended-color"><br>
<rng:element name="style:extended-color><br>
<rng:attribute name="style:color-type"><br>
<rng:choice><br>
<value>RGBHex</value><br>
<Value>Theme</value><br>
<value>RGBZeroToOne</value><br>
</rng:choice><br>
</rng:attribute><br>
<rng:attribute name="style:value"><br>
<rng:ref name="string" /><br>
</rng:attribute><br>
<rng:zeroOrMore><br>
<rng:ref name="style-color-transform"><br>
</rng:zeroOrMore><br>
</rng:element><br>
</rng:define><br>
<br>
<rng:define name="style-color-transform"><br>
<rng:element name="style:color-transform"><br>
<rng:attribute name="style:color-transform-type"><br>
<rng:choice><br>
<rng:value>LumMod</rng:value><br>
<rng:value>LumOff</rng:value><br>
<rng:value>Alpha</rng:value><br>
</rng:choice><br>
</rng:attribute><br>
<rng:attribute name="style:value"><br>
<rng:ref name="integer" /><br>
</rng:attribute><br>
<rng:empty/><br>
</rng:element><br>
</rng:define><br>
<br>
<rng:define name="style-graphic-fill-properties-attlist"><br>
...<br>
<rng:optional><br>
<rng:attribute name="draw:fill-extended-color"><br>
<rng:ref name="style-extended-color"/><br>
</rng:attribute><br>
<rng:optional><br>
<rng:optional><br>
<rng:attribute name="draw:stroke-extended-color"><br>
<rng:ref name="style-extended-color"/><br>
</rng:attribute><br>
</rng:optional><br>
...<br>
</rng:define><br>
<br>
<rng:define name="style-text-properties-attlist"><br>
...<br>
<rng:optional><br>
<rng:attribute name="style:text-extended-color><br>
<rng:ref name="style-extended-color"/><br>
</rng:attribute><br>
</rng:optional><br>
...<br>
</rng:define><br>
<br>
<br>
If we want to be more flexible in ODF for color-type or <br>
color-transform-type, we could use a namespaced string as datatype and <br>
make it implementation-dependent (to allow all of enum class <br>
TransformationType, for example).<br></blockquote><div><br></div><div>Tomaž <br></div></div></div>