This might be of use to those printing out PostScript-rendered documentation (schematics, manuals, etc).
I've always had PostScript printers. They're particularly useful when producing documents that have to be sent to a service bureau for printing/publishing, because most commercial photosetting systems are PostScript-based. What I see at home is /exactly/ what the final document will look like.
I've been printing out user manuals -- four sheets to a page -- for my Olympus and Canon cameras. Canon will no longer sell user manuals, so having a printout is handy -- you don't have to worry about damaging or destroying the Canon original. And a binder with the pages in professional vinyl sheet protectors makes a handy field reference. You can write on the sheets, or stick PostIt notes on them, again without messing up the original.
Anyhow... I'd had no problems until I got to the EOS-1V manual. Some pages -- mostly those with halftones -- simply would not print. The printer (an HP 4M) would chug away "forever" to render the page, the Ready light blinking. Then the Ready light would come on steady -- indicating that the image was fully rendered -- but nothing would print.
To make a long story short, I read the PostScript Help, and (following its subtle "do this if everything else fails" suggestion) selected the "Print as bitmap" Advanced option. This sends the rendered bitmap -- not the PostScript commands -- to the printer.
Not only did every page print, but it printed more quickly. Apparently, the computer renders the image much more quickly than the processor in the printer. And it can render things the printer gets stuck with.
So... if you're having problems, switch to "Print as bitmap".
--
"We already know the answers -- we just haven\'t asked the right
questions." -- Edwin Land
Use a postscript renderer (i.e., a piece of software *in* the PC) instead of a postscript *printer*. Printers usually don't have the same horsepower available to them as modern PC's. You also have all of the PC's memory to exploit for this purpose (fonts, etc.).
The tradeoff is you now have to send an *image* of the page to the printer which is usually more data than using an abstract PDL.
Once the HP LaserJet printer did this, too. Kept locking up and failing, had to continually Power OFF reboot the printer. After installing a 'special' buffer driver from HP, worked great. It seems when the meory in the printer gets full [like when the PC runs faster than the printer], HP printer has the flawed response of locking up.
The 4M is a PostScript printer ("M" for "Macintosh") setting it apart from the regular LJ4. (Adding the "+" signifies a faster marking engine -- in the LJ4+ and LJ4M+)
[snip]
But you are still printing to a PostScript printer *encapsulating* the bitmap as a PostScript file. So, the printer has to treat it as such.
If you just use a generic PostScript interpreter talking to a
*non* PostScript printer, you can usually get faster throughput as non-postscript printers don't have the same overhead as PostScript (i.e., "PostScript" itself takes up memory in the printer). You can then print at the speed of the *marking* engine instead of the print engine.
Note that you can end up *losing* quality going this route as the marking engine doesn't know what was intended in the image -- it has to rely on the bitmap provided to it exclusively. Often, it is hard to pinpoint where the loss in quality comes from (e.g., some renderers can't handle beziers/splines as well as "genuine" PostScript does)
No, it's not. It's a way of describing what will be printed. This requires interpretation -- which is not the same as running a program. The interpretation produces a bitmap that the printer prints. (That's all it can print.)
PostScript natively supports bitmaps. When you dump a rendered page to the printer in PostScript bitmap format, all the printer has to do is transfer it to the drum. No interpretation is needed.
Read what you wrote: "PostScript" itself takes up memory in the printer." It takes up no memory.
PostScript is a *programming language*. When you send a PostScript file to a printer, you are sending a PROGRAM to a COMPUTER (which just so happens to *look* like a PRINTER!). The computer runs that program (interprets that program) and, based on what the program says, it *may* decide to put some marks on the paper.
I.e., I can send a PS file to a printer that includes a list of the amounts of all of the checks I had written in the past month and tell the *printer* ("computer") to sum these values and print the result with the words: "You wrote checks totaling $" in front of it.
With this in mind, when you send an "iimage" to a postscript printer, you are sending some representation of that image (consider this "data") along with a *program* that tells the computer (printer) how to interpret that data (image) and mark the paper accordingly.
You might want to check that again. On my old W2K machine, I can select "print as image" for any of the printers that I currently have installed. These include an LJ6P, LJ4M+ (ok, that's a PS printer so it doesn't count), DPP-EX50, several Epson printers, etc.
See the example below.
No, the *interpreter* is in ROM. But the interpreter needs RAM to remember what it is doing!
For the example I cited above: the PS file (program) is downloaded into the printer. It sits in RAM. Then, the interpreter starts up and "runs" the program in that PS file.
I took a single page B&W document (mostly text but a small photo and maybe a chart or somesuch). I printed it to a LJ6 printer "as an image". The result was 507KB.
I took the same single page and printed it to the "Generic Postscript Printer" (AdobePS driver) also as an image. I.e., this is what you get when you wrap that "507KB LJ6 image" in a PS format. The file was 2,873KB -- almost 6 times larger!
Finally, I took the same single page and printed it to the "Generic Postscript Printer" (AdobePS driver) but *not* as "an image". I.e., this is a genuine PS rendering of the page -- you can actually read the text that will be printed by examining the contents of the file. The result was 845KB.
So, if you are printing to a postscript printer, you are sending 845KB of data to the printer. From this, the printer will create the actual dots to fill the page. When you take the same document and print it "as an image" to the *same* postscript printer, then you send 2.8MB of data to do the same job!
If you look at the actual data being sent to these three printers, you will quickly see that the LJ6P data is very dense binary. OTOH, the PS data is more abstract (less dense) and easily readable:
To further illustrate the nature of the PS file as being a *program*, here are a few other "easy to understand" snipets from the same *document*:
/m {moveto} def /l {lineto} def /c {curveto} def
these three lines define the three symbols m, l and c to represent the moveto, lineto and curveto "commands". I.e., these are effectively *abbreviations*.
385 274 m
180 274 l
179 283 179 293 179 303 c
179 310 179 316 180 323 c
398 323 l
423 404 l
197 404 l
219 477 273 520 357 520 c
409 520 466 490 487 454 c
487 389 l
579 389 l
579 612 l
487 612 l
These lines then invoke each of these "commands" to make marks on the paper. The first statement moves from the "current location" (wherever that happens to be at the time) to the location (385, 274). From there, a line is drawn to the location (180, 274). Then, a Bezier curve is drawn to the point (179, 303) using the points (179, 283) and (179, 293) as control points to shape the curve. This is followed by more curves, lines, moves, etc.
The PostScript interpreter knows how to draw lines, make Bezier curves, etc. But, the software (in the interpreter) to draw these things needs memory to keep track of what it is doing -- how far along the line have I progressed? What difrection am I headed? Have I reached the end point yet? etc.
If you can tell me how this is done while consuming "zero memory"... ;-)
I don't know (and don't care at the moment to print a test page). I assume it's around 64MB. I don't think lack of memory is the problem -- after all, the printer had no trouble with a 22MB bitmap dump -- roughly 10 to 20 times what's required for "descriptive" PostScript. That's about one byte for each bit on a 300dpi 8x11 page.
This is getting out of hand. (Nothing personal, Michael.) There's sometimes little point in posting anything, because it's bound to be overanalyzed for all the WRONG reasons. The issue isn't that the printer couldn't handle plain PostScript, but rather that there was a SOLUTION to the problem. I wasn't asking for an analysis, but offering help.
From _The PostScript Language Reference Manual (2nd Ed)_ by Adobe Systems Incorporated, Page 1, first sentencce:
"The PostScript language is a simple INTERPRETIVE PROGRAMMING LANGUAGE (emphasis mine) with powerful graphics capabilities.
I stand by my statement. :>
No, you are mistaken. It *is* a program. Just like BASIC was a programming language that was *typically* interpreted. As I stated in previous post: I can send a PS *program* to the printer that balances my checkbook! It need not even print the balance as a set of numeric digits. It could, for example, eject N sheets of paper where N is the number of dollars remaining in my checking account! (though it seems like simply printing the balance would be easier)
Do yourself a favor and *read* the language specification. Read some PS "code" (files). It is a simple S-machine language -- easy to implement.
PostScript uses the memory to run itself. I.e., if you have a 600dpi printer, you should never need more than 4MB in your printer! Just buffer up the image and then pass it on to the marking engine.
I can create a 300MB PS file that does nothing more than print a single dot.
I can create a 1KB PS file that will pring 5,000 pages!
I can write a PS file that just sits and tries to compute Pi and never prints *anything*.
As I -- and Adobe -- have said, PS is a programming language. As such, there are variables, control structures, pushdown stack, etc. All of these reside in memory and are NOT "dots". So, they aren't part of the image. They are memory that "PostScript itself takes up ... in the printer."
Here's a program to calculate pi -- try doing in that in PCL5:
%!PS-Adobe-2.0 %%Title: Calculate Pi in PostScript %%Creator: Frank Martin Siegert [ snipped-for-privacy@this.net] -
formatting link
%%Date: 23. November 1996 02:23 % Updated 2. April 1998 23:40 %%BoundingBox: 0 0 592 792 %%DocumentNeededFonts: Courier Courier-Bold %%EndComments
% Enter your desired number of digits here, min. 20, max. 262136 % Be prepared to wait a long time for anything > 1000
/ndigits 1000 def
% If your printer fails with a timeout error try to uncomment the next line % this will give you one hour extra time...
% Define bigmath routines - still a bit suboptimal % (direct ported from the C implementation by Roy Williams)
/bigadd { % increment result /result exch store /increment exch store 0 1 nblock 1 sub { nblock exch sub /i exch store result i get increment i get add dup base ge { base sub result exch i exch put result dup i 1 sub get 1 add i 1 sub exch put } { result exch i exch put } ifelse } for } bind def
/bigsub { % decrement result /result exch store /decrement exch store 0 1 nblock 1 sub { nblock exch sub /i exch store result i get decrement i get sub dup 0 lt { base add result exch i exch put result dup i 1 sub get 1 sub i 1 sub exch put } { result exch i exch put } ifelse } for } bind def
/bigmult { % factor result /carry 0 store /result exch store /factor exch store 0 1 nblock { nblock exch sub /i exch store result i get factor mul carry add dup /carry exch base idiv store base mod result exch i exch put } for } bind def
/bigdiv { % denom result /carry 0 store /result exch store /denom exch store 0 1 nblock { /i exch store result i get carry base mul add dup denom mod /carry exch store denom idiv result exch i exch put } for } bind def
/bigset { % rhs result /result exch store /rhs exch store 0 1 nblock { result exch 0 put } for result 0 rhs put } bind def
/bigzero { % result /result exch store 1 0 1 nblock { result exch get 0 ne { pop 0 exit } if } for } bind def
/bigcopy { % from result copy pop } bind def /bigprint { % result /result exch store bigfont result 0 get str4 cvs onpage smallfont (.) onpage 1 1 nblock { result exch get str4 cvs resstr 0 (0000) putinterval resstr exch dup length 4 exch sub exch putinterval resstr onpage } for } bind def /bigatan { % onestep denom w2 w1 result /result2 exch store /w1 exch store /w2 exch store /denom exch store /denom2 denom denom mul store /onestep exch store /k 1 def 1 result2 bigset denom result2 bigdiv result2 w1 bigcopy { onestep 0 ne { denom2 w1 bigdiv } { denom w1 bigdiv denom w1 bigdiv } ifelse
w1 w2 bigcopy k 2 mul 1 add w2 bigdiv k 2 mod 0 ne { w2 result2 bigsub } { w2 result2 bigadd } ifelse /k k 1 add store w2 bigzero 1 eq { exit } if
} loop } bind def
% Define output routines
/didpaint false def /onpage { /didpaint true store show currentpoint exch pagewidth ge { pagemargin exch lineheight sub moveto currentpoint exch pop pagemargin le { showpage pagemargin pageheight moveto /didpaint false store } if } { pop } ifelse } bind def
% Using Machin's formula: pi/4 = 4 arctan(1/5) - arctan(1/239)
1 5 t2 t1 tot bigatan 4 tot bigmult 2 239 t2 t1 t3 bigatan t3 tot bigsub 4 tot bigmult tot bigprint
Standard RAM for the HP4m is 6 MBytes. I used one in the office for a few year. It's also slow (8 ppm). With only 6MB of RAM, I could barely print anything from my office Mac Cube. It would frequently spend 10-15 minutes uploading some gigantic file, and then just quit. Maximum RAM for the HP4m with the Postscribble (Level 2) SIMM installed is 26MBytes. If you have an HP4m+, it will take up to
50MBytes. If you have some Fast Page Mode SIMMs, they should work. I loaded mine with something less than 26MB (I forgot the exact amount) and still managed to over flow the buffer.
Also, if you're using Windoze, go to the properties for the print driver and tell it how much RAM you have installed. The HP4m will not return config info to the driver. If you forget to do that, the Windoze driver will default to 2MB and your printing performance (and reliability) will suffer.
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS
The problems you pointed out are common with too little RAM.
I have several older laser printers with 2 MB (or less) of RAM that are only good for text. Any graphics look like crap, because there isn't enough RAM to properly render the postscript. One was an IBM 4019. I used it for a text only printer for over five years, till the fuser failed. I wasn't going to spend over $200 to fix a printer I bought for $10 with an almost full toner cartridge.
--
The movie \'Deliverance\' isn\'t a documentary!
Thanks for the suggestions. However, the driver has dialog boxes have no memory-size settings.
I went to a site that sould HP printer accessories, and the standard RAM size seems to be 16MB. What the default it, I don't know.
The printer had no trouble with 22MB bitmap files. (That's the size the spooler reported.)
I'll pull out the manual and check, but at the moment there's no need for me to upgrade the memory. With my luck, the printer will completely fail one week after I install the expanded RAM.
I wouldn't mind having a faster printer, but the 4M is such a good product, that I have no intention of ever giving it up, until it can't be repaired or cartridges aren't available.
But I've been using the printer ever since it was introduced without problems. (I had the LJ II and LJ III prior to that.) And I've been printing pages with complex graphics all that time, including my own documents, and the manuals for the Olympus E-500 and Canon 5D2. The Canon 1V manual is the first document that has ever caused this problem.
I finally gave up and printed the Self Test page. Total RAM is 6144KB. The PS Configuration page reports Global memory as 2308796 bytes and Local as
1530752 bytes.
Considering how cheap 16MB of RAM is ($8), perhaps I should add some.
William, printers don't use standard RAM. It has to match the printer. Your manual should list the HP part numbers that are compatible. If not, there should be a number starting with 'C' on your printer that is the actual HP number. C2066A is the part number listed on the HP website for that printer. I would keep an eye out for older HP laser printers people are junking. That module is used in a number of HP models.
formatting link
is a listing of the common HP models, but I haven't verified all this information.'
--
The movie \'Deliverance\' isn\'t a documentary!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.