MCGR repair broken offset on import
rb.henschel at t-online.de
Fri Apr 7 23:14:01 UTC 2023
> On 4/5/23 13:58, Regina Henschel wrote:
>> Hi Armin, hi all,
>> I'm currently working on import of multicolor gradients from ODF.
>> With my proposal for standardizing multicolor gradients the offset
>> values would be in interval [0.0,1.0] and sorted in ascending order in
>> a valid file markup.
> There is a correction in place when GradientStops are applied to the
> model data, so after import and transfer over UNO API (see
> It sorts the elements, preserving order for GradientStops with identical
> Let's call the space between two GradientStops GradientStopSegment.
> Every empty (0.0 == 'width') GradientStopSegment < 0.0 or > 1.0 is
> A GradientStopSegment overlapping 0.0 or 1.0 is corrected by moving the
> value outside [0.0 .. 1.0] to 0.0 or 1.0 resp. and also linearly
> interpolating the color of the corrected entry to represent that
> translation >
> This is done by assuming that an overlapping entry might still contain
> useful color information and to get as close as possible to what the
> instance creating that data wanted to define. That might be optimistic,
> but tries to follow the principle to safe as much input data (evtl. from
> the user) as possible and useful - even when the definition might be not
> 100% correct from what we define.
That is different than SVG handles this. But it is fine for me because
such situation will not occur in a valid ODF document.
> Due to this correction it is ensured that we will (potentially) not
> write 'wrong' definitions since all data you can get from the model data
> over the UNO API will be valid in the sense of that definitions. Thus,
> for export, no nee to check for correctness is needed - just export it.
For export I have kept a correction in the way SVG does it to be sure it
will be valid in the ODF sense.
> Since I know no places where data from ODF is imported and not set at
> the model data, this would automatically correct this at load/import
> time and in a roundtrip, too. Thus - for simplicity - you might just
> import from ODF to awt::Gradient2 what is there in the order that is
> there and leave the corrections to the model.
In import, I now take the values as they are. I have tested with offsets
out of range and with offsets in wrong order. After loading, a save and
reload gives the same fill as first load. So I think that works.
My version is in https://gerrit.libreoffice.org/c/core/+/150060. It does
not yet consider theme colors. When your part is finished, it should
work with simple colors. Currently there are some unit tests, which
fail. If you are curious how ODF will look, you can test it.
More information about the LibreOffice