1. gpr doesn't work with LPRng when printing to a HP printer configured as a remote printer
2. On mandrake printtool starts CUPS
3. Network connection hang for a minute or so after parallel port job completes.
4. Autodetection of parallel port printers on Turbo Linux
5. Parallel printer autodetction may not work on the SuSE distributions
6. LPD init script silently exits
7. single page jobs don't print when n-up'd
8. lpd daemon must be restarted after package installation

1. gpr doesn't work with LPRng when printing to a HP printer configured as a remote printer

When you run gpr, it submits a print job using the lpr command with a lot of options. Those options are put in the control so that the filter scripts can make use of them when it needs to. LPR and LPRng handle this in two different ways. LPR puts one option on each line of the control file, whereas, LPRng puts all the commands on one line in the control file. This doesn't matter to anything except the filter scripts except for the case where the you have a printer configured as a remote printer. In other words, a printer where the printcap entry has "RM=hostname" in it. In these cases LPR believes that it is talking to another LPR LPR server and it sends the unmodified control file to the remote end. The LPR servers embedded in printers HP printers have an undocumented line length limitation. LPR doesn't trigger this problem because it puts every option on a line of its own. LPRng overflows the printer's LPR server line buffer by putting all the options on one line. This messes up the print job and it doesn't print correctly. The workaround is to always use, "direct to port" vs. "remote LPR server" when selecting how to communicate with HP printers. The next version of printtool will pop up a warning about this issue.

2. On mandrake printtool starts CUPS

The Draxdrake package on the mandrake distributions creates a symlink to /usr/sbin/printerdrake their configuration utility for printers. The gnulpr system installs the real printtool in /usr/sbin. If /usr/bin is in your path before /usr/sbin then you will be running printerdrake rather than printtool. If things are not behaving as you would expect, make sure you are running the printtool that is in /usr/sbin/printtool.

3. Network connection hang for a minute or so after parallel port job completes.

There is no connection on a raw parallel port and so the printer doesn't know exactly when a print job ends. So if you send a job to a parallel port and then try to send a job to the network interface. The job will hang for 45 seconds or so before it prints. After 45 seconds of silence on the parallel port the printer concludes that you are done with that print job and allows the one that came from the network to complete.

To avoid this problem click the option click the option "Send EOJ to signal completion of print job" for that printer. Then at the end of the print job an ASCII control character signaling the end of the job will be sent.

4. Autodetection of parallel port printers on Turbo Linux

The default modules.conf file that ships with Turbo Linux doesn't include the necessary aliases to allow parallel port autodetection to work. The solution to the problem is to add the following line to the /etc/modules.conf file.

alias parport_lowlevel parport_pc

This line will be automatically added by the installation script. However, if you manually install the RPMS then you will have to make sure that it is added to your modules.conf.

5. Parallel printer autodetction may not work on the SuSE distributions

The enhanced print system's version of printtool calls the pconf_detect utility in order to perform the autodetect function. The pconf_detect utility, in turn, calls modprobe in order to load the parport_probe module, as well as all of its dependencies. The SuSE distributions include some hardware-specific options for the parallel port modules that may not work on all systems. If you find that parallel port autodetection is not working on your SuSE machine, try editing your /etc/modules.conf and putting a '#' character in front of the line that reads:

options parport_pc io=0x378 irq=none,none

...making it now read:

#options parport_pc io=0x378 irq=none,none

You may also, as an alternative, enter in the appropriate hardware resource information for your system.

This spurious options line has been known to cause problems in some VMWare configurations.

6. LPD init script silently exits

If you find that you are unable to start lpd, make certain that you have an /etc/printcap file. The init script will not attempt to start lpd if no such file exists. If you are using our enhanced version of printtool, it will prompt you to restart LPD if it finds that no printcap previously existed.

7. single page jobs don't print when n-up'd

If you try to print a single page job using n-up, ppdfilt will generate bad postscript. See bug https://sourceforge.net/tracker/index.php?func=detail&aid=435476&group_id=3800&atid=103800

8. lpd daemon must be restarted after package installation

For the enhanced print system to work properly, the lpd daemon must be restarted after the software packages are installed. Otherwise, the old lpd daemon will ignore the advanced options that are passed to it by gpr or "lpr -o".