Apache OpenOffice (AOO) Bugzilla – Issue 118643
Unexpected behaviour with Shapes → Intersect
Last modified: 2019-04-30 15:05:34 UTC
Created attachment 77047 [details] 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.
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.
*** Issue 128061 has been marked as a duplicate of this issue. ***
(In reply to Armin Le Grand from comment #1) > I suggest to make this task a feature request. Done