OT: printing PostScript files

[William Sommerwerck]

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

 

[William Sommerwerck]

Great information -- I like paper copies, but some manuals
are too big to waste paper. Four per page is the only reasonble
way and using bitmap is fine.

I goofed. It's actually "Print as image" -- same difference.

Part of the problem is that when you print four to a page, you have to
render four pages, rather than just one. This slows down the process.

 

[hr(bob) hofmann@att.net]

On Nov 13, 11:14 am, "William Sommerwerck"
<grizzledgee...@comcast.net> wrote:

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

Great information - I like paper copies, but some manuals are too big
to waste paper. 4 per page is the only reasonble way and using bitmap
is fine.

 

[William Sommerwerck]

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.).

That's exactly what I wrote. QV

 

[D Yuniskis]

William Sommerwerck wrote:

Great information -- I like paper copies, but some manuals
are too big to waste paper. Four per page is the only reasonble
way and using bitmap is fine.

I goofed. It's actually "Print as image" -- same difference.

Part of the problem is that when you print four to a page, you have to
render four pages, rather than just one. This slows down the process.

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.

 

[Robert Macy]

On Nov 13, 9:59 am, "William Sommerwerck" <grizzledgee...@comcast.net>
wrote:

Great information -- I like paper copies, but some manuals
are too big to waste paper. Four per page is the only reasonble
way and using bitmap is fine.

I goofed. It's actually "Print as image" -- same difference.

Part of the problem is that when you print four to a page, you have to
render four pages, rather than just one. This slows down the process.

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.

 

[D Yuniskis]

William Sommerwerck wrote:

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.).

That's exactly what I wrote. QV

Sorry, I have perhaps not been clear enough...

(below)

I've always had PostScript printers.

[snip]

The printer (an HP 4M) would chug away "forever" to render
the page, the Ready light blinking.

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]

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.

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)

 

[William Sommerwerck]

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.

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.

But it doesn't have to /render/ anything -- just dump the bits to the drum.

If you just use a generic PostScript interpreter talking to a
*non* PostScript printer...

That won't work.

This "Print as image" is available only for the PostScript driver.

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).

No, it doesn't. It's in ROM, and "consumes" zero memory.

 

[Michael A. Terrell]

William Sommerwerck wrote:

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".

How much memory does the 4M printer have?


--
The movie 'Deliverance' isn't a documentary!

 

[William Sommerwerck]

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.

But it doesn't have to /render/ anything -- just dump the bits to the
drum.

PostScript is a *programming language*.

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.

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).

No, it doesn't. It's in ROM, and "consumes" zero memory.

No, the *interpreter* is in ROM. But the interpreter needs
RAM to remember what it is doing!

Read what you wrote: "PostScript" itself takes up memory in the printer." It
takes up no memory.

 

[D Yuniskis]

William Sommerwerck wrote:

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.

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.

But it doesn't have to /render/ anything -- just dump the bits to the drum.

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.

If you just use a generic PostScript interpreter talking to a
*non* PostScript printer...

That won't work.

This "Print as image" is available only for the PostScript driver.

<grin> 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.

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).

No, it doesn't. It's in ROM, and "consumes" zero memory.

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:

===================
%!PS-Adobe-3.0
%%Title: PAXI 02021.pdf
%%Creator: PScript5.dll Version 5.2
%%CreationDate: 11/13/2009 16:49:56
%%For: Administrator
%%BoundingBox: (atend)
%%Pages: (atend)
%%Orientation: Portrait
%%PageOrder: Special
%%DocumentNeededResources: (atend)
%%DocumentSuppliedResources: (atend)
%%DocumentData: Clean7Bit
%%TargetDevice: (Generic PostScript Printer) (2010.0) 2
%%LanguageLevel: 2
%%EndComments

%%BeginDefaults
%%PageBoundingBox: 18 8 593 784
%%ViewingOrientation: 1 0 0 1
%%EndDefaults


%%BeginProlog
%%BeginResource: file Pscript_WinNT_ErrorHandler 5.0 0
/currentpacking where{pop/oldpack currentpacking def/setpacking
where{pop false
setpacking}if}if/$brkpage 64 dict def $brkpage begin/prnt{dup
type/stringtype
ne{=string cvs}if dup length 6 mul/tx exch def/ty 10 def
currentpoint/toy exch

....
===========

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"... ;-)

 

[William Sommerwerck]

memory does the 4M printer have?

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.

 

[D Yuniskis]

William Sommerwerck wrote:

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.

But it doesn't have to /render/ anything -- just dump the bits to the
drum.

PostScript is a *programming language*.

No, it's not.

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. :>

It's a way of describing what will be printed. This requires
interpretation -- which is not the same as running a program. The

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)

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.

Do yourself a favor and *read* the language specification.
Read some PS "code" (files). It is a simple S-machine
language -- easy to implement.

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).

No, it doesn't. It's in ROM, and "consumes" zero memory.

No, the *interpreter* is in ROM. But the interpreter needs
RAM to remember what it is doing!

Read what you wrote: "PostScript" itself takes up memory in the printer." It
takes up no memory.

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 [frank@this.net] - http://www.this.net/
%%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...

% statusdict begin 3600 setjobtimeout end


% Some defines for startup

/i 0 def
/str4 4 string def
/nblock ndigits 4 idiv 2 sub def
/t1 nblock 1 add array def
/t2 nblock 1 add array def
/t3 nblock 1 add array def
/tot nblock 1 add array def
/base 10000 def
/resstr 4 string def

% Define the page sizes and margins

/pagemargin 60 def
/lineheight 12 def
/pageheight 792 lineheight sub pagemargin sub def
/pagewidth 592 pagemargin sub def
pagemargin pageheight moveto
/bigfont {
/Courier-Bold findfont 36 scalefont setfont
} bind def
/smallfont {
/Courier findfont 12 scalefont setfont
} bind def

/scratch 16 string def

% 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

didpaint { showpage } if

%%EOF

 

[Jeff Liebermann]

On Fri, 13 Nov 2009 16:53:39 -0800, "William Sommerwerck"
<grizzledgeezer@comcast.net> wrote:

memory does the 4M printer have?

I don't know (and don't care at the moment to print a test page). I assume
it's around 64MB.

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

 

[Michael A. Terrell]

William Sommerwerck wrote:

How much [RAM] memory does the 4M printer have?

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.

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!

 

[William Sommerwerck]

I don't know (and don't care at the moment to print a test page).
I assume it's around 64MB.

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.

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.

 

[William Sommerwerck]

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.

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.

 

[Michael A. Terrell]

William Sommerwerck wrote:

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.

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.

http://www.hpprintermemory.com/hpprintermemory.html is a listing of
the common HP models, but I haven't verified all this information.'


--
The movie 'Deliverance' isn't a documentary!

 

[William Sommerwerck]

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.

I know that. I was looking at sites that specifically sold RAM for printers.

I have a service manual, which gives all the correct part numbers.

 

[AZ Nomad]

On Sat, 14 Nov 2009 06:53:38 -0800, William Sommerwerck <grizzledgeezer@comcast.net> wrote:

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.

I know that. I was looking at sites that specifically sold RAM for printers.

I have a service manual, which gives all the correct part numbers.

go to google and search for the part number