Subject: 07 Printer Troubleshooting
Subject: 07.01 PostScript printing problems
Subject: 07.01.01 Timeout and other PostScript errors
Subject: 07.01.02 PostScript and the Ctrl-D business
Subject: 07.01.03 PostScript Character Set
Subject: 07.01.04 PostScript Test Page Code
Subject: 07.02 LaserJet printing problems
Subject: 07.02.01 Using PRINT SCREEN under DOS

Subject: 07 Printer Troubleshooting

This section is a summary of questions typically posted in the comp.periph.printers newsgroup. The questions are sorted by the type of printer involved. As new printers arrive in the market, new problems will arrive here too ;-) The questions begin with "Q:" whereas the (possible) answers (or solutions) begin with "A:".

Subject: 07.01 PostScript printing problems

See also the PostScript FAQ ftp://wilma.cs.brown.edu/pub/comp.sources.postscript for problems not covered here.

Subject: 07.01.01 Timeout and other PostScript errors

Q:

After printing a PostScript job the printer's "Ready" light keeps flashing or the printer's front panel shows the message "Busy" for a minute or so. If the PostScript error report is activated in the printer a page stating a "Timeout" error is printed after this time.

A:

Since PostScript has no end-of-job command the printer must be told when the print job is finished (otherwise the printer waits for more data belonging to this job, and after a while it gives up waiting and generates a timeout error). By sending a Ctrl-D (0x04) to the printer immediately after the print job the printer knows that end-of-job is reached. The Ctrl-D should not be part of the PostScript file - see next section for this - instead it should be sent by the printer spooler.
The same error occurs when the printer receives characters immediately after the Ctrl-D, e.g. a newline or a formfeed. When receiving any character after the Ctrl-D, the printer assumes that a new job is in progress and waits for it to continue.

Q:

When sending a small PostScript file to the printer everything works fine, but if the print job is rather big the printer generates an I/O error (the error page states "ioerror" as error condition).

A:

The most typical reason for I/O errors in this context is that the communication protocol between host and printer isn't set up properly. If the printer and the host use different flow control protocols (e.g. the printer uses DTR, but the host assumes XON/XOFF flow control) the printer can't stop the host when it's input buffer is full ("data overrun"). In general an improper setup for the communication line is responsible for I/O errors. With serial connections this involves some combination of parity, speed, data bits and stop bits.

Q:

When sending single print jobs to the printer and waiting for them to complete everything works fine, but when the printer spooler has more than one job at a time in its queue the printout for the second job (and all following jobs) is not correct, eventually the printer states "VMerror", "stackoverflow" or the like.

A:

The printer spooler must separate the print jobs from each other by sending a Ctrl-D to the printer after each print job. Before sending the next job to the printer the spooler should wait for the previous job to complete. For this reason the printer answers the Ctrl-D from the spooler with a Ctrl-D. When the jobs are not separated by means of Ctrl-D, the printer assumes that the next job is a continuation of the previous, and therefore does not re-initialize the job environment for the new job. This leaves all variables defined by the previous job still valid for the new job.

Subject: 07.01.02 PostScript and the Ctrl-D business

First some general information about this topic (questions may be found at the end of the section).

For communication with a Postscript printer it's necessary to tell the printer when a print job is completed. Since there is no end-of-job command in PostScript this is done by sending a dedicated character to the printer after each job is completely transferred. This character is Ctrl-D (0x04). It's the job of the program communicating with the printer to append the Ctrl-D to the print job (normally this is the printer spooler), a program (even a printer driver) producing Postscript output should never precede a job with Ctrl-D nor should it append one to the job unless this program does the communication with the printer too.

Since PC type computers normally do not have a printer spooler and the driver often sends print jobs directly to the printer these drivers embed Ctrl-D as first and last character in all print jobs. Using Ctrl-D as the first character flushes any previously sent job in case it's "jammed up". Doing so is correct as long as the printer driver sends the data directly to the printer, but when the driver writes the PostScript program to a file it's against the Adobe Document Structuring Conventions and moreover may cause problems when it comes to further processing of such a file.

The above is true for the MS-Windows PostScript driver. There is a section in the file PRINTER.WRI describing problems when a file generated via this driver is transferred to UNIX for printing or other processing.

The reason usually given as to why UNIX has problems with these files ("UNIX uses the Ctrl-D as an end-of-file marker, whereas MS-DOS uses Ctrl-Z") is absolute nonsense written by someone having little or no experience with UNIX. As stated above the real reason is that the Windows driver breaks DSC.

It's possible to prevent the driver from generating a Ctrl-D at the beginning of the PostScript output by adding the line

    CtrlD=0

in the WIN.INI file in the section [ModelName,Port] that describes the printer in question. Rumors say that this switch won't work with all PostScript drivers, moreover it may vanish if you change the WIN.INI file via the control panel. Unfortunately this switch doesn't suppress the trailing Ctrl-D.

Q:

