Version: (using KDE KDE 3.1.1) Installed from: Compiled From Sources OS: Linux There are too few options for Printing images with kview (and kuickview also!). At least you should be able to control the print-size. Please take a look at the print dialog of the GIMP. You can even drag the image to the desired spot on the paper! Maybe it would be better to implement this is kprinter, so that other image viewers can also benefit, but I don't know if the application can tell kprinter that it is going to print an image and request extra options. Another step further would be to give multiple images to kprinter, allowing it to print multiple mini-images on the same page.
I guess this comes down to KIPI support in KView, which might be a bit overkill for such a basic image viewer..
This would be simple to add but... (tm) Currently something figures out what size to tell the PS driver what size to print based on the DPI of your screen. OTOH, maybe that (the DPI) is something that Qt knows and it isn't easy to change. IF I were you, I would make the request for KDEPrint. If it was possible to set the size there it would work for everything. This should work since the PS file isn't generated until after you click the "Print" button in the printing dialog box. So, I am moving this to KDEPrint.
When kprinter directly receives an image file for printing (JPEG, PNG, TIFF, GIF and some more supported by CUPS), like * "kprinter /path/to/image-file" command, or * by drag'n'drop an image onto kprinter then you can control the size of the paged printout: click "Properties", find "Image" tab, set up your stuff.... These print settings will then not be processed by kprinter itself, but be passed down to CUPS which can handle it quite well. If you print from an application like kview or kuickshow or kword or $whatnot, kprinter receives application-generated PostScript, and it is the business of the application to provide GUI controls to the user (the application is invited to host its controls on the kprinter dialog, like Kate, Konqueror, and quite a few other applications do. There is nothing KDEprint can do about this, if the print data comes from the application. The application needs to implement this. I'm wondering if I should close this bug report (there are plenty of other similar ones that address this wishlist item). I'm also wondering who assigned this to Matthias Kretz.
Most applications generate their own postscript, and most of these applications do not know how to do this properly. Maybe we should start filing bug reports with each individual application, and request to fix the implementation or leave it to kprinter?
'Maybe we should start filing bug reports with each individual application' Yes! :-) I've started to do this already (in general, not for this specific "image printing" problem): bug 139905 (KWord) bug 122147 (kpdf) And as you can see, even with some quick response/fix: http://bugs.kde.org/show_bug.cgi?id=139905#c2 Re. image printing: I mainly outlined it to you above to make you aware of your options right now. Also, we probably need to discuss with Cristian and Michael one idea coming from that; an idea that would need to a sort of "design decision": * KDEPrint could offer to applications (and their developers) which handle images that it also accepts all graphic formats CUPS is capable to handle as "raw" files (the most important being JPEG, PNG, TIFF, GIF, PNM -- for the more obscure ones look at http://www.easysw.com/printpro/specs.php) * KDEPrint would then apply the respective job options to the 'cupsdoprint' commandline and leave it to CUPS to handle the rest * the question remains: where to put the controls for these options? Should they be brought to the front of the main print dialog, where other apps can host their app-specific print controls? Just left on the "Image" tab? "Mirrored" from this tab to the app-specific front? Of course, this "raw graphics" print path would only work for CUPS, and it would be an *alternative* (not the main or only way) to the standard/common PostScript (future: PDF) one, but it may yield better results, and more control to the user in the short run. I think to *implement* this idea is pretty easy: for the application developers (Krita, Kuickshow, Digikam, ... ) as well as for KDEPrint. It is a well known set of "graphics printing options" that CUPS does understand right, and KDEPrint already supports all of them if kprinter gets raw graphic data. * The applications need just to know that it is legal for them to send raw graphics if they notify kprinter of the mime type... * ...and kprinter must be made to accept these file types as well. Probably *very* little new code. Then clean+polish. Done. One huge improvement. At least for those users who happen to print pictures and graphics not just twice a year. What do you think, Dik + all?
This is a duplicate of bug 77624 *** This bug has been marked as a duplicate of 77624 ***
Discussion is continued in Bug #77624
Closing old Resolved status bug.