Warren said:
Given the lack of detail, it's hard to precisely. But here's a common
situation:
1. Computer says to the printer: "This is graphic data, print it as
dots" and starts sending data.
2. Printer loses power somehow. No one will admit to this.
3. Computer sees that printer isn't responding, stops sending data.
4. User turns printer back on.
5. Computer sees that printer is responding, resumes sending.
6. Printer interprets graphic data as text, prints "gibberish".
Repeat steps 2-6 until all data has been sent or user kills the job on
the computer.
A print job consists of a cohesive set of commands encapsulating the
data. The entire data stream is a single entity. If it's interrupted,
say through a power interruption, or network communication problem,
then all of the front-end setup commands may be lost. When
communication is restored, the printer may no longer knows what the job
was, and if the data stream is resumed part way through, the printer
will just default to plain text and interpret it as such, ergo, you get
gibberish. Since some of the commands are control characters (i.e. non
text characters in the ASCII x'00' thru x'1F' range), they'll print as
'weird' characters such as smiley faces, etc.
For most PDL's (Page Description Languages, e.g. PCL, PostScript, IPDS,
XES, Epson Escape Sequence, etc.), the entire print data stream must be
sent to, and received, in a single communication session. Any abnormal
interruption of this communication, other than that negotiated between
the host (server) and device (printer), could result in printing of
garbage...
Places I'd look, in order, would be:
- power cord
- power circuitry (first supply circuitry, then printer)
- network communication cables / lines
- any other component that could possibly be responsible for
interrupting communication (server fault, router/switch fault)
Bullitt
