[Kde-print-devel] [Bug 77624] Wish: More advanced image printing capabilities

[Kurt Pfeifle]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=77624         




------- Additional Comments From pfeifle kde org  2007-01-13 16:52 -------
Dik,

re. your comment: I didn't say "allow *bitmaps*", but I enumerated the image formats supported by CUPS, or more specifically the two CUPS filters "imagetops" and "imagetoraster".  (I know this *implies*  bitmaps  :-)

     "I did not know that CUPS can print images directly. It sounds 
      like a great improvement over the current situation if applications 
      can just hand over a PNG file to CUPS."

Oh, CUPS can do that already since its beginning (more than 6 years ago). The drawback is, that it currently is using only RGB, not CMYK as input but that I'm not sure of, and need to ask. I only know that the pros all want CMYK and color management... but don't ask me why. Pros are weird...)  :-)

Right now, CUPS and the available PPDs have not yet built in full support for color profiles -- but this can be expected to be picked up soon (preparations for this are done). Once that is in place, it is probably the "lowest hanging fruit" for KDEPrint image printing to just support all the options CUPS gives to users on the commandline. And we already do for the most part...

Just start 

  kprinter /path/to/some/*.{jpg,png,tiff,gif,pnm,...}

ignore all the tabs and settings not applicaple to print single page images, concentrate on the "Image" tab of "Properties" and you know what I mean. You'll have the first approximation of the KDEPrint dialog for "raw image printing". Some of the adaptions to be made a probably "Junior Job" level, some more advanced ones (embedding a fast image viewer kpart for the preview that displays a (large) thumbnail of the real file are probably not too difficult either.

Heck, it would probably be feasible to add all the controls for the Gimp-Print/Gutenprint driver settings as well, and use the Gutenprint 5.0 driver to do the stuff they do so good. But that's more advanced stuff, and I don't know a lot about graphic formats, pixmaps, color management, ICC profiles, raster graphic conversion.... But for sure it will be a little "killer app" for all these fans of digikam, gwenview, kuickshow, kimdaba/kphotoalbum... out there wishing for better photo printing support.

The first step in any case would be to implement full support for all those features CUPS offers on its commandline. A really low hanging fruit! And something that lets CUPS probably produce better prints than what we get when we go thru the sub-par PostScript Level 1 conversion that Qt does offer us for images, right?

Only the *next* step would be to add the ability to actually manipulate the print file when kprinter has hold of it (I'm not even convinced if that is the best idea, but that is for other people to decide, not me), like you said: embedd DPI information, scale the image up/down, resample, change hue, saturation, brightness (the latter few for the *image*, not just the printout as can be done already) etc.

The complete current kprinter "infrastructure" is already there: talking with the CUPS server, sending jobs there with the correct commandline parameters, reading and displaying target printer PPD infos, retrieving PPD (=driver) infos from a remote CUPS server automatically without needing to locally install them, etc.

I's just that kprinter would probably get a "second skin" for raw image printing (or maybe spin off into a separate incarnation of itself, that may start to live a life of its own?). On the image app side, it's just a small provision to add another print button or menu entry that says "Send Printfile As Image" which would then call kprinter in its new fashionable disguise (and make sure they send image, not PostScript. [That would of course not exclude to still offe to print in the traditional way with "Send Printfile As Crappy PostScript Level 1"].

I should maybe mail these suggestions/ideas to the respective KDE image app mailing lists and a few other individuals I know, ask for input and maybe find a developer who is interested to help with this.

Dik, if you want, you can workout a draft for such a proposal, outlining all the basic ideas and compile a list of people we could jointly send this to. Maybe something good for KDE4 comes from this then...   :-)

Cheers, Kurt