When I print PostScript in a file on my PC (using DOS or Windows) and transfer this file to my UNIX host for printing, the printer spits out only garbage. Instead of printing my text and graphics the PostScript program is printed as plain text.

A:

UNIX printer spoolers for PostScript printers often check whether the file to be printed contains plain (ASCII) text or a PostScript program. This distinction is done by checking the first characters of the file for a sort of "magic sequence", and if these characters are "%!" the file is assumed to be a PostScript job. Otherwise the spooler transfers the text to a PostScript program that prints this text.
Normally this behavior is caused by a Ctrl-D being the first character in the file (see the general information above). The best approach would be to prevent the PC program which produced the file from adding Ctrl-D's at the beginning and the end of the file. If this is not possible you could use a filter that removes leading and trailing Ctrl-D from such files.

Subject: 07.01.03 PostScript Character Set

The PostScript Character Set is the set of characters used to write a PostScript program, not the printable characters in a PostScript font.

Adobe recommends use of only the printable subset of ASCII characters in a PostScript program, plus the characters space, tab and newline (both CR and LF are allowed). PostScript does not prohibit the use of characters outside this set, but using them may cause portability problems (e.g. when it comes to a transfer of 8-bit characters via a 7-bit serial line to the printer). For the representation of 8-bit characters inside a string you should use the octal form '\ddd'. For more information see the PostScript Language Reference Manual, second edition (the big red book).

Q:

When I print a PostScript file to a printer connected via a parallel line, text and raster graphics print correctly. But when the file is transferred to the printer via serial line, garbage characters are printed and there are dropouts in the raster images.

A:

This will happen if the file contains 8-bit characters and the serial communication is only 7-bit clean. It's common for the 8th bit to be used for parity checking. In the case of text strings all 8-bit characters should be written in their octal form '\ddd', raster image data should be send in ASCIIHex encoded form. See the 'readhexstring' command for further information.

Q:

I have a PostScript Type 1 font that I want to download into the printer. But when I do so the printer mentions a PostScript error either during download or during usage of this font.

A:

Type 1 fonts normally come in the so-called PFB format, which is a format containing the font information in an 8-bit, binary form. In order to send such a font file to the printer it is necessary to convert this format into a 7-bit clean representation, the so-called PFA format. The conversion may be done with the T1UTILS package available via FTP.

Subject: 07.01.04 PostScript Test Page Code

%!PS-Adobe-2.0
%%BoundingBox: 0 0 200 150
%%Title:        PrinterTest
%%Creator: David Byram-Wigfield 9.96
%%Contact: byram@cappella.demon.co.uk
%%EndComments
/line   {newpath 0 0 moveto 0 50 lineto 0 setlinewidth stroke} def
/star   {72 {line 5 rotate} repeat} def
                                                                gsave 100
100 translate star grestore
/screen { {dup mul exch dup mul add 1.0 exch sub} setscreen }def
/Pixels 256 string def
/wedge  {translate  scale  screen  image} def
              gsave 0 1 255 {Pixels exch dup put} for
              256 1 8 [256 0 0 1 0 0] {Pixels}
              85 45  148 18  30 20  wedge
              grestore
%%Trailer
showpage
%%EOF

Subject: 07.02 LaserJet printing problems

If you have an original HP LaserJet (model HP 2686/A) Arthur Entlich has put together a really nice FAQ discussing general hints on using one of these. hplj2686.txt

Subject: 07.02.01 Using PRINT SCREEN under DOS

Q:

Can you tell me how I can use [shift][print screen] with my HP Laserjet IIIp? I must enter the sequence 3 times before it prints anything then I get 3 copies.

A:

Well, I can tell you why it doesn't work the way you want. :)
What happens when you press the button is that the computer sends the 24 (or so) lines of information to your printer. If you have a dot matrix printer, that information starts printing out right away. If you have a page-oriented printer (laser, inkjet, etc.), nothing seems to happen except a blinking light on the printer.
Page printers, such as the LaserJet, are designed to image an entire page at one time, it assumes the page you're going to print is going to have a form feed character at the end of the page. If it doesn't, the printer will patiently wait until you have 60 lines (or so) and then automatically print the page because that's all that will fit on an 8.5 x 11 page.
It's just an inherent part of the printer design that it doesn't have a good way to tell that you only wanted to send the 24 lines of text just by "looking" at the 24 lines... it _has_ to wait for either the form feed or enough lines of text to fill the page.
If you look closely at a dot-matrix printer when you use print screen, you'll see that it's only printing 24 lines also, it's just we're so used to seeing the paper feed that we automatically see that as a "normal" action.
If after pressing print screen you wait a few seconds and press ONLINE then FORM FEED, you should get your one screen shot on one page. Don't forget to press the ONLINE button again to reconnect the printer to the computer.
There are some software programs you can run as TSRs which will modify printscreen to automatically send a FORM FEED character to the printer after you press print screen, but I've never used them so I can't really recommend one of them.