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)
