GNOME Bugzilla – Bug 165168
Pasted object should appear on top of the original object
Last modified: 2008-01-15 12:46:20 UTC
Please describe the problem: A small object on a transparent layer cannot be copied with whole Steps to reproduce: 1. File -> New -> Advanced -> Filled with (transparency) -> OK - single transparent layer is created. 2. Select paintbrush (<P>). 3. Draw letter U with paintbrush in a top part of layer. 4. Select whole layer (<CTRL> + <A>). 5. Copy whole layer (<CTRL> + <C>). 6. Paste selected area (<CTRL> + <V>). Actual results: Second letter U just in a middle of layer (below first U) will be visible Expected results: To get U shape exactly in the same place where the first U is placed Does this happen every time? Yes Other information:
If I understood your description correctly, the problem is that you do not want the copied layer to be shrunk automatically. Currently, when you copy and paste a layer, the GIMP will automatically shrink it (removing the fully transparent areas). And since the GIMP creates the floating selection (with the pasted object) in the middle of your image, the pasted object is not aligned with the original one. I have changed the summary of this bug report so that it fits this description. This cannot be done in all cases (e.g., if the original object is not from the same image) but other programs try to position the copy on top of the original so it makes sense that some users expect the GIMP to behave in the same way. Some improvements to the floating selections are discussed in bug #113477. Other issues were previously discussed in bug #78732 and bug #142944.
The gimp also fails to paste the alpha. Remember, the selection was rectangular. It was not generated from the alpha. For that the gimp has a menu option: Layer -> Transparency -> Alpha to Selection (probably that should appear under the Select menu too) So Piotr's problem is solved simply by making his selection based on alpha. Pasting the full RGBA image does not work though, and it should. Trimming is also wrong, since it destroys data that may be valid.
IIRC it already discards the A=0 parts during the copy, and there is another bug about this, or a discussion on a mailing list, describing if it can easily by solved or if (and why not).
I think that we can mark this as a duplicate of bug #350897 (even if this one is older). The patch attached to that bug report will solve this one as well. *** This bug has been marked as a duplicate of 350897 ***