Monday 24 November 2008 — This is over 14 years old, but it's still good.
Another story from printer-land of 20 years ago: this time about a seemingly impossible bug.
While working on the LPS-20 PostScript software, a bug was filed that said roughly,
Print the attached file. The LPS-20 will jam. You’ll have to open the printer to remove the scrunched up paper.
We were no strangers to jammed printers, but a particular file that could jam the printer? Yeah, right. It was crazy.
I printed the file. The printer jammed! I cleared the jam, printed the file again, it jammed again. I printed a different file, it printed fine. I printed a third file, it printed fine. Printed the bug report file again, the printer jammed, WTF!? How can a file reliably cause a printer to jam?
The mystery in this case was solved by the hardware team, because while we software guys were working on the software that fed PostScript files to the printer, the hardware guys were still getting the kinks out of the printer itself.
A laser printer has a drum on which the image is formed, and then used to transfer the image to the paper. In a 20 ppm printer like the LPS-20, the drum rotates once every three seconds. With a PostScript printer, a page could take an arbitrary amount of time to render. If the page takes less than three seconds to render, then the drum will rotate at full speed, with no pauses.
But if the PostScript interpreter takes longer than three seconds to finish a page, then the drum has to stop and wait for the image to be ready. Starting and stopping the drum and all the associated feed machinery is not trivial to get right.
In the case of the bug report file, the page took longer than three seconds, but only slightly longer, so not only did the drum have to stop, but it hadn’t quite totally stopped before it was started again. That mechanical edge case is what made the printer jam. The file had pages that took just the right amount of time to hit a bad timing window in the drive train firmware, and the printer jammed every time. Once the hardware guys adjusted the firmware, the problem went away.
- Just because a bug seems impossible doesn’t mean it is.
- Abstractions are everywhere, and they can be broken. As a software guy, I believed that getting the paper into the output tray was a solved problem.
1403s had another peculiarity. There was a paper tape that told the printer where the top of page was. An eject command caused the printer to space the paper forward until the tape (moving at the same speed) indicated the top of the next page. If the tape broke, the paper would eject at high speed...generally most of a box of paper (2000 sheets) would eject before the operator noticed it.
I don't know when IBM discontinued the 1403, but a Google search just now revealed several companies that sell ribbon cartridges for them.
"Another story from printer-land of 20 years ago"
Things were not as fast then.
About why the file would take 3 seconds to execute: not only were things not as fast then as now, but PostScript is a Turing-complete programming language. You can construct a file to take as long as you like.
As I recall, the file was a TeX output file full of Type3 bitmap fonts. Perhaps that had something to do with the complexity.
The 500 mile email. A Classic!
"wednesday" and "september" are the two longest day and month names.
The emails you send in 'Email me future comments' appears to be broken. I am using Evolution as my email client that does not seem to like HTML mail, and you don't send a plain version - so I cannot easily read these emails.
I found your blog through a reference on Gruber's blog. Quite a blast from the past.
Your right but your wrong, its not windows networking, its called having a Print Server. The driver is downloaded to your machine from the print server, and when you print the document is converted into the output file that the print driver would create and sends it to the printer THROUGH the print server. SO you are right, but you said windows networking as if it has anything to do with your print driver or the process of printing. Microsoft Networking is just the general name that all the different components of networking fall under.
Oh, for files that only took three seconds.
I worked on desktop publishing software that printed to some of the early hi-res filmsetters using a PostScript RIP. It was normal to print a 32 page tabloid document and wait an hour or two for all of it to finish. Sometimes, a single complex page done in Adobe Illustrator, or its then competitor, FreeHand, would take an overnight shift to output. Worse, it might run for several hours then die when the RIP ran out of memory and/or temp disk space. Good times.
> PostScript is a Turing-complete programming language.
My first programming language was PostScript. I learned while working as a QA tester, by debugging and optimizing PS routines in some of our products. Long story on why I had to do that instead of just demonstrate the issue and send it back to engineering.
It warps you for life, sort of like if your cradle language was pig-latin.
Thanks for the trip down memory lane.
But on a closer note - back at McDonnell-Douglas in late 70's a legend was that someone figured out the arm movement speeds on an old hard disk (IBM 3380?) and and set up a program to seek back and forth at high speed and start moving the disk drive unit across the floor, like a washing machine that is unbalanced. Never saw it happen.
I wonder what would happen if you sent that same text over and over, with no paper feed, and each time shifting the text one character in the direction the band or chain was moving--until you'd made two or three complete cycles through the character set?
And on the dot-matrix graphic line printers like the Printronix P600 or the DEC-branded LG02, you could tell whenever the printer drew a horizontal line by the "bzzzt" that was a little louder than usual.
@galen: we called them `carriage control tapes'. I don't know if there was an official IBM name for them. My memory is hazy now, but I believe the early ones were indeed paper. Maybe later 1403 carriage control tapes were Mylar too.
PS is a turing complete language (as noted above), and in those days ran on a 4Mhz 68000 -- hence, pretty slow. At one point, it was considered grand fun to write ray tracers in PostScript, which were programs that would render within the memory of the printer, and then print out the resultant image.
It took hours and hours of time to run programs that were under a page long. Irritated the hell out of the admins...
I was working for QualityLogic (formerly Genoa), a company that produced, among other things, certification tests for page description languages. Without boring you with the details, these tests just ran through each command in a PDL and exercised it six ways from Sunday.
Anyway, I was working on an upgrade to an HP PCL-XL test, and I came to the command (I don't recall the name off the top of my head) that set the color mode for printing bitmaps. This command actually did TWO things: it set the color mode to either indexed or direct, and it created a palette in memory.
Now, if you had set the color mode to direct, the palette was pointless, the color information came from the bitmap. So I figured it would be a good test to try poking various colors into the palette with direct mode set, and verify that the palette colors had no effect on the printed image.
And sure enough, on our reference printer (some HP color Laser Jet model), the command worked exactly as expected.
Our test pages had several pre-defined cells per page for separate tests, so I created a few tests that poked various colors into the palette, and verified that none of them affected the output.
Then I noticed I had one cell left on the page, so just for grins, I used it to set a palette that was all grays (ie, the R, G, and B values were equal).
The image didn't print. All the other tests on the page (the ones with non-gray palettes) printed. Just not the grayscale test.
I thought I'd made some kind of mistake, so I tried it again, with a different set of grays.
The image didn't print.
I tried a whole series of grayscale palettes, and in every case, the image didn't print. But when I inserted just ONE non-gray color into the palette, the image printed just fine. If I altered a gray by so much as +/-1 in any channel, the image printed. If I mixed gray and non-gray tests on a page, all of the non-gray tests printed fine, none of the gray ones did.
Unfortunately, since what I was doing was essentially black-box testing, I never got a chance to see the source code for the printer, so I have no idea what caused this. If you told me to write a command that would *deliberately* do this, it would be trivial. But if you wanted a command that was supposedly properly-written, yet had this as a side-effect, I wouldn't even know where to start.
That is, IF they even bother to let it get that far.
Lord help us all.
The oddest problem I saw on a LPS20, was a paper jam error on every page. It turned out the paper was A4, but the printer was set for A5, and complained that each page took too long to exit the printer!
Don't get me started on old disk drives!
most HP B&W LaserJet printers to lock up, requiring a power-off cycle to
clear. It was a color operator that was not properly handled by the
I reported the bug, but for some reason HP was reluctant to issue
fixes for all their Postscript printers. :-)
Reinstalled the Office didn't seem to solve the problem. I have no idea at all.
We have a spare printer now as we purchased a new 8600 pro as our other printers were apparently broken!
I will ave to spend some time with this document finding out how it does it.
Add a comment: