2

OK. So I understand that CUPS works as a Print Spooler, managing print jobs and sending them to printers. I also understand that PPD files describe the feature-set of a printer and that CUPS uses these and filters to interface with the printer, generating an output that the printer can use to print the document (either in PostScript, PCL or whatever proprietary format the printer requires). But I'm confused as to a few aspects of this. Mainly:

  • How do applications send print jobs to CUPS?
  • How do applications get print options for whatever printer is selected? DO these come from the PPD file or filter that CUPS uses for the printer?
  • How does this work when the printer is shared by CUPS over IPP? Does whatever device is sending a print job to CUPS do the processing locally or does the CUPS server do it? If CUPS does it, does that mean that the local device needs the PPD file to get the print options, or does CUPS send this to the local device?
  • As far as I'm aware, any linux computer will probably use CUPS locally as well for printing, so how does this work in regards to print options and processing the print job into PostScript/PCL etc.

Thanks for helping to clear up my confusion.

1

There are many ways to get a print job to CUPS:

  • a local process might just pipe ASCII text or PostScript to the CUPS's implementation of the lp or lpr command for printing, if the process is a traditional Unix program.
  • or it might use the LPD printing protocol in port 515/TCP on localhost, if CUPS has LPD compatibility enabled
  • or it might talk IPP over localhost port 631
  • or it might use CUPS's client library (libcups.so) for full native CUPS support.

If the lp or lpr command is used, any job options must be specified using command line options, and there is no traditional way to discover the supported options automatically; any programs using this legacy Unix interface will usually let the user edit the print command line to set any options necessary. CUPS also includes a file format autodetection (similar to the file command), so that you could in theory e.g. just say lp something.png and get the image printed in some reasonable way if CUPS has a PNG format converter available.

The CUPS implementation of IPP includes some protocol extensions that allow the client to query and set printer and job options, and even request the PPD content.

The IPP protocol itself includes content negotiation, much like HTTP: the server specifies the print job formats it can accept as MIME types, and the client declares the format of data it is about to send. If the server does not support a particular job format, the job can be rejected. It is also possible to specify "application/vnd.cups-raw" as the job format to indicate that the job should be passed to the printer exactly as-is without any conversions: the CUPS administrator may choose to allow this or not.

Generally, a CUPS server has a range of job format converters available to convert various file types to some standard "queued job format" and from there to whatever the printer is accepting (e.g. PCL, PostScript, or one of the more proprietary formats). The "queued job format" used to be PostScript, but is now PDF in modern versions of CUPS.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.