Hi Regina,
On Fri, Mar 24, 2023 at 7:01 PM Regina Henschel <rb.henschel@xxxxxxxxxxx> wrote:
Hi all,
There is ongoing development on theme colors and on multi-color
gradients. These require additions to the API and additions to ODF. The
current solutions are not sufficient (I think) or do not exist.
Therefore I suggest a concept of "extended color". Such "extended color"
has information about the type of the color, a color value and
transformations of the color.
Currently in API, the gradient2 misses theme colors and XThemeColor
misses color transformations. rng additions for theme color misses that
color transformations in OOXML can be combined with any kind of color
type, not only with theme colors, and thus ODF should be extended
accordingly.
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.
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.
More concrete descriptions of my idea are below.
Kind regards,
Regina
For the API in css::awt or in css::util or mixed, here written for awt
struct ExtColor
css::awt::ColorType Type
string Value
sequence<css::awt::ColorTransform> Transform
enum ColorType {RGBHex, Theme, RGBZeroToOne}
The ColorType determines how the string in Value has to be interpreted.
Examples:
Type="RGBHex" Value="#ffcc00". Value is a color in #rrggbb notation.
Type="Theme" Value="7". Value is an index into ThemeUnoRepresentation[2]
(="ColorScheme") or css::util::XScheme::ColorSet, respectively.
Type="RGBZeroToOne" Value="1.0 0.8 0"
struct ColorTransform
css::awt::ColorTransformType Type
short Value
enum ColorTransformType {LumMod, LumOff, Alpha}
The ColorTransformType determines how the number in Value has to be
interpreted.
Examples: Type="LumMod" Value="6000" means to modify the luminance of
the color with 60% as specified in OOXML.
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.
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.
I would also think about if there is a better name than "extended color" - this in itself doesn't say much about it.
struct ColorStop
double StopOffset
css::awt::ExtColor StopColor
These can be straightforward transported to ODF.
Examples:
<rng:define name="draw-gradient">
<rng:element name="draw:gradient">
<rng:ref name="common-draw-gradient-attlist"/>
<rng:ref name="draw-gradient-attlist"/>
<rng:optional>
<rng:ref name="style-gradient-stop" />
</rng:optional>
</rng:element
<rng:define name="style-gradient-stop"
<rng:element name="style:gradient-stop>
<rng:attribute name="style:color-offset>
<rng:ref name="zeroToOneDecimal" />
</rng:attribute>
<rng:element name="style:color-stop">
<rng:ref name="style-extended-color"/>
</rng:element>
</rng:element>
</rng:define>
<rng:define name="style-extended-color">
<rng:element name="style:extended-color>
<rng:attribute name="style:color-type">
<rng:choice>
<value>RGBHex</value>
<Value>Theme</value>
<value>RGBZeroToOne</value>
</rng:choice>
</rng:attribute>
<rng:attribute name="style:value">
<rng:ref name="string" />
</rng:attribute>
<rng:zeroOrMore>
<rng:ref name="style-color-transform">
</rng:zeroOrMore>
</rng:element>
</rng:define>
<rng:define name="style-color-transform">
<rng:element name="style:color-transform">
<rng:attribute name="style:color-transform-type">
<rng:choice>
<rng:value>LumMod</rng:value>
<rng:value>LumOff</rng:value>
<rng:value>Alpha</rng:value>
</rng:choice>
</rng:attribute>
<rng:attribute name="style:value">
<rng:ref name="integer" />
</rng:attribute>
<rng:empty/>
</rng:element>
</rng:define>
<rng:define name="style-graphic-fill-properties-attlist">
...
<rng:optional>
<rng:attribute name="draw:fill-extended-color">
<rng:ref name="style-extended-color"/>
</rng:attribute>
<rng:optional>
<rng:optional>
<rng:attribute name="draw:stroke-extended-color">
<rng:ref name="style-extended-color"/>
</rng:attribute>
</rng:optional>
...
</rng:define>
<rng:define name="style-text-properties-attlist">
...
<rng:optional>
<rng:attribute name="style:text-extended-color>
<rng:ref name="style-extended-color"/>
</rng:attribute>
</rng:optional>
...
</rng:define>
If we want to be more flexible in ODF for color-type or
color-transform-type, we could use a namespaced string as datatype and
make it implementation-dependent (to allow all of enum class
TransformationType, for example).
Tomaž
