| Home |
| Classification |
| Languages |
| Interfaces |
| Drivers |
| Supplies |
| Troubleshooting |
| Costs |
| Miscellaneous |
| Vendors |
| Glossary/Credits |
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
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:".
See also the PostScript FAQ
ftp://wilma.cs.brown.edu/pub/comp.sources.postscript
for problems not covered here.
- 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.
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.
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.
From: David Byram-Wigfield, the author of 'PracticalPostScript'
ISBN 0-9525308-0-5
A PostScript Printer Test.
Type the following into a text editor and download using the
Adobe or Apple Downloaders, or Drop PS, or the BBEdit Extension
Send PostScript command.
The star shows the finest lines available and if you convert
the 50 value to 500 it will then show the default margins of
the printer. The grayscale wedge shows the quality of the
halftoning. 85 45 is the halftone screen; 148 18 is the size
of the wedge in points and 30 20 its position on the page.
Alter to suit. Increasing the 85 lpi value to 95 or 105 will
show when banding starts to set in. Count the bands to see
how many shades of gray the printer can support at that lineage.
The curious commands 'gsave' and 'grestore' isolate the little
procedures from each other.
%!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
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
- 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.
Return to Top of this page
| Home |
| Classification |
| Languages |
| Interfaces |
| Drivers |
| Supplies |
| Troubleshooting |
| Costs |
| Miscellaneous |
| Vendors |
| Glossary/Credits |
Last modified: 04 Jan 1997 - bcm