Extended color

[Regina Henschel]

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 at t-online.de 
> <mailto:rb.henschel at t-online.de>> 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