Hi Armin,
Armin Le Grand schrieb am 31.03.2023 um 13:29:
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
I'm only thinking about API and ODF. My proposals do not touch
primitives and FillGradientAttribute.
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).
Then we agree.
Nevertheless, we need to track the relationship to themes and color
transformations. Those are needed in export to OOXML and ODF.
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 would be good, if Tomaž Vajngerl could give an overview over his
plans, especially how _he_ things to integrate theme colors and
multi-color gradients.
Kind regards,
Regina
