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
