Version: (using KDE KDE 3.2.0) Installed from: Compiled From Sources OS: Linux Image printing in KDE is currently quite limited. Generally, you can't set the size, orientation, position on the paper, colour correction, and so on. When a KDE application asks KDEPrint to print one or more images, KDEPrint should show a wizard that allows the user to arrange the image(s) on the paper (or multiple sheets of paper), choose colour print or black/white, adjust brightness & contast, and so on. Currently, all on this must be done by the application. For the sake of code duplication, KDEPrint should provide this functionality to all KDE applications. Maybe an idea for KDE 4?
Is this similar to bug 77691?
UNCONFIRMED (batch reassigning messed this)
*** Bug 77691 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
kooka (as others) already has some of the required functions. - size and dpi
*** Bug 117560 has been marked as a duplicate of this bug. ***
Don't forget scaling. A general write-in scaling option which defaults to 100% but has a radio button option "expand/shrink to fit page".
There are some additional use cases that have problems * using kooka to copy pages (related to resolved bug 63291) - margins and dpi still messes this up (some printers can print the whole area) * using gwenview to print an image to "photo with tear-off tab" - image was not rotated correctly, there should be no margins * using kword/kate/kwrite/... to print a draft for review - images in economy mode, possibly a row spacing of 1½. * using kdeveloper/kate/kwrite/... to print source code - two pages per sheet with head and foot [my preference] - - - There needs to be an easy way to affect several settings at once depending on what the user wants to do. And to save those for later use possibly from another program.
Although the print dialog of "The GIMP" is a usability nightmare (IMHO), it has some extremely cool features. For instance, it has a preview where you can see where the image will end up on the paper. You can even drag the image across the paper, and scale it. It would be a Good Thing if KDE will have something like this, so any KDE graphics application can 'inherit' this functionality.
You guy write here Bug 117560 and there Bug 37569 and maybe elsewhere the scaling should be done by the application. While trying print some PDF (page size a5) with kpdf via kdeprint I experience a nightmare... What I want: print 2 of those pages on 1 (a4) read on...
Created attachment 17700 [details] preview So I start trying to print 1 on 1, page size = a4
Created attachment 17701 [details] print result (1on1, a4) That's what I get. Strange, not what I was promised, thou unusable. Obviously the preview only showed the upper left corner of size a5.
Created attachment 17702 [details] preview (1on1,a5) So now I try to print one page on one, but change size to a5.
Created attachment 17703 [details] print result (1on1, a5) It was perfect what they promised, but the result.... (go and look yourself)
Created attachment 17704 [details] preview (2on1,a4) So now I try to print 2 pages on 1 (using the General Print settings), page size a4. Of course I'm aware that 2 on 1 will be done after by CUPS. The preview is still not nice to me.
Created attachment 17705 [details] print result (2on1, a4) But what I get seems much nicer. If only the pages would match the pager. Somehow it was shrinked to much.
Created attachment 17706 [details] preview (2on1,a5) So here we go with 2 on 1, a5. The preview looks so sweet, just do it like this (and let CUPS put 2 on 1). Perfect
Created attachment 17707 [details] print result (2on1, a5) Hmm. So CUPS intended, I would feed a5. %$#&}}!!!!
Created attachment 17708 [details] preview (2on1,a4,psnup) I still got an idea. I'll try it with psnup filter... Thou this preview looks really sad.
Created attachment 17709 [details] print result (2on1, a4,psnup) Surprise, surprise. My printer rocks. If kdeprinter shows me a crappy preview, the printer knows it much better how to do it. The only thing I'd like now: Please fit with the 2 pages. Don't scale down like this.
Created attachment 17710 [details] preview (1on1,a5,psnup) I only got this one possibility left. Please... (thou the preview doesn't look promising)
Hmm. You guessed right. Getting tired typing, shooting, printing. The preview above is meant to be... preview (2on1,a5,psnup)
Created attachment 17711 [details] print result (2on1, a5,psnup) No neither this helps. I'm lost!
So, what would work instead: - pdftops %in %out - psnup -2 -pa5 %in %out - print this one But what the heck does kdeprinter and all thouse glory filters inside that they only produce crap? This bug is really a newbie killer and should be fixed. Somehow... I guess my story shows that kdeprinting dialog doesn't honour all the page sizes for input, output and inbetween while doing conversion. There are many different parameters one might call page size: - input size of the "file to print" (i.e. pdf, though sometimes without specific size) - output size after postscript conversion - optionally: input size for some filter - optionally: output size after thouse filters - input size to CUPS ...... some of CUPS internals (or whatever printer server) ...... maybe some postscript printer capable resizing options - effective paper size you feed the printer Some of thouse got mixed up I guess. - If not I could somehow print 2 pages on 1 a5 sheet. I would also be glad if there would remain as less parameters as really needed. i.e. landscape/portrait autodetection if possible (i.e. for pdf and ps), input file page size auto detection if possible, ... more usability, ... My vision: It should just work (TM)
*** Bug 62739 has been marked as a duplicate of this bug. ***
Kurt Pfeifle suggested in Bug #62739 that it might be a very good idea to allow applications to provide bitmaps to KDEPrint in stead of Postscript files. So, some more thoughts about this that pop into my mind: 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. Two main reasons I see why this is a *very* good idea: * Most applications do a very bad job generating proper Postscript files. * Printing a 6 Megapixel image *should* be a breeze, but it seems that due to the conversion to Postscript format, the printing system needs to digest HUGE Postscript files that take very, very long to render, with Ghostscript consuming all system resources. Another issue (related to print size) that seems to be a problem in current KDEPrint is that applications have no idea about the image resolution required by the printer. Even if the printer is set to its lowest DPI setting, the application does not know this and sends a ultra-high resolution image anyways. Sometimes, I even get the impression that applications do not even know the maximum DPI setting of the printer they are sending the job to. The result is that the image data generated by the application is overkill for one printer, while another printer receives too little data to print the sharpest possible image. Please correct me if I am mistaken here! If applications are allowed to always send the entire image in, say, PNG format (never a big performance problem I think, even for a 16 Megapixel image) then KDEPrint can do the required upscaling / downscaling. When scaling down, KDEPrint could offer the user a choice between linear/bicubic/... scaling. When scaling up KDEPrint could even offer options to add a layer of barely visible correlated monochromatic noise to the image, which helps a lot in making the final print appear more detailed. These are things that will become possible (maybe in KDE 4.2 or so) when KDE 4 allows applications to provide a bitmap image file.
About the question where to put the options for the print job: I guess the possibility to provide bitmap data to KDEPrint will be used mainly by bitmap graphics applications. These applications generally do not care much about things like page size, only DPI matters. Since graphics file formats (at least PNG) can embed DPI information, KDEPrint will have this information also and can provide controls for selecting paper size, orientation positioning the image on the paper, and so on. KDEPrint can even show a small preview directly on the print dialog, like the GIMP has (that would be a very cool feature). Page-oriented applications (KWord for instance) will probably stick to Postscript and want to have full control over page size, orientation, and so on. So I guess these applications need to provide the job controls themselves and embed them in the print dialog.
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
> 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...) :-) I'm not a pro either.. But if the printer uses CMYK color inks, the printing system needs to convert the image to CMYK. Pro's (and some non-pro's) want to control this conversion process. > 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"]. Leaving the choice between postscript / image printing to the user does not sound like a good idea. The average user will not understand what the heck "Print as Image" is supposed to do. The average user does not even know what Postscript is. My guess is that every app should decide which 'printing path' to use: Postscript or bitmap image. > 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... :-) Well, I know *nothing* about KDEPrint, and very little about color management and KDE development. I also do not know any of the developers in the field of printing or image processing software. Maybe it is an idea to invite a bunch of developers (KDEPrint, Krita, DigiKam, GwenView, etc) in an IRC session and exchange ideas. I would be happy to join.
I'd love to see this improve! just searched a bit for how to print to cups directly: lpr -P photosmart -o media=Photo -o scaling=100 img.jpg (*) did an admirable job, except for the margins around the image on a 10x15cm print. The printer is well supported by cups/gutenprint (hp d7160 with the d7100 driver), but it still does better without the computer interfering with the image, when I use a CF card to print jpg files directly. The printer has no problem printing on the entire 10x15 card! I suppose this must work from windows or the mac, but I can't test that. (*) the printername and media would probably be different for another printer, the media names can be found in the ppd file, which should be located in /etc/cups/ppd Cheers Simon
KDEPrint is obsolete, unmaintained and will never be revived. Closing all open bugs. I think many of these options are now available in Gwenview and Digikam.