Offset uniqueness in vector of ColorSteps

[Armin Le Grand]

Hi Regina,

thought about it deeper, and it's even getting stranger quickly. Let me 
express my thoughts about possible problems. I will use an example: A 
ColorStop sequence of four colors, (a..d)o for offset, (a..d)c for the 
color. So let's look at

     1) ao = 0%, ac
     2) bo = 50%, bc
     3) co = 50%, cc
     4, do = 100%, dc

The order these should be used is defined by the offsets. Since 2) and 
3) have the *same* offsets, these have mathematically *no* order. If 
these entries get mixed, it is not possible to restore the order using 
sort - as a consequence of 2) being identical to 3) for the order criteria.

So we could have the following gradient runs rendered:

     a) ac to bc, then cc to dc
     b) ac to cc, then bc to dc
     c) ac to bc, then bc to dc
     d) ac to cc, then cc to dc

Seen strictly from the definition of order, all of these four are 
*valid* interpretations for the gradient to paint.

Intutitively we know that a) is the wanted one. This is because we use 
the order the steps are defined in as a second, indirect criteria. When 
we do that for the processing, we have to make sure that in all cases, 
including some not under our control, keep that second, indirect, 
intuitive criteria:

- reorder in load/save
- order of definition in ODF XML *will* play a role for the 
visualization of the gradient (very unfortunate, do we have that 
anywhere in our format?) e.g. 2) and 3) exchanged
- some pre/post processing tooling or external creator may change order 
or create 'wrong'

In short, it's not a well defined criteria and from my POV hard to 
guarantee, not only in 'our' sphere of influence, but in others, too.

I would really prefer to keep the uniqueness for those reasons, but I 
see that we may have to deal with this. I have the feeling that this 
will open a can of worms...

So - IF you see a chance to do this with uniqueness, don't hold back...

--

Another idea - just for completeness - not seriously taken into account:

If we define color-ranges instead of color-stops each entry would have a 
'in'-color and an 'out'-color. The 'in' of the 0% would not be used. The 
'out' of the 100% would not be used. Every stop would be unique. For 
non-sharp transitions 'in' would be equal to 'out'. For sharp 
transitions it would be different.

Just an idea, we will not do that, but that definition would be safe :-)

--

Kind regards,
         Armin

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.
>
> Kind regards,
> Regina

-- 
--
ALG (PGP: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)