DO NOT REPLY [Bug 118643] New: Unexpected behaviour with Shapes → Intersect

[bu...@apache.org]

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

             Bug #: 118643
        Issue Type: DEFECT
           Summary: Unexpected behaviour with Shapes → Intersect
    Classification: Application
           Product: Drawing
           Version: OOo 3.3
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: P5
         Component: editing
        AssignedTo: graphicsneedsconfirm@openoffice.org
        ReportedBy: rgb.mldc@gmail.com
                CC: ooo-issues@incubator.apache.org


Created attachment 77047
  --> https://issues.apache.org/ooo/attachment.cgi?id=77047
Compressed file containing an odg example and a pdf output.

I'm aware that issue 10589 was closed as "worksforme", but the behaviour of
Shapes → Intersect depends too much on the initial conditions to be a reliable
tool: while it gives good results with small, non rescaled images, the results
could be terrible otherwise. 

Suppose you introduce a picture on a Draw document and then draw on top of it a
shape (a rectangle, an ellipse), if you select both and do Right click → Shapes
→ Intersect you will obtain the shape with the image as background. 

The expected result is the shape showing as background the part of the image
that it covered previously to the intersection. While this expectation is
fulfilled under certain circumstances (pictures that were not resized
and are smaller than the page) you'll obtain weird results on other situations,
like compressed, displaced or even distorted images.

See attached file for a more detailed explanation and for a simple example to
test the behaviour. The tar.gz file contains an odg file and the pdf generated
from that file.

-- 
Configure bugmail: https://issues.apache.org/ooo/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

DO NOT REPLY [Bug 118643] Unexpected behaviour with Shapes → Intersect

[bu...@apache.org]

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

Marcus <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P5                          |P4
             Status|UNCONFIRMED                 |NEW
           Platform|PC                          |All
     Ever Confirmed|0                           |1
         OS/Version|Linux                       |All

-- 
Configure bugmail: https://issues.apache.org/ooo/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

DO NOT REPLY [Bug 118643] Unexpected behaviour with Shapes → Intersect

[bu...@apache.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Armin.Le.Grand@me.com

--- Comment #1 from Armin Le Grand <Ar...@me.com> 2012-02-06 12:48:55 UTC ---
ALG: Intersection is a geometrical operation on two polygon shapes, so the
bitmap you try to work with gets converted to a polygon object (context menu,
convert to contour). These two polygon shapes then get intersected, leading to
the ellipse result.
The intersection always uses the fill/line style of the deepest object, in this
case the converted polygon with fill style bitmap. Thus, the result gets the
line/fill style copied from that, so the result ellipse will just get the fill
style of the deepest object. This is designed to work with any fill style, e.g.
color and/or others.
This function is not intended to cut portions out of a bitmap, though. It works
as intended, but you make a nice suggestion how this feature could be extended.
It would be necessary to cut bitmap contents to the result geometry. A big
caveat is that the result geometry could not only be smaller and inside the
source image (which will make clipping simple and logic), but also be much
bigger and empty (shapes merge). How should the bitmap meeded as a result be
extended?

I suggest to make this task a feature request.

-- 
Configure bugmail: https://issues.apache.org/ooo/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.