Offset uniqueness in vector of ColorSteps

[Regina Henschel]

Hi Armin,

Armin Le Grand schrieb am 14.03.2023 um 15:08:
> Hi Regina,
> 
> good to hear from you, wanted to contact you already anyways, but we 
> were just moving, so I was pretty busy :-)
> 
> On 3/14/23 14:09, Regina Henschel wrote:
>> Hi Armin,
>>
>> you put the ColorSteps into a sorted vector with unique offsets of the 
>> ColorSteps.
>>
>> I see a problem with "unique". Both OOXML and SVG allow several color 
>> stops to have the same offset. Users need it in OOXML and SVG 
>> gradients to create stepped gradients like those from ODF draw:gradient.
>>
>> Thus forcing uniqueness in our core will give problems in import 
>> filter and in implementing the <svg:radialGradient> and 
>> <svg:linearGradient> from ODF.
> 
> Very good hints, thanks for that.
> 
> Indeed I thought about having two (or more) identical ColorStops to 
> allow a 'rapid' color change at the same offset. I abandoned that by 
> thinking that a very small step could be used that will never get 
> visible, so e.g.
> 
>    0.5
>    0.5000001
> 
> But allowing multiple identical may express that indeed better.
> 
> The problem is and why I chose uniqueness is also/mainly the UI - how to 
> represent equal ColorSteps in a UI trying to visualize the ColorSteps...?

The UI could have a sorted list (drop-down?) of gradient stops, so that 
it is possible to select a gradient stop without using the mouse. Then 
fields for position, color and maybe transparency will act on the 
selected gradient stop.
But that would be a question for the UX-team.

Export to OOXML writes 0.5 as 50000, thus 0.5000001 would be written as 
50000 too. If you want uniqueness, the import filter would need to 
consider that. I have not looked what conversion from and to SVG does.

> 
> So:
> 
> - It should then be OK to have a maximum of *two* ColorStops with 
> identical offset?

I think that could work in common use cases. But the gradient stops will 
be available for macros and I don't know what funny things users do in 
macros. And I do not know enough about SMIL in ODF to say what 
animations are theoretically possible.

> 
> - When correcting that, and there are more than two, delete all but 1st 
> and last? So the in-between ones?

MS Office keeps them. You can traverse the gradient stops with the arrow 
keys in the UI of MS Office.

> 
> - Also dependent of used colors: if all the same color, identicals can 
> be deleted, so go to uniqueness.

That would indeed not be visible in rendering and might ease searching. 
But here too, how react on using gradient stops in macros?

> 
> 
> And Questions for ODF format:
> 
> I see e.g. in SVG something like
> 
> <linearGradient id="Gradient2" x1="0" x2="0" y1="0" y2="1">
>        <stop offset="0%" stop-color="red" />
>        <stop offset="50%" stop-color="black" stop-opacity="0" />
>        <stop offset="100%" stop-color="blue" />
> </linearGradient>
> 
> so I would just add elements like
> 
>        <stop offset="0%" stop-color="red" />
> 
> to our ODF, is that OK from your POV? I remember we once discussed that 
> already, so should be no problem to do that I guess?

For ODF you need to distinguish <draw:gradient> from 
<svg:linearGradient> and <svg:radialGradient>.

The relationship between <svg:linearGradient> and <svg:radialGradient> 
to your ColorSteps vector is indeed straight forward. Only the 
com::sun::star::util::Color has to be split in svg:stop-color with 
#RRGGBB and svg:opacity calculated from alpha.

Using your concept with a stop containing {double Offset, 
com::sun::star::util::Color Color} does not work well for 
<draw:gradient> because StartColor and EndColor in <draw:gradient> are 
without alpha. To get transparency you always need parallel a 
<draw:opacity> element.

Having separate <draw:gradient> and <draw:opacity> elements in ODF 
allows to have gradients with e.g. color change from left to right and 
transparency changing from top to bottom. That cannot be expressed with 
one sequence of your new ColorSteps vector.

Further problems are the relationship between your ColorSteps vector and 
the attributes draw:border and draw:step-count.

> 
> I would take out from this the StartColor (AKA offset == 0.0) and the 
> EndColor (AKA offset == 1.0), so in the normal case there would be no 
> change at all. >
> If there are ColorSteps with offset != 0.0 or 1.0 I would create that 
> extra-entries for these.

What do you mean by "take out"?

> 
> Currently we have something like
> 
> <draw:gradient draw:name="Gradient_20_2"
>      draw:display-name="Gradient 2" draw:style="radial" draw:cx="50%" 
> draw:cy="50%"
>      draw:start-color="#bf0041"
>      draw:end-color="#127622"
>      draw:start-intensity="100%" draw:end-intensity="100%" 
> draw:border="0%"/>
> 
> which would then be something like
> 
> <draw:gradient draw:name="Gradient_20_2"
>      draw:display-name="Gradient 2" draw:style="radial" draw:cx="50%" 
> draw:cy="50%"
>      draw:start-color="#bf0041"
>      <stop offset="0%" stop-color="red" />
>      draw:end-color="#127622"
>      draw:start-intensity="100%" draw:end-intensity="100%" 
> draw:border="0%"/>

That do not work for formal reason: You cannot mix attributes and elements.
But in a first step, the line <stop offset="0%" stop-color="red" /> is 
not needed at all. On writing the markup the values of draw:start-color 
and draw:end-color are calculated from the first and last gradient stop. 
These gradient stops need not be at 0% or 100% respectively, because the 
colors are continued to 0% or 100%. On reading the markup the gradient 
stops at 0% and 100% are calculated from start-color and end-color.

The main task should be to use multi-color gradients to implement the 
two svg-gradient types. And change the import and export filter with 
OOXML to use them for gradFill "lin" and to use them for converting from 
and to SVG. That would be already a great step forward for most users. 
We could even use them for the other OOXML gradFill types, although that 
still makes them not fully compatible with our gradients.

In a second step we can think about bringing multi-color gradients to 
<draw:gradient>. That includes how to handle transparency, border and 
step-count. It might be, that it is easier to introduce new types of 
gradients for <draw:gradient> than to change the existing ones. Or even 
add a new gradient element. We cannot do without <draw:gradient> because 
all types but "linear" and "axial" are not representable with svg-gradients.

> 
> For import of 'older' stuff all will be good.
> 
> For import of new stuff in older Offices we would fallback to 
> Start/EndColor and ignore the In-Between steps - any ways the best we 
> can do AFAIS.

Yes, see above.


A further remark: We have in the meantime "Theme Colors". LO7.6 does not 
yet save theme colors to <draw:gradient>. But you can already have a 
solid fill with a theme color combined with a transparency gradient. Do 
you have already ideas about "Theme Colors" in gradients? Such is needed 
for roundtrip with OOXML.

Kind regards,
Regina