Re: Offset uniqueness in vector of ColorSteps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux