Issue 125349

The scenario involves two cascading clip regions defined in the primitive set that gets produced. This in principle no problem - the visualization shows that these regions are perfectly well defined.
The 1st clip region is needed for the svg itself, because content shows outside the svg bounds (this is detected in the svg importer). The 2nd clip region is used to give the gradient fill it's shape (shape as clip region, content renders e.g. a rectangular gradient)
When the primitive content needs to be converted to metafile the situation gets different: Metafiles only know one clip region at a time. Thus, when one is already set and a 2nd one is to be set, a merged clip region needs to be created, the logical AND of both. This is a complicated action which normally runs well in basegfx polyPolygons, but still has some numerical problems sometimes.
In https://issues.apache.org/ooo/show_bug.cgi?id=125300 I already did some optimizations for the clipping - for the same reason. It shows that this task (and the involved chrome.svg example) have the same reason. In issue 125300 I solved this in the MetafileRenderer, but the better solution is to solve it in the clipping code in basegfx itself. The first (not too expensive) step ist to detect special cases if one of the polyPolygons involved is indeed a rectangle. If so, a much simpler, cheaper and numerically more stable path can be taken. Even simpler if both are rectangles.
Grepping, added code to basegfx, removing code from issue 125300 and doing some tests...

Works as expected, issue 125300 still fixed. Also the chrome.svg example converts to metafile seamingless.
This 1st optimization is valid and even a speedup. It does not solve the numerical problem when the polyPolygons would not be clipped against a range but another polyPolygon, this would require a 2nd step and much more work. It looks as if exactly that numerically critical cases are the ones that use reanges a lot. This can be explained by realizing that the 2nd clip *is* a rectangular gradient clipped against the form to-be filled. These cases lead to ranges and polyPolygons with the same bound regions - which may lead to these problems. It would still be good to evtl. add a task for this 2nd step.
To do so it should be possible to form a pair of SVG polygons - one the SVG range itself but as path element and one the upper right red element and clip these against each other.
Preparing commit of current solution...

"alg" committed SVN revision 1615952 into trunk:
i125349 moved clip enhancements to base clipping functionality

Comitted, done.

"alg" committed SVN revision 1616154 into trunk:
i125349 refined to exclude possible recursive calls

Saw when reading the code again that a recursion was possible since clipping against range may call clipping against polyPolygon again when outside content is requested, secured that with the last commit. Did not happen (not sure if bInside=false is used, I remember I tested it when developing it), but you never know...

Created attachment 83797 [details]
example for the issue

Example document with the recommended svg-files for this issue.

Created attachment 83798 [details]
created pdf-file from the example document

Creating/Printing to PDF destroys the SVG as converting to metafile.
Created with AOO 4.1.1 RC1.

Created attachment 83983 [details]
example for the issue with AOO 4.2.0 Linux64

Example document with the recommended svg-files for this issue.
Break => changes the 2nd and 3rd figure
to Metafile (also PDF export) =>  changes the third figure

Created attachment 83984 [details]
created pdf-file from the example document with AOO 4.2.0 Linux64

Creating/Printing to PDF destroys the SVG as converting to metafile.
Created with
AOO420m1(Build:9800)  -  Rev. 1626099
2014-09-22_04:09:16 - Rev. 1626666