Bug 91644

KDE applications uses Qt's PostScript support to print.

As Qt is a general programming library, it is not as specialized as Gimp to create correct printing of images.

Have a nice day!

I reassign to digikam devevelopers. It's the only app from your listed list that I considered having good print out as target

> I reassign to digikam devevelopers. It's the only app from your listed
> list that I considered having good print out as target

Sorry but that is bullshit. Reducing quality of photos is bad for _all_
applications.

Eg.
- How I can prepare something more advanced in KWord when photos suck?
- How I can print photo of my aunt cat in KMail/Kuickshow when print sucks?

Sorry, I was a bit misleading. I meant: if not even digikam can print photos, then who can? :)

I had a discusion on Digikam mailing list => they told me to fill a KDE bug because it is a general kde problem (kprinter from kdelibs)

IMHO it should be a good thing to be able to print with good quality with at least from Digikam, but from any kde too (konqueror for example). Windows XP is not a model but regarding photos printing, it's really more user friendly : you don't have to think "which application do I need to use for printing" : double clic from file manager and you can print your photos ...

it seems kprinter doesn't use printer resolution by default. you have to force it to do so. fix has applied in cvs to digikam and kipi-plugins (calendar and printwizard). can you guys please waste some more ink toner and test it out. 

> Sorry, I was a bit misleading. I meant: if not even digikam can print
> photos, then who can? :)
Sure. But Digikam isn't general photo management system. You have to
import there photo.
1: Digikam isn't core KDE app
2: User doesn't always have to use photo management program to print
   images. Eg. I made some tests and the same photo printed from OO.o
   has better quality than from KWord.

I had somes problems but I managed to compile today's CVS (10/22) :-) I cannot say the result is a success ;-)) : printing a A4 give me some kind of big pixels, on 4x6", it's about the same but smaler, see attached file ... 

Printing still works as previously for other kde software ;-)

Created attachment 8000 [details]
sample printing with 10/22 cvs

what does the attached photo show? is it a scan of the printed image? do you have a sample of the original file?

yes it's a scan of the result (A4 and 4x6), I'll post the original file (sea landscape)

Created attachment 8001 [details]
Original file

I cannot confirm that supposed bug at all. I printed the file (attachment as linked below) 

 a) on a black+white Laserjet 8100 (once as PostScript, once as PCL). 
 b) as well as on a Color Laserjet (PostScript). 
 c) onto the screen as a "preview".

I didnt use the "Turboprint" driver for this (wouldnt be useful for the printers at my disposal). I printed directly from Konqueror, from Kuickshow, from Gwenview -- always using kprinter as the print dialog. My printout resolution was 600x600 dpi.

My KDE versions were: current HEAD (self-compiled), 3.3.1 (both on SUSE-9.1), 3.2.3 (on Knoppix-3.6). My CUPS versions were: 1.1.20 and 1.1.22rc1.

What does this proof? 

 1) the file is OK -- nothing weird with it.
 2) KDE, KDE applications or KDEPrint don't have the bug described here
    regarding printing of hi-res images.
 3) the standard CUPS filtering system chains work fine on this file:
    * printing as PostScript: JPEG --> (imagetops) --> (pstops) --> PostScript
    * printing as PCL: JPEG --> (imagetoraster) --> (rastertohp) --> PCL

It is hard to believe that the scan is similar what the printer spits out. That looks like a resolution of 6dpi instead of 600dpi.

The printfile is generated by the applications (mostly as PostScript). kprinter doesnt change that file by default (it can however run some "pre-filters" on it, if you explicitely select them). kprinter is just an interface to select print options. From the selected print options, kprinter constructs a commandline and passes the printfile and the commandline options to the underlying print system (mostly CUPS nowadays). CUPS uses its own or some third party filters to convert the printfile into a format that the printer can digest.

I think that bug can savely be closed. There is something seriously wrong with the submitter's system setup.

I invite him to come to one of the forums/newsgroups/mailing lists where CUPS and printing is discussed, and we'll troubleshoot the problem in his setup there:

 * Linuxprinting.org/: http://www.linuxprinting.org/forums.cgi (General group)
 * CUPS.org: http://www.cups.org/newsgroups.php (General group)

I most likely will be there and respond. But we need more details than was provided here:

 a) each single setting in the print dialogs he uses.
 b) the output of "grep cupsFilter /etc/cups/ppd/*.ppd".
 c) the output of "ls -l /usr/lib/cups/filter/".
 d) the output of "lpstat -p [his_printername]".
 e) the output of "lpstat -p [his_printername] -l".
 f) the exact versions of the software he has: CUPS, TurboPrint, gimp-print, 
    Gimp, KDE

