GNOME Bugzilla – Bug 570353
first time open of .svg file ignores the requested units (points rather than pixels)
Last modified: 2009-07-20 21:07:54 UTC
Please describe the problem: wget http://home.att.net/~Tom.Horsley/dvdprint/perfect-120mm-white-template.svg gimp & File -> Open and select that .svg file just downloaded In units change pulldown menu from "px" to "pt", make sure width and height say 360 if they don't already. Change resolution from 90 (or whatever it says) to 300 pixels/inch Click OK You get an image that is 450 pixels x 450 pixels at 300 DPI. The units specified above should generate a 1500 x 1500 pixel image at 300 DPI. Close the incorrect image, and do File -> Open again following the exact same procedures again as specified above. This time, the dialog acts different. When you select units of "pt", the width and height change from 450 to 108, then you need to change them to 360. Also, for some reason, the x/y ratio values change from 1 : 1 to 3 1/3 : 3 1/3 Open the file again, and now you get 1500x1500 pixel image. Steps to reproduce: 1. see description 2. 3. Actual results: see description Expected results: I'd expect the 1500x1500 pixel image the 1st try Does this happen every time? Yep - on every first attempt to open the file after starting new gimp. Other information: This is the gimp-2.6.4-3.fc10.i386 from a fedora 10 system. The .svg file was produced with inkscape on the same system. (I don't think the specific .svg file matters, but figured I might as well point at the one where I noticed the problem).
I discovered that if I leave the units menu alone (defaults to pixels) and I tell it 1500 pixels, it does correctly open the .svg file. So it looks like something is wrong with changing the units.
This SVG file specifies width="450" height="450". This is to be interpreted as pixels. The resolution shown in the Import dialog only affects how we convert this pixel size to the unit you have chosen. From what I can see the dialog behaves correctly. If you want to open the SVG at 1500 pixels, then you need to enter this size as pixels or choose the ratios accordingly.
OK, but I don't understand. Why does the dialog even have the ability to select the units and type in the dimensions if it is going to ignore them and always use pixels? And why does it work differently when I close the image and open it the exact same way the 2nd time? I have tried telling it 1500 pixels, and it does work if I do that.
The dialog allows to specify the size in units as pretty much all dialogs in GIMP. Imagine you want to print that SVG 100mm wide at 300dpi. Then you are able to specify that size in the SVG import dialog.
But that was the point of my bug report, it doesn't work. If I tell it to use 360 points and 300 DPI, I don't get a 360 point and 300 DPI image (which would be 1500 pixels), instead I just get a 450 pixel image.
Yes, you have a point. There's something wrong. I doubt though that one of the developers will find time to look into this in more detail. So if this bothers you, then please send us a patch that fixes this. Thanks.
No unconfirmed bugs with milestones, please.
Created attachment 138692 [details] [review] Patch against 2.6.6 Here the problem is that the resolution used to convert the sizes between pixels and units is set initially and never updated. If you specify the sizes in units, whatever resolution you set, the sizes in pixels corresponds to the resolution was initially in place. The resolution that the user chooses only defines the final pixbuf physical dimensions and works fine only when the user specified these in pixels. The attached patch is against file 'plug-ins/commom/file-svg.c' of release 2.6.6.
Thanks. Committed to both branches: commit c78f7d1382ed1b717a7168a883f6ecb1455aa6bf Author: Massimo Valentini <sixtysix@inwind.it> Date: Mon Jul 20 23:04:41 2009 +0200 Bug 570353 – first time open of .svg file ignores the requested units The resolution used to convert the sizes between pixels and units was only set initially and never updated. plug-ins/common/file-svg.c | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-)