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/02 15:36:33 UTC

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

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

          Issue ID: 125349
        Issue Type: DEFECT
           Summary: convert from svg to metafile drops element totally, if
                    point outside viewBox
           Product: Draw
           Version: 4.2.0-dev
          Hardware: PC
               URL: https://bugs.freedesktop.org/show_bug.cgi?id=71068
                OS: Windows 7
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: editing
          Assignee: issues@openoffice.apache.org
          Reporter: rb.henschel@t-online.de

Created attachment 83773
  --> https://issues.apache.org/ooo/attachment.cgi?id=83773&action=edit
three identical objects on different positions

This bug is related to https://bugs.freedesktop.org/show_bug.cgi?id=71068.

Insert the attached graphic into a Draw document. Convert it to metafile.
Notice, that the upper red area disappears.

The reason is a combination of filling with gradient and having a point outside
the viewBox.

In detail
the part
<path id="path55_out"
   d="m 100,47
    c -6,-20 5,-41 25,-47
      3,-2 7,-2 11,-2"
   style="fill:url(#path55_2_)" />

results in the absolute coordinates (in coordinate system of the viewBox)
100,7       start point
 94,27      1. control of bezier curve
105,6       2. control of bezier curve
125,0       end point = start of next bezier curve
128,-2      1. control of bezier curve
132,-2      2. control of bezier curve
139,-2      end point
In svg it need no to be closed for filling.
The endpoint is outside the viewBox.

The green part has the same curves, but starts at x=20 instead of x=100. The
endpoint is still outside the viewBox. But here the filling is no gradient but
a plain color.

The lower red part has the same curves, but starts at y=147 instead of y=47.
Now all points are inside the viewBox.

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

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

Posted by bu...@apache.org.
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.

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

Posted by bu...@apache.org.
https://issues.apache.org/ooo/show_bug.cgi?id=125349

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

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

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

Posted by bu...@apache.org.
https://issues.apache.org/ooo/show_bug.cgi?id=125349

mroe <mr...@gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #83798|0                           |1
        is obsolete|                            |

--- Comment #10 from mroe <mr...@gmx.net> ---
Created attachment 83984
  --> https://issues.apache.org/ooo/attachment.cgi?id=83984&action=edit
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

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

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

Posted by bu...@apache.org.
https://issues.apache.org/ooo/show_bug.cgi?id=125349

--- Comment #7 from mroe <mr...@gmx.net> ---
Created attachment 83797
  --> https://issues.apache.org/ooo/attachment.cgi?id=83797&action=edit
example for the issue

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

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

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

Posted by bu...@apache.org.
https://issues.apache.org/ooo/show_bug.cgi?id=125349

--- Comment #3 from SVN Robot <sv...@dev.null.org> ---
"alg" committed SVN revision 1615952 into trunk:
i125349 moved clip enhancements to base clipping functionality

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

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

Posted by bu...@apache.org.
https://issues.apache.org/ooo/show_bug.cgi?id=125349

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ACCEPTED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Armin Le Grand <Ar...@me.com> ---
Comitted, done.

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

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

Posted by bu...@apache.org.
https://issues.apache.org/ooo/show_bug.cgi?id=125349

--- Comment #5 from SVN Robot <sv...@dev.null.org> ---
"alg" committed SVN revision 1616154 into trunk:
i125349 refined to exclude possible recursive calls

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

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

Posted by bu...@apache.org.
https://issues.apache.org/ooo/show_bug.cgi?id=125349

mroe <mr...@gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #83797|0                           |1
        is obsolete|                            |

--- Comment #9 from mroe <mr...@gmx.net> ---
Created attachment 83983
  --> https://issues.apache.org/ooo/attachment.cgi?id=83983&action=edit
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

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

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

Posted by bu...@apache.org.
https://issues.apache.org/ooo/show_bug.cgi?id=125349

--- Comment #8 from mroe <mr...@gmx.net> ---
Created attachment 83798
  --> https://issues.apache.org/ooo/attachment.cgi?id=83798&action=edit
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.

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

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

Posted by bu...@apache.org.
https://issues.apache.org/ooo/show_bug.cgi?id=125349

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

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