https://bugs.documentfoundation.org/show_bug.cgi?id=107787

--- Comment #36 from Regina Henschel <[email protected]> ---
Created attachment 188147
  --> https://bugs.documentfoundation.org/attachment.cgi?id=188147&action=edit
Increment 3 in MCGR

(In reply to Heiko Tietze from comment #35)
> (In reply to Regina Henschel from comment #33)
> > Or should the design of the dialog be changed (with is needed for multicolor
> > gradients anyway) to make clear, that the Increment value does not belong to
> > a gradient definition but is an attribute of the individual object?
> 
> This. I suggest to check (=Automatic) and disable the steps spinbox if more
> than two colors are used aka MCGR.

So you suggest to always use "automatic" in case the gradient has more than two
color stops?

The current behavior is, that in case there are more than two color stops and
the user has set an Increment value, the stepped rendering is applied
individually to each part between two adjacent stops.

Example attached: [1] offset 0.2 red, [2] offset 0.5 yellow, [3] offset 0.95
green and Increment=3. Current behavior:
0 to 0.2 red (automatic extending of the first color),
0.2 to 0.3 red (first step)
0.3 to 0.4 orange (second step)
0.4 to 0.5 yellow (third step)
0.5 to 0.65 yellow (first step)
0.65 to 0.8 yellow+green mix (second step)
0.8 to 0.95 green (third step)
0.95 to 1 green (automatic extending of the last color)

For me it looks ugly and I would support to use always 'automatic' in case of
more than two colors. The user can still create steps by setting two stops to
same offset. Having always 'automatic' in this case brings no restriction to
the OOXML filter, because OOXML has no setting for stepped rendering at all.

Because MCGR is not yet in ODF, we could include such restriction into the
proposal to the ODF TC.

> 
> (In reply to Regina Henschel from comment #33)
> > Heiko, do you really want, that the XML of our palette is
> > changed to be able to carry the Increment value in addition?
> 
> Ultimately being able to have 5 steps for red to blue followed by a smooth
> transition from blue to green, as an example? Hopefully I never suggested
> this (keep it simple).

I do not mean a mix but this: Users currently do not understand, why a preset
gradient cannot have a stepped rendering, although the shape from which the
preset is created had an Increment=4, for example. The current solution of the
Gradient-dialog has no indication that it is not possible.

This problem exists independent from MCGR and is not solved by forcing
'automatic' in case of more than two colors.

I see the following solutions. Which would do you prefer?
(A) The current css.awt.Gradient struct from the API contains the Increment as
StepCount component, whereas the gradient definition in the <draw:gradient> in
ODF has no corresponding attribute. Currently the XML of the palette uses the
ODF definition directly. Because the XML of the palette is our own format we
could change it without impacts to ODF. Of course, this is not to be had for
free; it requires a developer to donate his free time to it.

(B) The dialog could show a warning, that the Increment-value is not included
in the added gradient, in case an Increment-value is set and the user adds this
gradient to the palette.

(C) Separate the Increment setting visually from the others in the dialog and
include a hint/warning in its label.

(B) and (C) affects only the dialog and could be done, when the dialog is
adapted to MCGR.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to