Version: 0.9.2-final (using KDE 3.5.7, compiled sources) Compiler: Target: i586-mandriva-linux-gnu OS: Linux (i686) release 2.6.18.8.tex5 We are experiencing long printtime when small and especially large images are printed. An ordinary image, 2-4MB in size, takes forever to print (30+ minutes if ever) - but the situation can be handled by rightclicking the image, open with Gimp and then print - this only takes 5-15 seconds with the same image. We use Digikam on a Linuxnetwork in a learning center for young kids at our museum - and when they print with Digikam we have to delete the printqueue and reset the printer for each job. We are using a HP5550n lan printer, using Jetdirect. Clients prints to a Linux printserver. All other applications print fine - Gimp, OpenOffice. We had a Linux support technician to look at the problem and he diagnosed the problem to be a digikam compiled printsystem that causes this delay, All Linuxsystems are PCLinuxos2007 final - and all systems are fully updated (synaptics). This is the only problem we have with DigiKam - and we must say that it is a brilliant photo handling program, Regards, Martin Bantz IT chief-consultant Royal Museum of Fine Art Denmark
Martin, Are you using Image editor to print picture, or the print wizard kipi-plugin ? In the first case, digiKam use KDE printing interface. Are you the same problem using others KDE application like konqueror, gwenview, krita, etc... In the second one, the printing system is different. Are you tried to use it ? Angelo, we have already few report about editor printing interface, and you have solve few issues about. What do you think about this report ?
First some questions: - is the system a Mandriva or another one? (the bug seems to say Mandriva, Reporter PCLinuxos2007) - which hplip version are you using? - is quality of printing better anyway in digikam -when finished- than in gimp? - have you experienced any other kde application? Gwenview or kipi-plugins for instance. Now what i can say is kde printing is different compared to the way gimp does, IIRC gimp use guteprint directly, that was an old idea of old printwizard maintainer iirc again. Anyway I experienced some similar problems in mandriva and always with hp printers, so i believe there something on hplip drivers. Have a look at http://qa.mandriva.com/show_bug.cgi?id=23455 for instance.
Dear Angelo, I will check your questions right away, I'll be back as soon as possible, regards, Martin Bantz -----Oprindelig meddelelse----- Fra: owner@bugs.kde.org [mailto:owner@bugs.kde.org] P
Hi again Angelo, - the system is PCLinuxOS2007 - the final version - synaptic tells me that hplip is 1.6.9-3pclos2007 version - the print seems the same in both digikam and gimp - but I can make further checks if needed now for the interesting finding, I just installed Gwenview (nice program) - and it produces the exact same behaviour - after 2 minutes I cancel the job and restart cups. Then using Gimp - the print is printed after 32 seconds, the testimage is a JPG image, 2MB in size, this must imply that the bug has to be reassigned, can You direct me? any help greatly appreciated :-) Regards, Martin Bantz www.ulk.dk -----Oprindelig meddelelse----- Fra: owner@bugs.kde.org [mailto:owner@bugs.kde.org] P
Martin, Sound like a problem in CUPS deamon running with hplip driver. Note, here, i use everywhere hp printers (larserjet and colorjet) without problem. Perhaps you need to update cups and/or hplip on your computer. Gilles Caulier
> - synaptic tells me that hplip is 1.6.9-3pclos2007 version http://hplip.sourceforge.net/ shows newer versions As far as i can say i've seen a similar problem in mandriva 2007 (hplip 1.6.9) and a speed improvement with mandriva 2007.1 (hplip 1.6.12). > - the print seems the same in both digikam and gimp - but I can make further checks if needed The important thing should be the quality, e.g. dpi settings, page type etc. Other one could be the way we (in kde) print if I'm not wrong the process passes to gs before going to the printer, and that is slow and long. To see that you could run on a konsole top and have a look at active processes during the printing, I'm quite sure you will see gs untill the image is in print queue. > this must imply that the bug has to be reassigned, can You direct me? The best way could be asking for it to hplip developers/support (http://hplip.sourceforge.net/), on their mailing lists, but they will ask to you for using the last version first i believe.... Angelo
Just a little note on hplip 2.7.7 release notes 3. Added pre_install_cmd to installer to fix cups issue in PCLinuxOS and Mandriva maybe it could be pointless.... maybe not
Hi, I think it is a problem of print resolution. I have an Epson RX600. The ppd-file shows an resolution of 1440x1440dpi for photo quality. KDEPrint produces postscript level 1 files, which include the raw image data. An A4 page with 1440x1440dpi 24Bit color results in a ps file of size 600MByte !! CUPS invokes ps2ps, which takes a VERY LONG time to process this file. OpenOffice can only print an A4 page in photo quality if I check the "Reduce Bitmaps" in the printer settings, otherwise it will be killed due to out of memory during preparation of the ps file. Maybe it tries to scale the images to the selected printer resolution. A reasonable would be an option to the digikam/printwizard dialog to set a custom resolution. This would solve also the issue that printing to ps file is done with screen resolution which is useless for photos. There were other issues of printing with low resolution. It seems that KPrinter uses screen resolution as fallback if it can not gather the value from the ppd-file and some ppd-files of some drivers may be "buggy". Here a custom resolution would solve that too. Jörg
> A reasonable would be an option to the digikam/printwizard dialog to set a custom resolution. Resolution (by now) is useless in printwizard, dpi are not used yet... Krinter interface as far as i understood cannot make much for customizing resolution, and always if i understood correctly driver settings override them. I haven't find a way yet to get "non standard" info from kprinter, I mean ppd files and drivers can give more options like photo paper quality, paper resolution, bordless printing. They are all present in kprinter dialog box, but i haven't found a standard way to get them, think of page layout for instance, A4 is A4 for any printers, photo paper (15x10 cm for instance) is not... QT and KDE should "standardize" that first I believe, and disable if not given by drivers.... imo of course.
Dear all, hold your horses, I'll first try to get the newest hplip - I'm wondering why PCLinux (final) is shipped with this old version, I'll get back as soon as possible, Regards, Martin -----Oprindelig meddelelse----- Fra: owner@bugs.kde.org [mailto:owner@bugs.kde.org] P
Hi again, the upgrade to HPLip2.7.7 didn't make any differnce, this time I print directly to the JetDirect port on the printer. I've selected the Adobe PS PPD file when installing to HPLip - this is the exact same PPD file I use in Gimp/Gutenprint, The Gimp is printing with the same speed using the 2.7.7 drivers (that is around 30 seconds), I sure hope one of this group has an idea of where to look now, Regards, Martin -----Oprindelig meddelelse----- Fra: owner@bugs.kde.org [mailto:owner@bugs.kde.org] P
After further investigations about the KDE/Qt print mechanism I found out that the printing problem with digikam/printwizard is a Qt problem. The Qt postscript driver is very poor and can only create postscript level 1. The resolution of the image is not the problem. It seems that the image is embedded with the original size. The larger the source image the larger the postscript file. But many printer driver use ghostscript to create raster files and the postscript created with Qt is very inefficient. Preview and further processing takes very long. Gimp uses gimp-print or gutenprint, which can create a postscript level 3 file. Ghostscript can process this file much much faster when viewing and printing. I think there is nothing to be done. Maybe you can try the program photoprint (http://www.blackfiveservices.co.uk/photoprint_news.shtml). It can be called from digikam context menu "Open with ...". It uses gutenprint directly and prints very fast. JK
Joerg, Thanks for this investigaution. now the problem is clear. Perhaps something can be done if Qt version 4 handle Postscript V.3 properlly. (digiKam is already ported to KDE4/Qt4). Are you some informations about ? Gilles Caulier
I found some discussions, but I think neither Qt nor KDE-Print will provide a quick solution. See: http://mail.kde.org/pipermail/kde-print-devel/2007-January/001407.html http://thread.gmane.org/gmane.comp.kde.devel.core/45560 especially: http://thread.gmane.org/gmane.comp.kde.devel.core/45560/focus=45682 JK
Would it be possible to allow for different "printing back-ends"? With this the user could choose among the default and others, like the above mentioned photoprint.
> Would it be possible to allow for different "printing back-ends"? > With this the user could choose among the default and > others, like the above mentioned photoprint. We could try to make a guteprint frontend (kguteprint?) into extragear/libs and use it into printwizard... that could be very nice and printwizard could be the optional printing for users... the default one is using kprinter... I can't do that without help though :( Anyway what do you think about it?
Angello, > I can't do that without help though :( I'm here to help you of course. And i'm sure than others contributors will be interressed by this job. Printing is common in photo world... (Gerhard, Arnd, Luka, etc... ?) > Anyway what do you think about it? I'm agree. But there is always something like this in opensource world. Are you checked this point using google ? Gilles
Angelo, I'm so surprized than no KDE interface already exist to gutenprint (not "guteprint") I'm not sure if a new shared lib is the right way. I think than something in KDE core is more appropriate. Perhaps we need to contact kde print devel team on mailing list before to start something... Gilles
I'm glad to hear that the reason for the slow printing is established - this was a big concern to us - I had parallel investigations going on with cups/jetdirect, but I'm now sure that the QT postscript level 1 driver/handling is the main issue. What strikes me, is that a lot of people must have this problem - so I'm pleased we can assist in sorting things out. The suggestion about being able to select the printengine would certainly work for us. Then, when QT can provide more efficient printhandling - the user will be able to change back to the QT engine. To come by the issue - we tell the schoolkids (there were 80 in class last week) to use the open-with feature and use Gimp. We are trying to teach users using Gimp, and it's printengine (GuthenPrint), is reliable, blazingly fast and has all the options we need. Only problem is when the kids are not listening :-) then they clog up the printqueue :-) As an aside, our conservation team at the museum needs X-ray images of a large Jordaens piece stitched together - and I'm using Gimp to level the image correctly, but we need 16 bit handling but Gimp handles only 8 bit. Can this group recommend a 16 bit system to us? Thank you all for this very impressing and interesting discussion, Martin Bantz Royal Museum of Fine Art Denmark -----Oprindelig meddelelse----- Fra: owner@bugs.kde.org [mailto:owner@bugs.kde.org] P
> I'm so surprized than no KDE interface already exist to gutenprint (not "guteprint") :) Don't know, i haven't look for it yet.... always tried to use kde/qt interface. > I'm not sure if a new shared lib is the right way. I think than something in KDE core is more appropriate. There are a lot of bugs/request for changing kprinter/qt interface iirc. In other ml i read other users complaininig for this problem. And always iirc i haven't seen much improvements in kde printer interface yet (don't know for kde4 though). > Perhaps we need to contact kde print devel team on mailing list before to start something... Feel free to, and give us a feed back for it :) Any improvments is *more* than welcome :D Angelo
Angelo, This file is purely relevant of KDEPrint interface. Like all is currently re-writted for KDE 4.1, i propose to move this file in KDEPrint component of KDE bugzilla, else nothing will be fixed... What do you think about ? Gilles
Angelo, In this place especially : http://bugs.kde.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&product=kdeprint&component=general&version=unspecified&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&bug_id=&votes=&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&order=Reuse+same+sort+as+last+time&cmdtype=doit&newqueryname= Gilles
This is not new issue. For long time I prefer Scribus or even KWord to perform printing of photos because printing from digiKam takes ages. Not that while Scribus doesn't use kdeprint KWord uses it all right.
> Angelo, > > This file is purely relevant of KDEPrint interface. Like all is currently re-writted for KDE 4.1, i propose to move this file in KDEPrint component of KDE bugzilla, else nothing will be fixed... > > What do you think about ? It's fine for me.
What news about this file ? As KDE 4.x use Qt printing interface now, it's solve the problem ? Gilles Caulier
New digiKam 4.11.0 is available. https://www.digikam.org/node/740 Can you reproduce the problem with this release ? Gilles Caulier
With digiKam 5.0.0, this problem is not reproducible. I close this file now. Don't hesitate to re-open if necessary. Gilles Caulier