Extended color
Tomaž Vajngerl
quikee at gmail.com
Mon Apr 10 10:30:03 UTC 2023
Hi Regina,
On Fri, Mar 24, 2023 at 7:01 PM Regina Henschel <rb.henschel at t-online.de>
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.
[1]
https://cgit.freedesktop.org/libreoffice/core/tree/include/docmodel/theme/FormatScheme.hxx
>
> 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ž
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20230410/2ad8ab3c/attachment.htm>
More information about the LibreOffice
mailing list