Created attachment 84187 [details] file shows steps 1-4 and result Problem description: When subtracting a shape bigger than the shape to cut, the cutted object will be deformed. Steps to reproduce: 1. import a picture 2. draw a shape (e.g. circle) with a diameter bigger than the objects height 3. move the new shape over the object so that the left upper and lower corners are covered (or any two boundary points) 4. right click: shapes - subtract Current behavior: The trimmed object is deformed (what can not be seen if the object does not contain a recognizable pattern). Expected behavior: The object gets trimmed without deformation. Operating System: Windows 7 Version: 4.0.4.2 release
Thanks for the good, clear example. I can confirm the behaviour described. Status set to NEW. Version set to v3.3.4 release as a result of the testing here, but probably Inherited From OOo. Platform set to All/All. I tested the behaviour under Crunchbang 11 x86_64 running: - v3.3.4.1 OOO330m19 Build:401 - v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a. In both cases the resultant graphic is of an altered aspect ratio (reduced to the area that was left uncovered) prior to any subtraction taking place.
Indeed already a problem in 3.3.0 The problem only occurs with rectangle shapes, AFAICS
(In reply to comment #2) > The problem only occurs with rectangle shapes, AFAICS And only when the rectangle overlays one entire side of the graphic. Overlaying only a corner or part of a side results in the expected subtraction.
(In reply to comment #3) > (In reply to comment #2) > > The problem only occurs with rectangle shapes, AFAICS > > And only when the rectangle overlays one entire side of the graphic. > Overlaying only a corner or part of a side results in the expected > subtraction. No. Actually, the same effect occurs for all basic shapes. It seems to depend on whether one side of the underlying image is fully or partially covered.
@owen: thanks for additional info!
This is the expected behavior, when one of the objects for merge/subtract/intersect is a picture. These operations first convert all marked objects to contour. (You can verify this when you look into the information in the undo list.) When such converting is done on a picture, then a polygon is build, with the picture as background. Then the two polygons are subtract. The resulting object gets the background of the deepest object, with is the picture in your example. During the "convert to contour" the background picture is set to "AutoFit". This kind is taken over by the resulting object. But because the resulting object has a different ratio, the picture is skewed. If you want only to show a rectangle part of the picture, then not subtract, but crop (in the picture properties) is the correct tool. An unregular cut-off needs some tricks and you should ask on forum or mailing list for that. I think, it is no bug.
Hi Regina, (In reply to comment #6) > This is the expected behavior, when one of the objects for > merge/subtract/intersect is a picture. These operations first convert all > marked objects to contour. (You can verify this when you look into the > information in the undo list.) When such converting is done on a picture, > then a polygon is build, with the picture as background. Then the two > polygons are subtract. The resulting object gets the background of the > deepest object, with is the picture in your example. Ah, valid explanation. Thanks! > During the "convert to contour" the background picture is set to "AutoFit". > This kind is taken over by the resulting object. But because the resulting > object has a different ratio, the picture is skewed. > > If you want only to show a rectangle part of the picture, then not subtract, > but crop (in the picture properties) is the correct tool. Yes. And the exporting via File menu Export (not via context menu Save Picture) indeed results in the cropped picture > An unregular cut-off needs some tricks and you should ask on forum or > mailing list for that. IMO not what we aim for. > I think, it is no bug. Me too. Again tanks for the explanation.. @troudelalmanach closing as NOTABUG. If you think it's still a bug, pls explain and reopen. Cheers Cor