the wierd files I submited are the printing results using the cvs digikam version, not results concerning my initial complain ;-) With a fresh Mandrake install results are not so bad hopefully, but not as good as they should be ... 
- I'll post another scan to be more explicit
- I'll do other tests using another distro 

ok. here's the deal. i got one of the digikam developers to print out some pictures from the image viewer print dialog (with varying resolution). the results have been decent (taking into consideration the fact that he had a bad bunch of ink toners). also changing the resolutions of the printers works correctly now, with the image quality being improved with the resolution of the printer being bumped up. a lot of kde applications print with the default resolution (screen resolution) which is 72dpi. a fix was committed to digikam and the kipi-plugins to make use of the printer resolution when available. 

you would need to check your setup and as kurt suggested, maybe join the linuxprinting forums to figure out whats wrong with the setup. 

note, we haven't been able to compare the output to gimp printouts because of me not having printer and not having a response to my request from anyone yet at the mailing lists.

*** Bug 92438 has been marked as a duplicate of this bug. ***

I can confirm this issue also.  Print quality from digikam is very poor by default.

I have not reviewed the updated digikam CVS, but all I did to my digikam kipi plugins source code to fix the problem (before I found this bug report) was this:

In the file:
kipi-plugins-0.1-beta1/kipi-plugins/printwizard/frmprintwizard.cpp 

Line 293 was:
KPrinter printer;

Which, according to KDE doc's, creates a print job that defaults to an effective quality of your screen (about 72dpi) when printing, regardless of the dpi or quality mode of the printer.

If this is changed to:
KPrinter printer(true, QPrinter::HighResolution);

Printing takes significantly longer, but the quality is _much_ better. Although I would always want this on, printing could be painfully slow on older machines. It might be appropriate to have a "Print with High-Quality (slow)" checkbox in the print wizard that would trigger this option.

This same simple change might work well for other KDE apps that need to print in high quality.

I can only second Dave's comment above: Having QPrinter::ScreenResolution as the *only* supported PrinterMode setting in an application for printing photos is not appropriate, IMHO. Even QPrinter::PrinterResolution might not be such a good idea, since it results in a 72dpi resolution when printing to a ps file. (Which I sometimes would like to do e.g., when printing a photo calendar with the calendar wizard KIPI plugin.)

From the Qt docs (QPrinter::PrinterMode):
"... ScreenResolution will produce a lower quality output than HighResolution and should only be used for drafts. ..."

An ideal solution might be to make the default for the QPrinter::PrinterMode m parameter of the KPrinter constructor a globally configurable option instead of hard-wiring it. Of course, this would require a modification of the KPrinter class, but it might be worth it, since all existing apps would benefit from it: People like Dave and me could use a default of QPrinter::HighResolution, while others satisfied with 72dpi or stuck with old hardware might be better off with the QPrinter::ScreenResolution setting for performance reasons.

Just thought twice about that last suggestion of mine and realized that it's probably nonsense, since the default parameter value is substituted at compile time... Only way to enable existing apps (without modification) to print in higher resolution modes would be to reinterpret the QPrinter::ScreenResolution value to mean something user definable. Don't know if that would be a good idea, though.

So, I guess, it would be best to follow Dave's suggestion to add a check box to the print options of all apps which should produce high res output, like digikam, kooka, kuickshow, kview, ...

Thanks for your time!

digiKam now prints at the printer resolution... always. If you want to print at some other resolution, just change the settings on the printer directly.

Thanks a lot, this is good news! I can't wait to see it in action. :-)

I'm still not sure if this will allow printing to a ps file in a resolution higher than 72dpi, since the PS printer does not give me an option to set the printer resolution (unless I'm missing something?). However, printing to a physical printer in its native resolution(s) is fair enough, I guess. 

Once more, thank you for this great program!

I think there's still a problem here.  If I try and print an image (say some scanned text) to the PS or PDF pseudo-printers I get really poor quality 72 dpi output, and there seems to be no way to change this (the 'Image Resolution', 'Downsampling', and 'Compression' settings in the driver settings seem to have no effect).  Must it be this way?  It would nice to be able to make a nice PDF out of a high resolution scan.

This bug still applies to "kuickshow", "Gwenview" and "kipi print wizard" in their SuSE 9.2 versions (2004 October, package kdegraphics3-imaging-3.3.0-12). Is the bug fixed for these applications, too?