Occasionally we receive calls from people reporting problems with transparent print, more specifically that their printer might print ok the first time, but subsequent print jobs consist of garbage or the printer locks up. This article is written to help people who run into this problem understand why it is happening, and what they can do to fix it.

Typically, this problem has nothing to do with the onstr/offstr setting or the terminal emulation the port is set to, since numerous files can be catted to the printer port and they work flawlessly. The problem only appears when transparent printing from an application, or when sending print jobs through the spooler.

In order to understand what is happening, let's talk a little bit about devices in general. On a SCO system for instance, there are 4 different devices created for each physical port, for example ttya##, ttyA##, pra##, and prA##. These devices all point to the same PHYSICAL port, but are created to allow for a clocal (ttya*) and -clocal (ttyA*) tty device, as well as a clocal (pra*) and -clocal (prA*) transparent print device. Since the psuedo devices all point to the same physical port, an stty (ioctl()) call that changes a characteristic of the port (ie, speed, flow control, etc) will cause the change to happen for ALL of the devices. Though our example uses the name of devices created during a SCO driver install, it applies equally to any of our drivers which create more than one psuedo device for each physical device.

How does this all tie together? When the pr device is setup for printing in the application or print spooler, usually the first thing the app will do is open() the port and send an stty configuration string to the device to configure characteristics the application or spooler wants to see on the port. If we were talking about a serial port that has no other use except a printer, that would be fine. In the case of a transparent print device however, there is an underlying (and controlling!) tty device, so any settings made by the printer application/spooler are ALSO being made to the device being used for the getty running on the terminal!

*** Example ***
User has a terminal set to 38400 with a printer connected to it that runs at 9600.

The user sets letter "o" in inittab for the tty, and then creates a print spool for the port using the corresponding "pr" device for that tty. When a spool is created, lpadmin controls the print settings.

The user then logs into the port with no problems at all. They send out a print job to the printer connected to their terminal, and now when the user types at the terminal they get jumbled characters.

*** Solution ***
The solution to the above case is simple. In the lp interfaces script for that spooler, remove any mention of stty for that pr device, so there is no longer any stty string in there whatsoever.

I can understand some concerns at this point. You may be thinking that the printer will no longer be configured for flow control because you've removed the stty string, or that it will no longer work. Remember, gettydefs/inittab controls the settings for the physical port which your terminal is connected to, and therefore sets the baud rate, flow control, etc. between port and terminal. Settings for the transparent printer attached to the terminal are set on the terminal itself, therefore the OS/lpinterface need not be configured for it.