Issue 118643 - Unexpected behaviour with Shapes → Intersect
Summary: Unexpected behaviour with Shapes → Intersect
Alias: None
Product: Draw
Classification: Application
Component: editing (show other issues)
Version: OOo 3.3
Hardware: All All
: P4 Major (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 128061 (view as issue list)
Depends on:
Reported: 2011-11-25 22:18 UTC by rgb
Modified: 2019-04-30 15:05 UTC (History)
4 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---

Compressed file containing an odg example and a pdf output. (116.22 KB, application/x-gzip)
2011-11-25 22:18 UTC, rgb
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description rgb 2011-11-25 22:18:05 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.
Comment 1 Armin Le Grand 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.
Comment 2 oooforum (fr) 2019-04-30 14:58:29 UTC
*** Issue 128061 has been marked as a duplicate of this issue. ***
Comment 3 oooforum (fr) 2019-04-30 15:05:34 UTC
(In reply to Armin Le Grand from comment #1)
> I suggest to make this task a feature request.