Bug 62739

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.