Offset uniqueness in vector of ColorSteps

[Armin Le Grand]

Hi Regina,

thanks for the points, will comment inline

On 3/14/23 23:07, Regina Henschel wrote:
> 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.


Yes, I already discussed on FOSDEM with Heiko, so it's initiated (we 
discussed about that anyways for years :-)). Fact is that UI is far 
away, 1st need to get that working in the core & im/exports. Of course 
an intuitive graphical visualization with added interactions would be 
preferrable to a list view - just my 2ct - but list view may be 1st shot 
later...


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


Yes, that was only a 'guessed' example. In that case and knowing that 
keeping a small distance is needed due to it's meaning/definition of 
course 50000/50001 would have to be used, an export filter would have to 
be aware of that 'special' value. Note: no, I do *not* like special 
values, but...


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


Yes, we cannot change our stuff too far to get to svg definitions - we 
will not get rid of these. We will also not have a svg:spreadMethod. The 
currently important point is to use existing svg definitions (to not get 
even further away from svg as needed) as far as possible, as far in 
their svg meaning as possible, too.

For now we need to get the Color-Stops added to 'our' gradients. Do you 
have concrete examples/advice how to do that?


>
>>
>> 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"?


Just that for 0% I would use our draw:start-color and for 100% our 
draw:end-color. I would only write new entries in svg-conform semantic 
for offsets ]0%..100%[. This is to stay as compatible as possible. It 
also makes no sense to 'double' the information with having the same 
color represented e.g. for StartColor once as draw:start-color and once 
as <stop offset="0%"/>.


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


I disagree here. To get forward for now the easiest would just be to 
'somehow' add the Color-Steps which are not Start/EndColor in a 
as-svg-compatible way as possibe to 'our' gradients for now. The 'other' 
possibility is (unfortunately) not backed, so when we want that in odf 
we need the simple way 1st definitely...

The replacement/mapping step to get them moved to the two SVG types 
is/will be much more complicated. I agree that four could be mapped, but 
I also agree that lots of our old attributes (not only border and 
step-count). A short hint for transparency - we can just do that on a 
higher level by adding a TransparencyGradient to objects that need them 
with the same gradient definition - that will work. You can easily 
create an example in draw, create an object with gradient, choose to 
also have a transparency gradient, put the values to the same values and 
you get controllable transparency in the same granularity as the 
gradient itself.


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


Not yet, but thanks for the hint, will keep a note in my mind - one 
after the other..


>
> Kind regards,
> Regina

Kind regards back,
     Armin


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