Issue 19933

Summary: Crop like with selections in Gimp/Photoshop - add a new feature to grouping
Product: Draw Reporter: firmail <firmail>
Component: codeAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: issues, mfedyk
Version: OOo 1.1 RC4   
Target Milestone: ---   
Hardware: All   
OS: Linux, all   
Issue Type: FEATURE Latest Confirmation in: ---
Developer Difficulty: ---

Description firmail 2003-09-23 11:21:14 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.
Comment 1 wolframgarten 2003-09-23 11:24:01 UTC
Reassigned to Bettina.
Comment 2 mfedyk 2004-11-23 07:46:03 UTC
*** Issue 19933 has been confirmed by votes. ***
Comment 3 maxwolf 2007-05-17 16:50:58 UTC
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
Comment 4 bettina.haberer 2010-05-21 14:58:01 UTC
To grep the issues easier via "requirements" I put the issues currently lying on
my owner to the owner "requirements".