Hi Tomaž,
Tomaž Vajngerl schrieb am 14.04.2023 um 05:25:
Hi Regina,
Sorry, I have vacation so I'm travelling again, but found some time to
reply.
Thank you for looking at it.
On Tue, Apr 11, 2023 at 6:59 AM Regina Henschel <rb.henschel@xxxxxxxxxxx
<mailto:rb.henschel@xxxxxxxxxxx>> wrote:
Hi Tomaž,
I have currently only 'RGBHex' and 'Theme' in my ODF proposal draft.
And
I have put the color-transformations separate from the definition of
the
base color (see attachment). That was my guess from the additions to
the
RelaxNG.
Does integrating the color-transformation into my
<style:enhanced-color>
would better fit to your intentions? I could change that.
Currently we have something like this example:
<style:graphic-properties svg:stroke-color="#536dfe"
draw:fill-color="#bbc5fe" ...>
<loext:fill-color-theme-reference loext:type="accent1">
<loext:transformation loext:type="lummod" loext:value="4000" />
<loext:transformation loext:type="lumoff" loext:value="6000" />
</loext:fill-color-theme-reference>
<loext:stroke-color-theme-reference ... >
....
</loext:stroke-color-theme-reference>
</style:graphic-properties>
I thought to just change it to:
<style:graphic-properties svg:stroke-color="#536dfe"
draw:fill-color="#bbc5fe" ...>
<loext:fill-complex-color loext:type="theme" loext:value="accent1">
<loext:transformation loext:type="lummod" loext:value="4000" />
<loext:transformation loext:type="lumoff" loext:value="6000" />
</loext:fill-complex-color>
<loext:stroke-complexcolor ... >
....
</loext:stroke-complex-color>
</style:graphic-properties>
Do we actually need <style:enhanced-color> element - couldn't we have it
in the attributes of the parent element which would be
fill-complexcolor, stroke-complex-color?
Yes, you are right. We can drop such element. My current version has now
a "common-enhanced-color-attributes", which is used in
<draw:char-complex-color>, <draw:fill-complex-color> and
<draw:stroke-complex-color>.
I could write/read style:color-type="RGBHex" and
style:color-value="#rrggbb" in the <draw:gradient-stop> element if we
agree on that structure.
I think the transformations are fine where they are.
As the <enhanced-color> element is gone now, they need to be child
elements of the several <loext:foo-complex-color> elements. I agree the
current location is OK.
Not sure the change
would make any difference. How the change
The ColorType 'CRGB' did not get support in the ODF TC right away,
because it is also only a variant of RGB. The same would then apply to
ColorType 'HSL'. They could be converted in the xmloff export filter.
Yes, that makes sense. HSL makes sense in some cases (tcould be easier
to think in HSL when you later change one of H, S or L values with a
transform) , but not sure we would use that all that often. >
Regarding ColorType 'System' and its 'SystemColorType', I don't see yet
how this can be implemented well to ODF. It would mean to have a
reference to a color table defined at the user or the user's system.
And
it is different from CSS4 <system-color> [2], so specifying by
reference
to CSS4 will not work.
I think we don't need this for ODF - in OOXML we convert the colors
using a fixed mapping function/table anyway. We don't ask the system
(OS) for the colors.
That makes it easier.
What is ColorType 'Palette' and 'Placeholder'? Is it something, that
needs to be written to ODF markup?
Regarding "Palette" it is the prstClr element in OOXML. Maybe I should
rename it to "Preset" too. We don't need that in ODF I think.
"Placeholder" is needed in themes, but not theme colors. Placeholder is
replaced by a theme (scheme) color, whatever one is defined by that
theme link (IIRC). It's used mainly in the format scheme of a theme - so
for themes for shapes. Would be good to define it now, even when we
won't be really using it yet.
It looks as if I need to dig into the OOXML standard to understand how
it works. But as these drafts are for ODF 1.5 it is not urgent. With the
structure of a pair 'style:color-type and style:color-value' any further
color-type can be easily added.
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.
Having a UNO interface and integration to the gradient would allow to
develop ODF import/export parallel to other filter. Is that correct?
ODF and UNO model don't have to depend on each other because you can
access the internal model in ODF filter too.
It would become relevant, if gradients get theme colors. The access to
gradients goes via css::awt::Gradient2, css::awt::ColorStopSequence and
css::awt:ColorStop.
Do you see a change to get such into LO7.6 (or maybe named LO8)? Or
should we not even try to get integration of multi-color gradient and
theme colors to LO7.6?
I think we can add all the changes that are needed for theme colors and
multi-color gradients into LO 7.6. Maybe some things won't be completed
yet...
The current state of my start with import and export of multi-color
gradient to ODF [3] does not consider "enhanced-color".
That's fine.
It certainly reduces stress if the integration of theme colors with
multi-color gradients is done after the feature freeze of LO 7.6.
However, one must always keep in mind how an integration could look like
so that the course is set right from the start.
I wish you a relaxing vacation. And thank you for your comments that
you have made despite the vacation.
Kind regards,
Regina
