libkdeprint

Albert Astals Cid aacid at kde.org
Tue Oct 16 20:29:26 BST 2007


A Dimarts 16 Octubre 2007, John Layt va escriure:
> Right.
>
> In this e-mail I'll address printFiles() and leave the other issues to
> separate e-mails.
>
> I spent half my day at work today looking through the KDEPrint code to see
> exactly how printFiles does its magic, and I think the solution is fairly
> easy, depending on how fancy we want it to be.
>
> printFiles() takes the list of files to print, then applies any valid
> pre-filters chosen in the print dialog to the files, then passes the file
> list to the specific printer system implementation you are using (CUPS,
> LPR, etc).  The implementation then reads the settings from KPrinter,
> translates them into the printer system specific commandline options, and
> executes the command.
>
> In the case of CUPS, this is a KDEPrint utility found in
> kdelibs/kdeprint/cups/cupsdoprint.c which you pass the printer name,
> printer options and filenames.  It then calls the CUPS api for you and your
> files print.  For LPR the command is obviously 'lpr'.
>
> Now, there's a fair bit of code wrapped around that, most just for nice job
> management, but some to respect the settings chosen in the print dialog.
> This can be found in classes like KPrinterImpl, KCupsPrinterImpl,
> KLprPrinterImpl, KDEPrintD and KPrintProcess.
>
> My proposal is a 3 step one:
> 1) This is the proof of concept step.  Write a basic printFiles() that
> takes a QPrinter and a file list, reads the printer name from QPrinter, and
> executes cupsdoprint to send all the files to CUPS.  The key thing here is
> that QPrinter::printerName() provides a name usable for CUPS, which it
> appears to do.
> 2) Add code to detect between CUPS/LPR and add LPR support.
> 3) Add code to pass along other important settings, like print range and
> copies.
>
> This won't be supported under Windows or OSX (but then the old one didn't
> work either), or other *nix backends like rlpr.  However some file formats
> supported by Okular use the normal QPainter which will be supported, so
> Okular will need to pop up a message telling the users "Sorry this file
> format printing not supported on Win/Mac, but x, y and z do work"
>
> Nice plus is this method will work for any file format supported by CUPS.
>
> Does this all look feasible?  Obviously there is no way it could be
> completed and QA'ed in time to make kdelibs for 4.0, so the 3 apps affected
> will have to include it directly for now, but it will only be a small
> amount of code.
>
> If no-one else gets there first, I’ll start on this next week.
>
> Another problem is the non-continuous page selection which Qt doesn’t
> support, e.g. selecting random pages from the preview list in KGhostView (I
> don't think Okular currently supports this?).  

All KDE 3 apps support that, you just have to write 2,7,9 in the interval 
field of the KPrinter dialog.

Albert

> The work-around is that CUPS 
> does support being passed a file and a list of non-continuous pages to
> print.  So if a user has selected pages from the GUI, when we display the
> QPrintDialog we set the page range to Selection rather than All.  If they
> leave it at Selection, then we send the full file and the selected list of
> pages to CUPS to do the processing.  If they switch to All or Pages then we
> use those instead.  If they are not using CUPS (e.g. on LPR, Windows or
> OSX), then we first we pop up a message box saying "not supported, select
> All or a continuous range in Pages instead", then show the QPrintDialog
> with Selection disabled.
>
> This is a nice to have but not vital, as the user can stll select
> continuous page ranges instead.
>
> Now I just have to explain to the boss why that design document isn't
> ready :-)
>
> John.
>
> --
> Send instant messages to your online friends http://au.messenger.yahoo.com






More information about the kde-core-devel mailing list