trouble setting up cups printer queues on redhat enterprise 5

[Gary LaBonte]

I am moving an application from a TRU64 AlphaServer to an Intel based server running RHEL5. I have numerous queues setup on the Alpha and I am using CUPS in the linux box. Using the CUPS gui, I can setup the queues and print to them from the linux box but the files format differently. All of the HP lasers act the same way. I created a text file 80 characters across with 66 lines. The TRU64 box prints the file fine. Using the CUPS created queue, the linux box prints the file in a bolder font and uses 2.5 pages. I setup another queue on the linux box but set it up as a raw queue. The file prints with the same font as the TRU64 box and the correct number of columns but the line spacing is off, only printing 60 lines on the page.

Thanks for any help,
glabonte

The queues are setup as follows:
TRU64 queue
#HP4200 laser in tech services area
lp5|lp5|hp4200:\
:ct=tcp:\
:if=/usr/lbin/ppdof +OPageSize=Letter +Chplj4100.rpd:\
:lf=/usr/adm/lp5err:\
:lp=@oflaz2/hplaser:\
:mx#0:\
:of=/usr/lbin/ppdof +OPageSize=Letter +Chplj4100.rpd:\
:pl#66:\
:pw#0:\
:sh:\
:rw:\
:sd=/usr/spool/lpd5:\
:xf=/usr/lbin/xf:


cups queue
Description: HP LASER
Location: IT_TECH_SERVICES
Make and Model: HP LaserJet 4200 Series Postscript (recommended)
Printer State: idle, accepting jobs, published.
Device URI: socket://172.16.2.58


raw queue
Description: hp4200
Location: tech service
Make and Model: Local Raw Printer
Printer State: idle, accepting jobs, published.
Device URI: socket://172.16.2.58:9100

[Matti_Kurkela]

Hmm. CUPS contains quite a lot of auto-detection and auto-conversion features, and I think your problem is probably caused by them.

Is the print output of your application in PostScript or plaintext format? I'd guess plaintext, because the output of the raw queue is similar to TRU64 output.

As far as I can determine without experimenting with an actual TRU64 machine, the TRU64 queue will prepend the print job with some control codes to set the page size and the number of lines per page, then pass the data to the printer essentially as-is.

Your first CUPS queue probably uses some kind of text-to-PostScript conversion or PostScript preprocessing, which causes the font to change.

On the other hand, the raw CUPS queue does nothing at all to your application's output. The number of lines per page is then defined by the printer's default settings.

Offhand, I can think of two ways to fix this. There are probably other alternatives.

(Disclaimer: I don't have a RHEL5 box with a printer available for testing, so my answers will be based on CUPS of Ubuntu Linux. They are probably very similar.)

1.) Adjust the printers' default "lines per page" value to 66 using the printers' LCD control panels. Then print from the application using the raw queue(s).

Pros:
+ won't interfere with printing from Windows PCs, because PC print jobs always reset the print job settings to factory defaults at the beginning of a job, then specify all the necessary settings explicitly. This overrides everything set using the printer control panel for the duration of the print job.
+ no need to fiddle with the internals of CUPS

Cons:
- Unless you can configure the printers remotely (using WebJetAdmin or a scriptable tool like npadmin, http://npadmin.sourceforge.net/ ) this may be a lot of footwork, as someone must physically visit each printer

2.) Modify CUPS's configuration to do what you need.
Essentially, you would have to create your own filter script. Then you must create your own PPD file to invoke that script.

There should be a "textonly.ppd" or something similar. On this Ubuntu Linux system, it's at /usr/share/ppd/cups-included/textonly.ppd. It would be a good starting point.

Within the PPD file, there will be a line beginning with "*cupsFilter". At least in this Ubuntu Linux, the line is:

*cupsFilter: "text/plain 0 textonly"

This defines
- the printer's native MIME type (in this case, "text/plain")
- the main filter script associated with the printer ("textonly")
- the cost associated with the filter script (0)
The main filter script can be found in /usr/lib/cups/filter/textonly. It's a standard shell script.


CUPS identifies the content of the print job using the rules listed in the /etc/cups/mime.types file. If the MIME type of the print job matches the type listed on the cupsFilter line of the printer's PPD file, only the filter listed in the PPD file gets used.

If the MIME types won't match, CUPS uses the /etc/cups/*.convs files to find a (chain of) conversion(s) that will change the job's content so that its MIME type will be suitable to the printer. If there are several possible conversion chains, CUPS uses the chain with the smallest total cost (i.e. usually the shortest possible conversion chain).

If there is no cupsFilter line in the PPD file, then CUPS apparently assumes the printer is a PostScript printer and converts everything to PostScript according to the rules in /etc/cups/mime.convs.

Assuming that your application output is of type text/plain, you would want to create a modified version of the /usr/lib/cups/filter/textonly script that prepends the necessary control codes to achieve the correct line spacing and number of lines per page. Then create a modified version of textonly.ppd that invokes your modified filter script and create a print queue using that PPD file.

Pros:
+ no need to modify printer settings; all changes can be done at the server end

Cons:
- requires some shell scripting skills
- requires access to printer protocol manuals to determine the correct codes
(Last time I looked, the HP PCL and PJL control code references were available at the HP printer support webpages.)

MK