Extended color

[Armin Le Grand]

Hi,

On 3/24/23 11:01, Regina Henschel wrote:
> 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.
>
> struct ColorStop
>     double               StopOffset
>     css::awt::ExtColor   StopColor
>
We should split it here from my POV.

(a) There is the model data in the XFillGradientItem and 
XFillFloatTransparenceItem expressed as XGradient

(b) There is FillGradientAttribute used in primitives

Both use currently basegfx::ColorStops and thus ColorStop which just 
uses a basegfx::BColor as color definition. I agree that we should use 
css::awt::ExtColor in the model data (a), but not in (b).

The issue is that primitives are designed to be self-contained, thus 
should contain a 'complete' data set to describe their content, also to 
be able to implement as simple as possible, and *local*, decomposition. 
If they would contain the ColorType 'Theme' always some kind of 'solver' 
would be necessary to be in reach to get the end result of the color to 
be used in the visualization.

Thus the primitives in (b) should already contain the result of that 
processing that converts from a theme color to the render color. This 
fits well together, so in the primitive creating step where (a) is 
processed the probability to have such a 'solver' is high (should be 
e.g. in the same ItemSet?). Just 'solve' it there and use the result in 
a single representation form in the to-be-created primitive.

It *could* also be done in the decompose with adding callbacks and extra 
info e.g. in DisplayInfo (similar to already providing the XPage there 
to be able to decompose text that contains a page number field 
correctly), but that makes things unnecessarily complicated and 
error-prone (could be easily forgotten). Better remove that case once in 
the future then adding more such cases...

So - yes, let's add ColorType to the model data, but - no, not to the 
primitive data, please.

Just my 2ct,

Regards, Armin


>
> 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).

-- 
--
ALG (PGP: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)