Bug 68236 - EDITING: shapes - subtract -> deformation
Summary: EDITING: shapes - subtract -> deformation
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-18 03:39 UTC by troudelalmanach
Modified: 2014-08-18 19:56 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
file shows steps 1-4 and result (107.34 KB, application/vnd.oasis.opendocument.graphics)
2013-08-18 03:39 UTC, troudelalmanach
Details

Note You need to log in before you can comment on or make changes to this bug.
Description troudelalmanach 2013-08-18 03:39:40 UTC
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
Comment 1 Owen Genat (retired) 2013-11-30 04:34:01 UTC
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.
Comment 2 Cor Nouws 2014-08-13 11:20:54 UTC
Indeed already a problem in 3.3.0

The problem only occurs with rectangle shapes, AFAICS
Comment 3 Owen Genat (retired) 2014-08-18 14:17:34 UTC
(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.
Comment 4 Owen Genat (retired) 2014-08-18 14:22:33 UTC
(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.
Comment 5 Cor Nouws 2014-08-18 15:49:09 UTC
@owen: thanks for additional info!
Comment 6 Regina Henschel 2014-08-18 19:10:39 UTC
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.
Comment 7 Cor Nouws 2014-08-18 19:56:05 UTC
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