Apache OpenOffice (AOO) Bugzilla – Issue 19593
in draw: intersect/subtract of shapes does not work as expected
Last modified: 2008-02-01 10:30:58 UTC
in the OOdraw application: As I understand it the intersect feature in Modify>Shapes>intersection when used on two shapes (both were selected with the shift-key) does only leave the area the two shapes have in common (Boolean AND). This works fine and as expected - for two shapes! But - if a rectangular shape is overlayed over a rectangular bitmap (i.e. a jpg), then the area of the bitmap is _resized_. When the shape is a circle though, then this works as expected. In Staroffice User Guide Chapter 6 "Creating Drawings With StarOffice Draw" on Page 349, there is the statement: "The selected polygons are joined into one single polygon that corresponds to the intersection area (Boolean AND) [!]. Only the area where all polygons overlap remains. You can also choose Shapes - Subtract and Shapes - Intersect to cut parts out of a bitmap, for example. [!] The illustration shows examples." It does not say anything about resizing there, actually the fact that it resizes makes it pretty much useless to crop an image, and it does not "cut out parts of a bitmap" either, but only resizes it to the size of the shared area of bitmap and shape. To reproduce: 1)select a rectangular bitmap 2)draw a rectangular shape over it 3)choose Modify>Shapes>intersect --> the underlying bitmap is _resized_ not croped Also try to: 1)select a rectangular bitmap 2)draw a rectangular shape over it, so that the upper half of the bitmap is completely covered 3)try to Modify>shapes>subtract --> the underlying bitmap is _resized_ not croped The Problem is (I guess): The bitmap is seen by draw as a rectangular shape with the filling of Bitmap:chosen bitmap from file. So what it does when intersecting is: intersect the shapes of the two selceted shapes. And then apply again apply the bitmap as filling to the remaining shape. But the desired behaviour (to crop, cut... images, shapes, gradients, hatchings) would be to intersect the two shapes and also intersect the content (area: be it a bitmap or gradient or hatching). I think croping and cutting images is quite basic behaviour, but as I don't know if you also think it is, I am going to leave it as it is: Priority 3.
This can be reproduced. But as far as I know this feature is only for intersecting polygons, not for cropping bitmaps. Nevertheless I reassign it to Armin for fixing or for a comment.
Reassigned to Armin.
AW: This behaves like intended. What gets computed is not a bitmap, but a rectangular shape with bitmap filling. The resulting shape gets the same filling attributes again, in this case the bitmap filling. If the bitmap filling is set to scale the bitmap into the shape (the default), then exactly that will happen. For cropping a bitmap please use the cropping functionality of the bitmap (see dialog for that).
Well, that's a shame. I rather liked the feature for cropping, and actually that is what is intuitive. And as I posted it on users@openoffice I also think it is for others. In addition: from the user manual: "You can also choose Shapes - Subtract and Shapes - Intersect to cut parts out of a bitmap, for example. [!]" It can _not_ be used to cut out parts. Because what you actually get is not a part of the bitmap but: "a shape resembling the intersection of shape and bitmap, into which is placed the resized original image" But then it is useless for bitmaps and the User Manual is wrong. In addition it is counter-intuitive. The cropping feature you mention is not good (for me), because one cannot visually select the area to crop. I need the Gimp for a simple task as this. As well as I thought that the use of any shape for cropping _rocks_ and is a fantastic feature compared to other office products. Let's have a look at what you can do with this feature: I understand from your statement, that the intersect feature is only intended to generate fancy shapes by intersecting, no matter what it's content. What you could do with this feature: What you would gain by also including it's content into the shapes>... functionality is: -Croping -selecting, -cutting of parts of bitmaps in a -intuitive and user friendly way without _loosing_ any functionality. In fact if the original behavior is wanted one can always reapply the bitmap filling to the shape. The whole functionality is there only not in a IMHO useful way! I understand that this cannot be done for OO 1.1 or maybe even OO 1.1.1 as this is a rather big feature request. But you should consider that the way this works now, is very counter intuitive (even the staroffice manual get's it wrong) and that you would loose nothing by changing the behaviour to include the content of a shape. You would however gain IMHO a fantastic functionality, which helps a lot - for any imaging task you wish to use OO for. b.
AW: Well, i am sorry to disappoint You, but indeed the handbook is mis-leading here. What is meant is that You can create PolyPolygons and add e.g. 'holes' top shapes with polygon fill style. Only when You change the size of the shape (this means: one of it's outmost and thus defining limits) the looking of fillstyle bitmap will change. I call it fillstyle bitmap here by purpose, because you actually cannot select a 'bitmap' as You describe in the steps (1). You are correct that this would be a intuitive cropping feature, but there are some points to keep in mind: (1) It would be an exception to handle intersect/substract different for shapes with fill style bitmap (How to behave for tiled botmaps here?) (2) When used for cropping, the cropped parts would be lost. This is not the case for the cropping with the dialog and not usually what You want for cropping (3) Together with not changing the bounds of the object this all just falls back to the single case where You have a rectangular shape with a fillstyle bitmap (no tiling) and want to cut it with another rectangular shape -> This is exactly cropping. (4) How to geometrically intersect/substract shapes with fillstyle bitmap in the future (-> _loosing_ functionality). Thus, i would much more suggest to enforce the cropping feature, it may use something 'intuitive', too. But it would be an error to 'misuse' the intersect/substract feature for geometries for cropping. So if You want that please write a feature request for enchancing the cropping, maybe add an interactive mode for it. This would be a good idea anyways. In it's form ATM it's not too intuitive.
I guess we misunderstand each other: >(1) It would be an exception to handle intersect/substract different >for shapes with fill style bitmap (How to behave for tiled botmaps here?) >(2) When used for cropping, the cropped parts would be lost. This is >not the case for the cropping with the dialog and not usually what You >want for cropping That is what Gimp and Photoshop do when they say 'cropping' >(3) Together with not changing the bounds of the object this all just >falls back to the single case where You have a rectangular shape with >a fillstyle bitmap (no tiling) and want to cut it with another >rectangular shape -> This is exactly cropping. No, the problem is with point c). Why is the bitmap resized? There is no need for it to be of the _same_ size as the Shape. The Bitmap and the Shape could be coupled _relative_. I may be wrong, but this is how it looks to me: When a shape is applied to a bitmap/hatching/gradient (b/g/h) then the shape serves as a _view_ or window to it's underlying content. I imagine a window (Shape) in that looks into a living room (Content=b/g/h). With OO as it is now I am forced to have the borders of the window the same size as the living room. But there is no need for that. I could as well have a window that only shows one quarter of the living room. That is _not_ possible when the underlying bitmap _must_ be of the same size as the shape. Another point: This is not only counter-intuitive for bitmaps but also for any b/g/h. I.e. when I select a gradient of type "radial yellow" and try to "intersect out" it's upper left quarter so that I get another gradient which has its center in the lower right corner --> It cannot be done, the gradient _must_ have the same size as the resulting shape This all results from the fact that the content _must_ have the same size as the shape/view. That is IMHO wrong. The result is, that this is not possible: ########## #_____ C # #| S | # #| | # #----- # # # # # # # # # # # # # ########## S=Shape, C=Content Only: ####### #-----# #| S |# #| C |# #-----# ####### S=C This applies to _any_ shape not only to rectangles. The Shape _must_ be the same size as the content right now. It also applies to any shape operation as stated above with the gradient. The intersect/subtract feature simply do not work as expected. If it was allowed to have S and C with different sizes (as if they were grouped toghether) then the cropping feature as well as all other Shape>... functionality would work as expected. _Without_ the problems you mention in point (1) and (2), nothing would be lost, but much gained. >(4) How to geometrically intersect/substract shapes with fillstyle >bitmap in the future (-> _loosing_ functionality). > >Thus, i would much more suggest to enforce the cropping feature, it >may use something 'intuitive', too. But it would be an error to >'misuse' the intersect/substract feature for geometries for cropping. > No, I think to decouple the size of the view/shape from the content (bitmap/hatching/gradient) is the solution. Which will yield much better results than to reinvent the weel, when you already have such excellent features as Modify>Shapes>.... >So if You want that please write a feature request for enchancing the >cropping, maybe add an interactive mode for it. This would be a good >idea anyways. In it's form ATM it's not too intuitive. As I don't want that I will reopen this issue as a request for enhancement. I hope that I do not enerve you too much. But I simply love the functionality that comes with the shapes and the fact that you can transform _anything_ into a shape. To me it is like the selections in Gimp/Photoshop - the common currency. You can do wonderful things with that and it would be a waste to leave it as it is now. It is so counter-intuitive that even the Staroffice Manual got it wrong - or better got it right, because that is how it should be! The only thing that is neccessary is to decouple shape-size and content-size... b.
I mention a point (c) but have cut it's explanation out of my submission: here is what I mean: When Modify>Shape>intersect is applied to a bitmap then what happens is this: a) Bitmap is converted to "shape with filling bitmap" b) The Shape and the "shape with filling bitmap" are intersected c) the size of the underlying bitmap is resized to macht this intersection <-- this is the flaw of the whole thing. Decouple the content-size and shape size. Like when grouping two objects togheter: It would be a design-flaw to make them the same size, their sizes are coupled but not identical! They are allowed to have a different size. The same way should content (bitmap/hatching/gradient) and view (shape to intersect/add/subtract) be handled. This is IMHO a flaw in the Modify>Shapes>... functionality and therefore is seen as misleading by the Staroffice Manual itself.
>I guess we misunderstand each other: I do not think so. I understand what You want to have, but i have to tell You about the realities in the existing office, not about possibilities or what might be nice to have. A basic change in handling like You suggest is a base for dicussion, but not a 'enchancement'. Such a change would require 2-3 Years of work. >As I don't want that I will reopen this issue as a request for >enhancement. Please think about that again. An enchancement for e.g. interactive cropping support will have a chance to be handled in forseeable time. What YOu are talking here is simply too big and would require a application-rewrite. >That is what Gimp and Photoshop do when they say 'cropping' These applications are bitmap-based, and no vector-graphic programs. In Vector-graphic programs the basic operations are defined on geometries. >When Modify>Shape>intersect is applied to a bitmap then what happens >is this: I will comment on that. Keep in mind: This is what is implemented today, not what would be an ideal world/possible. >a) Bitmap is converted to "shape with filling bitmap" This does not happen at Modify>Shape>intersect but always when You create/instert a bitmap. There exists no 'bitmap', but always a shape with geometry with fillstyle bitmap. That's the view of vector graphics. >b) The Shape and the "shape with filling bitmap" are intersected Right. >c) the size of the underlying bitmap is resized to macht this >intersection <-- this is the flaw of the whole thing. No. The resize is just a visual effect. Internally, the bitmap is unchanged. But the fillstyle is 'bitmap' and the mode is 'stretch to shape'. Thus, the bitmap as fillstyle is displayed as defined. At this point Your imagination of defining a transformation between fillstyle and shape is imaginable, interpreting the shape geometry as 'clipping' of the fillstyle. But how will then the fillstyle size be defined? Which size will be manipulative using the handles? The shape or the fillstyle? Which one will define the object size? Would You double the number of handles to allow interactive work with both? I hope You see that this would be a major change in handling. >Decouple the content-size and shape size. See above. Thus, it's relatively simple: An enchancement requiest for e.g. interactive cropping would have more chances to be realized then the complete paradigm change You describe. BTW: There was once a pixel application coming with StarOffice which was used for cropping, too. That allowed interactive cropping in a cropping mode (that's what pixel applications do, a mode for it -> Gimp, Photoshop). I was not opting for removing it, but it was. The argument was that te internal pixel tool cannot have the same power as a specialized tool like Gimp, so lets remove and let the people use Gimp.
I have stolen much too much from you already, but it was kind of you discussing this with me and it has helped me find out 2), which might benefit OO too. I will leave this issue as resolved - because I believe you, that it would need a major rewrite to implement my suggestions into OO. Nevertheless: 1) I have a question for you at the bottom, and I wanted to know if you think it's worth filing a request for a feature for (what I call) "View" or if it might indeed need a rewrite of too much of OOdraw) 2) I have (as you suggested) filed an issue about improved cropping, exept that I included cropping of _any_ shape from _any_ shape as I want it here. I also included a step-by-step how-to do this with using _only_ OOdraws given features (you might want to look at it, I think it's worthwile) http://www.openoffice.org/issues/show_bug.cgi?id=19665 I would also very muc like your comments about it. Since the idea was from the discussion with you. Because you have so kindly answered my questions for such a long time: I will try to visually explain why I thought that the Modify>Shapes>... functionality works for shapes (meaning 'outline') but _not_ when the shape is filled with content of _any_ kind. I am going to make an example in an attempt to visually show you, that the problems you mention do not apply, and to show that the current implementation is flawed (contra-intuitive at least) for any _content_ in a shape, but not it's outline. 1) Draw a rectangle (r1) 2) fill it with gradient of type "radial yellow". The brightest point of the shape is at X (see below) 3) Draw a second rectangle r2 which overlaps Rectangle1 (r1) in it's upper left quarter 4) select Modify>Shape>intersect --> I dare say, that the expectation of 99% of the people will be that the result is a rectangle with a gradient that has it's brightest spot in it's lower right corner! But it isn't! #########----------- # r1 # | # # | # # | ######### X | | | | r2 | | | -------------------- That's why I think the shape>... features are flawed - when it comes to content. Now to your problems. (Remember I believe you, that this needs a major rewrite of OO, so this is utterly hypothetical, and even though I still believe this belongs to the shape functionality and nowhere else - I am going not to bother you again - I just try to show you what IMHO would be correct from a (my) users point of view) In my example above: redo steps 1 to 3 without the intersection in step 4. _group_ them toghether instead. Let me call this step 4a as it is applied instead of an intersection. Only _imagine_ r1 being the _view_/intersection onto the content of r2, aka r2 is hidden exept for the area it share with r1. (that's how I think intersection should work) >Which size will be manipulative using the handles? The shape or the >fillstyle? When two objects are grouped (or as I suggest: intersected) then their size becomes coupled but not identical, when the grouped (intersected) image is resized - both shapes will be resized relatively to each other. That means: _at_ the point of grouping/"applying intersection" the two sizes will be coupled. >Which one will define the object size? This is a difference in the grouping comparison: not the sum of the sizes of the two shapes but (of course) r1 = the intersection part will define the object size and have the according handles. But even with the size of both it will be an improvement to how it is now. >Would You double the >number of handles to allow interactive work with both? No, once they are grouped/intersected they become what they are: a view and a content. To have the functionality that OO shows currently one has to reapply the filling of gradient "radial yellow" otherwise this would be it. (Of course interactive work aka in the grouping feature would be wonderful, in fact this is an idea! See below) >I hope You see >that this would be a major change in handling. In handling it would be similar to grouped shapes. Or in short about _all_ the problems you mention: these apply also to the "group" feature, but are solved quite well there. --------------- Just a parting question, to which I would like to have your opinion: if YOU think it is a worthwile feature then tell me and I will file a request for enhancement: Imagine a feature: Called: "View" with the following functionality: If 'view' is applied to two shapes r1 and r2 then they become grouped toghether and only the area of the upper shape (r1) shows the content of the shape below (r2) This would serve as a crop, without any of the problems you mention at all. (The handles of the resulting group may be of the size of the grouped images or of the size of the view [better]. And as any other group they are moved toghether/ resized toghether.... and maybe also edited as a group???[That would be the non-plus-ultra])
of course I again have messed up something: the names of r1 and r2 have to be swapped in the drawing.
Closing these older resolved issues. Cheers.
*** Issue 85780 has been marked as a duplicate of this issue. ***