Re: MCGR repair broken offset on import
Hi, On 4/8/23 01:14, Regina Henschel wrote: Hi Armin, Hi, 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. Yes, that is true and we can always argue when parameters outside of the valid range are feed in. Point from my POV is that UNO API needs to check anyways in all cases - it cannot rely on being only used in XML im/exports, so it will always need to be checked/corrected at UNO API when values move to the core and will not be allowed to deliver results outside defined valid ranges when asking for values from the core. Thus double checking/correcting at the XML im/exports is just not needed - and would be double, risking slightly diverging handling. From my POV... 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. Should alreay be cheked, see above. Will do no ham, but should not trigger. 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. Yes, I tested that, too :-) 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. Looking foward to that - when we have ODF im/export we can use MCGR in templates - e.g. gradient templates in the Area... TabPage :-) And offer some nice gadients for the uses Kind regards, Regina Regards, Armin -- -- ALG (PGP: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)
Re: MCGR repair broken offset on import
Hi Armin, 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. 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. Kind regards, Regina
Re: MCGR repair broken offset on import
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 element has a svg:offset value larger than 0.0, consumers shall behave as if there is an additional element with svg:offset="0.0" and same and child elements as in the first 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)
MCGR repair broken offset on import
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. (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 element has a svg:offset value larger than 0.0, consumers shall behave as if there is an additional element with svg:offset="0.0" and same and child elements as in the first 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
