You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@openoffice.apache.org by bu...@apache.org on 2014/08/05 17:47:10 UTC

[Issue 125349] convert from svg to metafile drops element totally, if point outside viewBox

https://issues.apache.org/ooo/show_bug.cgi?id=125349

Armin Le Grand <Ar...@me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ACCEPTED
                 CC|                            |Armin.Le.Grand@me.com
           Assignee|issues@openoffice.apache.or |Armin.Le.Grand@me.com
                   |g                           |
     Ever confirmed|0                           |1

--- Comment #1 from Armin Le Grand <Ar...@me.com> ---
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...

-- 
You are receiving this mail because:
You are the assignee for the issue.
You are watching all issue changes.