Re: 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 > 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

would better fit to your intentions? I could change that.


Currently we have something like this example:
draw:fill-color="#bbc5fe" ...>

     
     
     
    
    
  
    
  

I thought to just change it to:
draw:fill-color="#bbc5fe" ...>

     
     
     
    
    
  
    
  

Do we actually need  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 
,  and 
.


I could write/read style:color-type="RGBHex" and 
style:color-value="#rrggbb" in the  element if we 
agree on that structure.



I think the transformations are fine where they are.


As the  element is gone now, they need to be child 
elements of the several  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  [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

Re: Extended color

[Tomaž Vajngerl]

Hi Regina,

Sorry, I have vacation so I'm travelling again, but found some time to
reply.

On Tue, Apr 11, 2023 at 6:59 AM Regina Henschel 
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 
> would better fit to your intentions? I could change that.
>

Currently we have something like this example:




   
   
 
   
 

I thought to just change it to:




   
   
 
   
 

Do we actually need  element - couldn't we have it in
the attributes of the parent element which would be  fill-complexcolor,
stroke-complex-color?
I think the transformations are fine where they are. 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  [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.


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


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


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

[2]
> https://www.w3.org/TR/css-color-4/#css-system-colors
> [3]
> https://gerrit.libreoffice.org/c/core/+/150060
>
> Kind regards,
> Regina
>

Regards,
Tomaž Vajngerl

Re: Extended color

[Regina Henschel]

Hi Tomaž,

Tomaž Vajngerl schrieb am 10.04.2023 um 12:30:

Hi Regina,

On Fri, Mar 24, 2023 at 7:01 PM Regina Henschel <mailto:rb.hensc...@t-online.de>> wrote:


Hi all,

There is ongoing development on theme colors and on multi-color
gradients. These require additions to the API and additions to ODF. The
current solutions are not sufficient (I think) or do not exist.
Therefore I suggest a concept of "extended color". Such "extended
color"
has information about the type of the color, a color value and
transformations of the color.

Currently in API, the gradient2 misses theme colors and XThemeColor
misses color transformations. rng additions for theme color misses that
color transformations in OOXML can be combined with any kind of color
type, not only with theme colors, and thus ODF should be extended
accordingly.


Right, well actually XThemeColor doesn't miss transformations - they 
just aren't exposed through the UNO type.The wrapped model::ThemeColor 
has the transformations, but anyway - I'm aware of this issue and I have 
been thinking to add at least a UNO type to represent something like a 
"extended" color.


For the theme definition in OOXML we already need a complete extended 
colors - you can find it in [1] as ColorDefinition class, but the 
requirement of that is completely the same as in other cases.


[1] 
https://cgit.freedesktop.org/libreoffice/core/tree/include/docmodel/theme/FormatScheme.hxx


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  
would better fit to your intentions? I could change that.


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.


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  [2], so specifying by reference 
to CSS4 will not work.


What is ColorType 'Palette' and 'Placeholder'? Is it something, that 
needs to be written to ODF markup?


 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?


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?
The current state of my start with import and export of multi-color 
gradient to ODF [3] does not consider "enhanced-color".


[2]
https://www.w3.org/TR/css-color-4/#css-system-colors
[3]
https://gerrit.libreoffice.org/c/core/+/150060

Kind regards,
Regina




ODF draft multi-color gradient plus theme v3.odt
Description: application/vnd.oasis.opendocument.text

Re: Extended color

[Tomaž Vajngerl]

Hi Regina,

On Fri, Mar 24, 2023 at 7:01 PM Regina Henschel 
wrote:

> Hi all,
>
> There is ongoing development on theme colors and on multi-color
> gradients. These require additions to the API and additions to ODF. The
> current solutions are not sufficient (I think) or do not exist.
> Therefore I suggest a concept of "extended color". Such "extended color"
> has information about the type of the color, a color value and
> transformations of the color.
>
> Currently in API, the gradient2 misses theme colors and XThemeColor
> misses color transformations. rng additions for theme color misses that
> color transformations in OOXML can be combined with any kind of color
> type, not only with theme colors, and thus ODF should be extended
> accordingly.
>

Right, well actually XThemeColor doesn't miss transformations - they just
aren't exposed through the UNO type.The wrapped model::ThemeColor has the
transformations, but anyway - I'm aware of this issue and I have been
thinking to add at least a UNO type to represent something like a
"extended" color.

For the theme definition in OOXML we already need a complete extended
colors - you can find it in [1] as ColorDefinition class, but the
requirement of that is completely the same as in other cases. 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.

[1]
https://cgit.freedesktop.org/libreoffice/core/tree/include/docmodel/theme/FormatScheme.hxx


>
> More concrete descriptions of my idea are below.
>
> Kind regards,
> Regina
>
> For the API in css::awt or in css::util or mixed, here written for awt
> struct ExtColor
>  css::awt::ColorType Type
>  string  Value
>  sequence Transform
>
> enum ColorType {RGBHex, Theme, RGBZeroToOne}
>
> The ColorType determines how the string in Value has to be interpreted.
> Examples:
> Type="RGBHex" Value="#ffcc00". Value is a color in #rrggbb notation.
> Type="Theme" Value="7". Value is an index into ThemeUnoRepresentation[2]
> (="ColorScheme") or css::util::XScheme::ColorSet, respectively.
> Type="RGBZeroToOne" Value="1.0 0.8 0"
>
> struct ColorTransform
>  css::awt::ColorTransformType Type
>  shortValue
>
> enum ColorTransformType {LumMod, LumOff, Alpha}
>
> 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.
>

I much prefer to just provide an interface - XExtendedColor or something
that is better named mainly, because that allows you to just transport the
underlying class through UNO much easier as there isn't really any need for
any kind of mapping (just like css::uno::XThemeColor with
model::ThemeColor, and css::uno::XTheme with model::Theme). That was my
plan generally.

Don't understand why transport the color value around as a string - this is
not really needed as there aren't that many different possibilities here.
There are many more ColorTransformTypes available in OOXML too - especially
tinting and shading are important, also satmod and satoff and others. As
for the value types of the transformations - those could probably be
floating points as mostly they represent some kind of percentage, but it
may not necessarily be that.

I would also think about if there is a better name than "extended color" -
this in itself doesn't say much about it.

struct ColorStop
>  double   StopOffset
>  css::awt::ExtColor   StopColor
>

> These can be straightforward transported to ODF.
> Examples:
> 
>  
>
>
>
>  
>
> 
>   
>  
>  
>  
>  
>  
>  
> 
>
> 
>  
>  
>  RGBHex
>  Theme
>  RGBZeroToOne
>  
>  
>  
>  
>  
>  
>  
>  
>  
> 
>
> 
>  
>  
>  
>  LumMod
>  LumOff
>  Alpha
>  
>  
>  
>  
>  
>  
>  
> 
>
> 
> ...
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> ...
> 
>
> 
> ...
>  
>  
>  
>  
> ...
> 
>
>
> 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).
>

Tomaž

Re: Extended color

[Tomaž Vajngerl]

Hi,

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.
>
>
Sorry , I'm traveling currently. I will reply when I have some time... and
properly look into this when I'm back home mid next week.

Tomaž

Re: Extended color

[Regina Henschel]

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

Re: 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:

    
  
  
  
    
  

    
    
    
    
    
    



    
    
    RGBHex
    Theme
    RGBZeroToOne
    
    
    
    
    
    
    
    
    



    
    
    
    LumMod
    LumOff
    Alpha
    
    
    
    
    
    
    



...
    
    
    
    
    
    
    
    
    
    
...



...
    
    
    
    
...



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)

