MCGR repair broken offset on import

[Armin Le Grand]

Hi,

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

It sorts the elements, preserving order for GradientStops with identical 
StopOffset.

Let's call the space between two GradientStops GradientStopSegment.

Every empty (0.0 == 'width') GradientStopSegment < 0.0 or > 1.0 is 
discarded.

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.

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.

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.

Just my 2ct...

>
> (A)
> Should I nevertheless repair a broken sequence of gradient stops to be 
> tolerant in regard to invalid markup?
>
> If yes, how to handle offsets out of range? It could be:
> (1) remove such stops
> (2) round up values < 0.0 to 0.0 and round down values > 1.0 to 1.0.
> (2) corresponds to section 14.2.4.3 SVG specification [1]
>
> If yes, how to handle out of order?
> My suggestion would be to do the same as specified for SVG [1]
>
> (B)
> My proposal for standardizing multicolor gradients contains the rule:
> "If the first <draw:gradient-stop> element has a svg:offset value 
> larger than 0.0, consumers shall behave as if there is an additional 
> <draw:gradient-stop> element with svg:offset="0.0" and same 
> <style:enhanced-color> and <style:color-transform> child elements as 
> in the first <draw:gradient-stop> element."
> and analogous for 1.0.
>
> I could add such additional stop on import. Should I do that, or do 
> you always handle such situation already in this sense?
>
> [1] https://svgwg.org/svg2-draft/pservers.html#StopNotes
> or at the end of section 13.2 in
> https://www.w3.org/TR/2011/REC-SVG11-20110816/pservers.html#GradientStops
>
> Kind regards,
> Regina
>
-- 
--
ALG (PGP: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)