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 an attachment (id=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 an attachment (id=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?