Apache OpenOffice (AOO) Bugzilla – Issue 19933
Crop like with selections in Gimp/Photoshop - add a new feature to grouping
Last modified: 2013-02-07 22:35:29 UTC
Hi, This request was born out of a bit of frustration about the handling of the Modify>Shapes>... features. I tried to cut pieces of bitmaps/shapes/gradients. Situation now: You can draw a shape and fill it with a bitmap/gradient/hatching, and show only part of it - but the bitmap/gradient/hatching is then _always_ scaled to the same size as the shape. The feature request is such: I would like to have the possiblility to show any part of bitmap/hatching/gradient independant of its size. The underlying bitmap/gradient/hatching should _not_ be forced to have the same size as the overlaying shape. Something along the lines like: Select two (or more shapes) and then select "Shapes>View" (or whatever you want to call the new feature) so that the shapes will be _grouped_ toghether and the area of the uppermost shape will be the window/view to the content below, the outside of this shape will be transparent and thus suppressing those parts of the underlying group members. Simply a mixture between the behaviour of filling of a shape (the area of the shape is the view onto the content, the rest is transparent) and grouping (allowing the members of the group an independant size, resizing them relatively to each other instead of making them the same size, entering and editing the group members) What would it do? -It would enable Draw to "crop" any shape out of any bitmap/gradient/hatching in the way this is expected. (See example below why this is not so now). - You could do the same things as with the selection tool in Gimp/photoshop plus more (entering the group, changing the overlaying shape later - because the original content still exists) What would it cost? -The grouping feature is already implemented. (It allows relative resizing of components and entering a group) -Shapes can have a bitmap/gradient/hatching filling already. (The area of the shape is the view to its underlying bitmap/gradient/hatching, the outside of the shape is transparent - hiding these parts of the bitmap/hatching/gradient) These two features could IMHO be combined. For a group to allow the _area_ of the uppermost shape to show it's underlying group members, and to make the outside of the shape transparent also for the group members below. Why not change the way the Modify>Shapes>... functionality works now? You could do it but in the discussions I had (see links below) it was pointed out that this is as the Shapes functionality is intended to work. Why not use the current crop feature? The current implementation is not visual, but when prepairing a presentation, or while drawing you often need to cut a screenshot/image visually and fast (that is not to fire up Gimp). It does only work for rectangles and it does only work for bitmaps. Why not improve the existing crop feature? Shapes a wonderful feature which would allow to use _any_ shape not just a rectangle. I personally would build on it instead of replicating the features. Shapes of any kind could be used to show underlying content (Text, circles...) It would behave like the selection tool in Gimp/Photoshop! Similar issues where discussed: http://www.openoffice.org/issues/show_bug.cgi?id=19665 and especcially (filed as a bug because I, some users from the mailing list and the staroffice manual thought the feature would work as the selection tool in Gimp/photoshop): http://www.openoffice.org/issues/show_bug.cgi?id=19593 An example of the problems with the current implementation in Modify>Shapes>...: 1) Draw a rectangle (r1) 2) fill it with a gradient of type "radial yellow". The brightest point of the shape is at X (see below) 3) Draw a second rectangle r2 which overlaps 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 what happens is that the gradient of r1 is resized to the size of r2 so that the brightest point is again in the center - they _must_ have the same size for some reason. It cannot be done. #########----------- # r2 # | # # | # # | ######### X | | | | r1 | | | -------------------- The same applies when instead a bitmap/hatching is used as filling. r2 is always resized to the same size as the r1. Now as in this example: imagine that at the point that we press Modify>Shapes>View (or whatever) instead of intersect the relative size of r2 and r1 become fixed (like they were grouped) and are now resized as if they were grouped? Then this whole feature would work as expected. I just think the two features: grouping and the exitsting 'View onto content' in the bitmap/hatching/gradient of shapes would make a great couple and enable us to use it similar to the selection too in Gimp/Photoshop - only better. Thank you for considering it.
Reassigned to Bettina.
*** Issue 19933 has been confirmed by votes. ***
hmm. it seems this issue has been open for a long time. So i'd like to vote for it, too. cropping is very frustrating in ooo at the moment. Another approach perhaps could be to improve the way that placing bitmaps on areas is handled. ATM it's just not possible to position a bitmap relative to the shape - instead, the bitmap will always be center-aligned. 1. import a jpeg. 2. place a rectangle on top of it 3. shapes->intersect 4. in the area options, uncheck the "autoFit" option. ... and now we're almost there. but from here it's impossible to move the origin of the bitmap fill to another position! it always aligns to the shape. basically, it would have been all well if after step 3 the texture coordinates of the fill would remain static. Is there any way to get a statement if someone is actively working on this issue? cheers from frankfurt max
To grep the issues easier via "requirements" I put the issues currently lying on my owner to the owner "requirements".