Jump to content

Printing/CUPS/FAQ

From KDE Community Wiki
Revision as of 18:33, 26 May 2011 by Jlayt (talk | contribs) (Created page with '== CUPS FAQ == This is a slightly edited version of the old KDE CUPS FAQ, which itself was extracted form the KDEPrint Handbook by Kurt Pfeifle. === Why can't I re-start my job...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

CUPS FAQ

This is a slightly edited version of the old KDE CUPS FAQ, which itself was extracted form the KDEPrint Handbook by Kurt Pfeifle.

Why can't I re-start my jobs from the CUPS web interface?

To re-start your "completed" jobs from the web interface, you need an entry of (in the /etc/cups/cupsd.conf)

PreserveJobFiles Yes

set (default is "Yes").

To see your completed jobs, you need

PreserveJobHistory Yes

set (default is "No").

How does CUPS "page accounting" work?

CUPS passes nearly every job through the pstops filter; pstops does, amongst other things, the page counting. Output of this filter then may be piped into other filters or even a chain of filters (like "pstoraster --> rastertopcl") or sent to the printer directly (if it is a PostScript printer).

In any case, this works for network, parallel, serial or USB printers the same. For pstops to work, it needs DSC, Document Structuring Convention compliant PostScript (or near-equivalent) as input. This way it calculates the pages during filtering on the print server and writes info about every single page (what time, which user, which job-ID and -name, which printer, how many copies of which pages of the document, how many kilo-bytes?) into /var/log/cups/page_log. (By the way: on my personal \wishlist\ is a hack of \webalizer" to read and analyse the page_log and give a similar output. Anyone?)

However, it is *not* giving correct results in the following cases:

  • the printer jams and maybe therefor throw away the job (real life experience with real-life printers; or maybe throws away the job because of problems with the data format)
  • jobs printed as "raw" are always counted as size of 1 page (and maybe multiple copies).

Therefore page accounting of CUPS is "only" an approximation (in many cases an excellent + good one, in others a quite poor one). The only *reliable* print count is the one done by the internal printer counter. (Because this is the one you pay for, if you are on a "click price" or similar.) Some, by far not most, printers can be queried remotely for that information via SNMP (Simple Network Management Protocol). That means, in a bigger network with many different printers there *is* just no completely reliable and accurate page accounting tool!

Why is CUPS page-accounting not working with Windows clients?

From Windows clients jobs nearly always need to be sent as "raw". Why? If CUPS works as a print server for Windows clients using the original native Windows driver for the target print device, this guarantees the correct formatting of the job on the clients already; therefor the server should not touch it -- this is also called "raw" printing; no filtering is started by print daemons being asked to handle a printfile as a "raw" printfile. (Filtering in most of those cases is not even possible, because the input from the clients mostly is not PostScript such as the CUPS filter pstops expects; hence no pagecount occurs other than the default "1"...

How do I get a list of available options for a given printer or a PPD file?

See the man page for the lpoptions command. You may query a CUPS-enabled box about any option of its available printers. There is no need to have the printer installed locally. As long as the printer is available locally (through the CUPS "printer browsing" feature), it will also work remotely. To query for a printers' option, type something similar to:

lpoptions -h transmeta -p HitachiDDP70MicroPress -l

This will give a long listing of all available options as read from the PPD file for the given Hitachi-Printer (in my case installed on remote server transmeta). Remote server transmeta and its CUPS daemon as well as the localhost's CUPS daemon need to be up and running for this to succeed. If you leave out the "-h" specification to query a remote host, it is assumed that you want to query localhost for a local printer.

How do I read the listing retrieved by the lpoptions command?

You should know, that for PostScript printer manufacturers it is "legal" to define their own internal names and procedures even for standard PostScript options. As long as the driver is able to retrieve the option from the PPD and show it to the user in a way that he understands it, everything is OK. But what do you do, if you want to use some obscure printer options on the *command line*? How do you find out its exact syntax?

Let's take an example. Looking at Hitachi's DDP70 printer and how it implements duplex printing is revealing somehow. How do you tell how to print double sided (duplex or Duplex?). Here is the CUPS solution (command should be given in one long line, not using the backslashes):

 lpoptions \
    -h transmeta \
      -p Hitachi_DDP70_ClusterPrintingSystem \
        -l | grep uplex

This leads to the output

  TR-Duplex/Duplex: False *True

This is to be interpreted like follows:

  • name of the investigated option is "TR-Duplex"
  • behind the slash you see the translation of the option, as it should be shown in a GUI or Web interface ("Duplex")
  • option may take one of the two values "False" or " True"
  • present setting is "True" (to be recognized by the marking with a star/asterisk *).

The "Duplex" option for this printer should therefor take the following form if used on the command line (or in a script with a print command):

lpr -o TR-Duplex=True

To override the present default setting (duplex is true, as shown by the asterisk in above example) and print a job in simplex, you need to use the following command:

  lpr \
     -P Hitachi_DDP70_ClusterPrintingSystem \
       -o TR-Duplex=False \
         /path/to/your/printjob

How do I get a nicely formatted listing of available options for a given printer or PPD?

Use the lphelp command which may be installed on your system locally. There is not yet a man page for lphelp. (lphelp was written by Till Kamppeter from Mandriva; as it is distributed under the Free GPL license, you may find it by now on most other Linux distributions.)

  lphelp infotecP450

This lists the available options for the named printer. It is nicely formatted and does explain every available option and how to use it. You can query different printers for their respective options at once:

  lphelp infotec7410color DANKA_fullcolor_D2000 HP_ColorLaserJet8550

It also works for PPD files. Just specify the path to the PPD:

  lphelp /home/kurt/PPDs/HP-ColorLaserJet8550.ppd

This is quite handy if you want to inspect a PPD file for the abilities of a printer you plan to install.

Here is an example output (cut short after a few lines):

kurt@transmeta:~> lphelp /etc/cups/ppd/mopier320.ppd

======================================================

HP LaserJet 8100 Series

======================================================
  Black & white printer
  Printer-specific options
  ------------------------
  Besides the options described in the CUPS software users manual
  (http://localhost:631/sum.html)  you can use also the following
  options, when you print on this printer with the  "lp" or "lpr"
  command.  --  A choice with the  "default" mark  represents the
  behaviour of  the printer when the  appropriate option is *not*
  given on the command line):
  Duplex:  -o Duplex=[choice]
     <choice>> can be one of the following:
     DuplexNoTumble  (Flip on Long Edge (Standard), default)
     DuplexTumble  (Flip on Short Edge)
     None  (Off (1-Sided))
  Medien-Größe :  -o PageSize=[choice]
     [choice] can be one of the following:
     A3  (A3, size: 11.69x16.54in)
     A4  (A4, size: 8.26x11.69in, default)
     A5  (A5, size: 5.83x8.26in)
  [....cut here....]

[German expressions in above output due to German PPD file. Any PPD file is specific to only one language.]