Description: Stumled over a SVG graphic that is not correctly broken up when converted to SdrObjects. It is one of the many existing 'Tux' ones with several gradients. Some of these are problematic in this respect. I have reduced the example and extracted one gradient (left foot). When breaking it into SdrObjects, one element is mssing and thus the gradient looks broken. Note: Currently that break still uses the in-between step to convert the primitive representation (that is fine and can represent SVG gradients) to a Metafile. This is then broken to SdrObjects. At their creation these are 'clipped' against the original form, e.g. an ellipse in this case, that is used as ClipRegion in the Metafile. Steps to Reproduce: 1.Start LO 2.Open reduced SVG example 'simple-ellipse.svg' 3.Select object, choose 'break' in context menu -> Creates needed Objects, but there is a 'gap' in the gradient where an element is missing Actual Results: Gap in broken graphic Expected Results: Created SdrObject-representation shows gradient error-free identical to original Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Identified the clipping has a problem for extreme case. - SvgLinearAtomPrimitive2D gets decomposed - added to Metafile with - orig Ellipse as ClipRegion - single parts of SvgLinearAtomPrimitive2D as content - converion to SdrObects clips single content geometries - due to the SvgLinearAtomPrimitive2D optimally creating the content the content touches the ellipse - Identified a case where an edge point of content exactly hits ellipse border. That is detected, but still problematic - the ellipse horder is a Bezier-snippet. The preparation of clip works well - allpoints are identified The processing of clip - switching in points, extracting content - does make an error here One possibility to solve this is to create some 'overlap' in SvgLinearAtomPrimitive2D decomposition. Just do not use 0.0 and 1.0 for Y-Coordinates, but slight overlap. Despite that this would work this - should not be needed - may cause problems in other places - does not solve the error in the clipper -> may still happen in other places/conditions => try to solve in clipper 2nd step first. on it...
Created attachment 142550 [details] One foot of 'Tux' isolated showing the problem
Spent quite some time in checking/reorg/debugging (my own) clipping bezier stuff. Will need more time to solve. For now, fallback to simple solution (and mark it as temporary in the code)
Added solution (see https://gerrit.libreoffice.org/#/c/55376/)
Armin Le Grand committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa5d7477e8e1e4bcd0e56496e745c3dc3b05c369 tdf#117949 Use small overlap for SVG gradient representation It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Solution in master, done.
Armin Le Grand committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a3423a4efd016014158fdeec34e1f75960f8604a&h=libreoffice-6-1 tdf#117949 Use small overlap for SVG gradient representation It will be available in 6.1.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Back-ported to libreoffice-6-1