GNOME Bugzilla – Bug 562619
[WIN32] Print positioning does not work in GIMP 2.6.3
Last modified: 2018-05-02 14:38:23 UTC
Please describe the problem: While resolution to 522911 allows printing, and print scaling works properly in GIMP 2.6.3, all information is printed to the upper left had corner of the page, independent of the left/right and top/bottom position settings. The screen image appears correctly in the Preview Panel, but does not output correctly to the print device, be it a physical printer or a virtual printer such as Adobe PDF. Confirmed with Windows XP SP3 Build 2600, using HP OfficeJet 7200 and with Adobe PDF printer. Confirmed proper operation with other applications (e.g. Photoshop). Steps to reproduce: 1. In GIMP 2.6.3 load or create an image. 2. Select File > Print, and select the Image Settings tab 3. Scale the image to a size smaller than full width and height of the page. 4. Change position so that the image is not at the upper left margin of the page. 5. Select Print Actual results: 1. Image is properly positioned in the Preview page. 2. Resulting output is positioned to the upper left of the physical (or virtual) media. Expected results: Image is printed at the same position as shown in the Preview panel. Does this happen every time? Yes. Other information: Ref. previous bug report 522911 which (almost) fixed printing in Windows.
I can confirm that this bug is also in latest WIN32 build from CVS(r28070). And no matter what printer is used. I've also tried latest stable 2.6.5 x86 and x64 windows versions on XP x64 with the same result.
I can confirm this in the latest stable 2.6.6 windows version
I also see this, using GIMP 2.6.8 on Windows Vista using an Epson Stylus SX100 and Canon Pixma iP1200. The Position options in File > Print > Image Settings do have some effect, but not the correct effect. Changing the offset by 50 only moves the image on the printed page by about 10mm, even though the effect in the preview appears correct. I would have thought priority and severity of this should be higher than "Normal"?
I just updated to GIMP 2.6.10 and this still happens.
Lada (comment #1): how did you manage to get GIMP (or GTK+, for that matter) from CVS in 2009? mbourne: The priority and severity fields are not really used in this bugzilla. Until printing problems in GTK+ on Windows are fixed (if they ever are), just use some other application to print your images than GIMP. Saving an image, opening it in another application shouldn't take longer than five seconds.
*** Bug 639317 has been marked as a duplicate of this bug. ***
Lada, mbourne: Is this still a problem for you in a recent version? If so, which GIMP, gtk+ and Microsoft Windows versions do you use nowadays, and which application to print from? Note that testing with a recent GIMP (2.7.x instead of 2.6.x) is welcome...
NEEDINFO as per my last question. Lada and mbourne, could you please answer the last comment if you find time?
Apologies for the delay replying; I've been rather busy the last few weeks. I'm still using GIMP 2.6.10 on Windows Vista at the moment, but will update to a 2.7.x release and test when I get a chance - hopefully next weekend.
Hello André, I can confirm that in 2.7.4 this error still persist. Scale of image is working but position of image do not accept settings from page preview where is displayed right.
Tor: I get rev.28070 from there: http://sourceforge.net/projects/gimp-win/files/
I just tried GIMP 2.7.4 on Windows 2000 Pro, but it doesn't start properly. Has support for Windows 2000 been intentionally dropped, or should this be filed as a bug? Errors on startup are: 1. "The procedure entry point GetModuleHandleExA could not be located in the dynamic link library KERNEL32.dll" (while the splash screen shows "Looking for data files - Modules") 2. "The procedure entry point getaddrinfo could not be located in the dynamic link library WS2_32.dll" (while the splash screen shows "Querying new Plug-ins - script-fu.exe") MSDN indicates these functions are not present on Windows 2000. The UI is displayed, but is unresponsive - the windows can't be moved, and don't even redraw after they've been covered. About to try on Windows Vista. (I'm not too fussed about Windows 2000 support - just happen to have an otherwise unused licence so use it on a virtual machine to avoid cluttering the main Vista install up too much.) Will also see if it's reproducible with PDFCreator as the printer, as that may make testing easier.
Now on Windows Vista, 32-bit Business edition. GIMP 2.7.4 runs, but print positioning still doesn't work correctly. In addition, the Print plug-in crashes when trying to specify centred printing - details below. Setup ----- Install GIMP 2.7.4 using gimp-2.7.4-setup.exe from http://sourceforge.net/projects/gimp-win/files/ Install PDFCreator 1.2.3 from http://www.pdfforge.org/ Start GIMP Set background colour to black File > New - Width: 20mm (rounds to 20.11) - Height: 20mm (rounds to 20.11) - X resolution: 72.000 - Y resolution: 72.000 - Color space: RGB color - Fill with: Background color File > Page Setup - Size: A4 210 x 297 mm - Source: Sheet - Orientation: Portrait - All Margins: 6.35 mm Test 1 - Print at top left -------------------------- File > Print - Select Printer: PDFCreator - Image Settings tab: - Width, Height, X & Y resolutions as above - Position Left: 0.00 Right: automatically set to 177.19 - Position Top: 0.00 Bottom: automatically set to 264.19 - Center: None - Ignore Page Margins - Click Print When PDFCreator window appears: - Click Save - Specify folder & file name Open the PDF file - The black square is in the top left corner as expected Test 2 - Manually set centred offsets ------------------------------------- Back in GIMP... File > Print - Select Printer: PDFCreator - Image Settings tab: - Width, Height, X & Y resolutions as above - Position Left: 94.95 Right: automatically set to 94.94 - Position Top: 138.45 Bottom: automatically set to 138.44 - Center: None - Ignore Page Margins - Click Print When PDFCreator window appears: - Click Save - Specify folder & file name Open the PDF file - The black square is slightly away from the top left corner, but nowhere near the centre of the page where it should be. Test 3 - Automatically set centred offsets ------------------------------------------ Back in GIMP... File > Print - Select Printer: PDFCreator - Image Settings tab: - Width, Height, X & Y resolutions as above - Center: Both - Position Left: automatically set to 94.95 Right: automatically set to 94.95 - Position Top: automatically set to 138.45 Bottom: automatically set to 138.45 - Ignore Page Margins - Click Print Windows displays an error: "GNU Image Manipulation Program Plug-In has stopped working Problem signature: Problem Event Name: APPCRASH Application Name: print.exe Application Version: 2.7.4.0 Application Timestamp: 4ee92c53 Fault Module Name: libgtk-win32-2.0-0.dll Fault Module Version: 2.24.9.0 Fault Module Timestamp: 4eeca880 Exception Code: c0000005 Exception Offset: 001d87db OS Version: 6.0.6002.2.2.0.256.6 Locale ID: 2057 Additional Information 1: 50d1 Additional Information 2: 0239e205757b6336adef9d7815ae8399 Additional Information 3: 5e73 Additional Information 4: 785e9560b70f878375f3fdac857b8ee5 GIMP continues running (which is quite nice!), but nothing is printed. Note that the left and top positions set by selecting "Center: Both" are the same as manually specified in Test 2, but the automatically set right and bottom positions are 0.01 higher. Perhaps there's some sort of rounding error somewhere in this case, leading to the crash as the dimensions don't all add up correctly?
Created attachment 206552 [details] Results of "Test 1" in comment 13 (Print at top left)
Created attachment 206553 [details] Results of "Test 2" in comment 13 (Manually set centred offsets)
The crash in "Test 3" in comment 13 does not occur in GIMP 2.6.10. I've raised a new bug #669141 for that issue.
*** Bug 677581 has been marked as a duplicate of this bug. ***
I opened a duplicate – Bug 677581 – ; I probably checked too fast before opening. Bug still here in Gimp 2.8.0, reproduced under Windows (Vista) but working well under Linux/Gnome. Julien
I wonder which GTK version GIMP 2.8 uses...
For Windows 32 version Gimp 2.8 install this file: libgtk-win32-2.0-0.dll: * Product version 2.24.10 * File version 2.24.10.0 I also found this DLL but I assume it's not relevant: libgtk-pixbuf-2.0-0.dll: * Product version 2.24.1 * File version 2.24.1.0 Julien
Is this a duplicate of bug #491230 (see comment 10 there)?
I'd agree it does look related. The screenshots attached to bug #491230 seem to be describing problems with the UI though, so not sure if there's a risk of that one being closed for the UI issues are fixed, missing the print positioning issue?
Does that still happen with GTK 2.24 or a recent GTK 3 version?
Windows Vista GIMP 2.8.10 GTK 2.24.18.0 as far as I can tell (that's the version shown in the file propertied for libgtk-win32-2.0-0.dll) Repeated tests as per Comment 13. Test 1: Position set to top left: Same result - image is correctly positioned at top left of the page. Test 2: Position manually set to centre co-ordinates: Same result - Image is slightly away from top left, but nowhere near centre. Test 3: Select Centre: Both option: No crash, but the position is the same as Test 2, i.e. Image is slightly away from top left, but nowhere near centre. I'll install and test against GIMP 2.8.14 when I get a chance.
*** Bug 659740 has been marked as a duplicate of this bug. ***
Also: One detail I found in #659470 is an apparent 10:1 ratio between the offsets specified in the Print dialog and the actual offset measured on the printed rsult. So the offset values do have a consistent effect, but they seem to be out of scale.
It's still a problem with GNOME 2.8.18 and Windows Vista. I tested it on a friend's computer. Is more information needed? If so, just tell me what infos you are looking for. Also it seems to me that https://bugzilla.gnome.org/show_bug.cgi?id=491230 describes the same problem
I think #491230 may actually describe several things -- problems with properly fetching the paper size settings, the UI not redrawing (both of them since fixed), and the failure of the print offset to work correctly (still not fixed). The other day I took a casual glance at the GIMP code (via GitHub repository) and while I'm not able to offer any in-depth analysis, the problem seems to be isolated to gimp/print-draw-page.c line 62, i.e. cairo_translate(). Every other cairo call used in printing produces the intended and correct result, so either it's a problem with the passed parameters or with whatever the cairo transformation matrix is at that time.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
I can confirm this bug is definitely still present (tested: GIMP 2.8.22, bundled with GTK 2.24.28.0, on 64-bit Windows 10). The important details to know: - There is a significant (10:1?) ratio between the Print Offsets input in GIMP's Print dialog and the actual offset on paper; e.g. if the printer margin is 0.25" and I specify an offset of 2.5", there will be a 0.5" offset on the actual paper (or 0.25" if Ignore Page Margins is set). - Centering options work correctly, in the sense that they calculate correct offsets from the desired print size versus paper size. It's the offsets themselves that are coming out wrong. - This can be worked around by manually padding the image canvas with the desired offset (the image nonetheless prints at the correct size specified). - Personally I suspect this actually is a GIMP bug not GTK -- GIMP printing is handled via (gimp/plug-ins/print/print-draw-page.c) using libcairo and literally everything works except the offsets. (Ref: https://github.com/GNOME/gimp/blob/gimp-2-8/plug-ins/print/print-draw-page.c ) I would like to lend some help here (I don't print things often, but when I do...) but without an ability to compile and test GIMP from source, all I'm able to do so far is look at the source file (see above) and make guesses. (Maybe I can at least find us a lead...?)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/306.