Re: Extended color

[Regina Henschel]

Regina Henschel schrieb am 24.03.2023 um 11:01:




[..]>




Sorry, not in "attlist" but in "elements". But have no time left today 
to elaborate it.


Kind regards,
Regina

Extended color

[Regina Henschel]

Hi all,

There is ongoing development on theme colors and on multi-color 
gradients. These require additions to the API and additions to ODF. The 
current solutions are not sufficient (I think) or do not exist. 
Therefore I suggest a concept of "extended color". Such "extended color" 
has information about the type of the color, a color value and 
transformations of the color.


Currently in API, the gradient2 misses theme colors and XThemeColor 
misses color transformations. rng additions for theme color misses that 
color transformations in OOXML can be combined with any kind of color 
type, not only with theme colors, and thus ODF should be extended 
accordingly.


More concrete descriptions of my idea are below.

Kind regards,
Regina

For the API in css::awt or in css::util or mixed, here written for awt
struct ExtColor
css::awt::ColorType Type
string  Value
sequence Transform

enum ColorType {RGBHex, Theme, RGBZeroToOne}

The ColorType determines how the string in Value has to be interpreted.
Examples:
Type="RGBHex" Value="#ffcc00". Value is a color in #rrggbb notation.
Type="Theme" Value="7". Value is an index into ThemeUnoRepresentation[2] 
(="ColorScheme") or css::util::XScheme::ColorSet, respectively.

Type="RGBZeroToOne" Value="1.0 0.8 0"

struct ColorTransform
css::awt::ColorTransformType Type
shortValue

enum ColorTransformType {LumMod, LumOff, Alpha}

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


These can be straightforward transported to ODF.
Examples:


  
  
  

  












RGBHex
Theme
RGBZeroToOne















LumMod
LumOff
Alpha










...










...



...




...



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