GNOME Bugzilla – Bug 342548
gimp_drawable_transform_scale_default behavior is not to spec
Last modified: 2008-01-15 13:08:12 UTC
Please describe the problem: When using gimp_drawable_transform_scale_default to scale an object, the parameters specify that the "new" i.e. target top-left and bottom-right x,y coordinate pairs should be entered. However, the actual behavior is to scale to the right size but the location is mysterious. If only scaling is the intended behavior, then the function should simply take the new width & height, and not ask for coordinates. As it is, the behavior is highly non-intuitive. Steps to reproduce: working from script-fu 1. create a simple object (say a rectangle): (gimp-rect-select inImage 100 100 50 50 2 FALSE 0) (gimp-edit-bucket-fill inLayer 0 NORMAL 100 0 0 0 0) 2. float selection (set! floating-selection (car (gimp-selection-float inLayer 0 0))) 3. (gimp_drawable_transform_scale_default floating-selection 0 0 20 20 TRUE FALSE) Actual results: the selection is scaled but is moved not to the given coords but to ~ (40,40) topleft and (60,60) bottomright Expected results: the selection should be scaled AND move to the location specified by the x,y coord pairs given in the parameters, i.e. (0,0) topleft and (20,20) bottomright Does this happen every time? yes Other information: I thought I could work around this by using gimp-selection-translate, but it is not clear to me how much to offset. Help?
Could you perhaps attach a small example image and a script that shows the problem?
The location is not so mysterious: it is the original offsets of the drawable (relative to the image) scaled by the same amount as the drawable itself. You could correct for this by using "gimp-drawable-offset" after scaling but I would agree that the behavior is peculiar and should be investigated further.
Created attachment 66023 [details] test script to show behavior of gimp_drawable_transform_scale_default This small script creates a rectangle, then floats and scales it.
re saulgoode's comment: Thanks. Yes, I see that now. I was looking for some correlation to the coordintes entered as parameters. If this is the intended behavior and/or if it will be too hard to fix, then the procedure interface should be changed to reflect that.
This is indeed totally broken, all of the transform PDB wrappers don't care about the layer offset and produce wrong results if the layer is not at 0,0. This is so broken, it will be fixed in 2.2 too, even if it changes behavior of some scripts.
Fixed in both branches: 2006-05-23 Michael Natterer <mitch@gimp.org> * tools/pdbgen/pdb/drawable_transform.pdb * tools/pdbgen/pdb/transform_tools.pdb: add the drawable's offset to the x and y returned by gimp_drawable_mask_intersect() because all transform functions expect image coordinates. Fixes bug #342548. * app/pdb/drawable_transform_cmds.c * app/pdb/transform_tools_cmds.c: regenerated.
Wow, that was quick! I have never had a bug resolved so quickly in a commercial product. When / in what version will I be able to get the fix? Thank you!!
You're welcome :) The fix will be in 2.2.11 (stable) and 2.3.9 (unstable).
Um, in 2.2.12 of course.
Re comment #2: Workaround is to do "gimp-layer-set-offsets" after scaling. gimp-drawable-offset does not give the desired result.