Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Printer buffer: does size matter?

403 views
Skip to first unread message

Angus Rodgers

unread,
Nov 29, 2005, 3:50:46 PM11/29/05
to
Is buffer size ever a factor in choosing a laser printer for
use with LaTeX?

I usually print from the YAP previewer supplied with MiKTeX.

I've never had any problems using my HP DeskJet 690C inkjet
printer, but it is nearing the end of its working life, and
I want to replace it with a cheap laser printer.

The Samsung ML1610 laser printer that I'm considering has a
2MB buffer, which seems about half what is needed for an A4
page of monochrome graphics (at 600dpi) but I don't know if
this matters.
--
Angus Rodgers
(twirlip@ eats spam; reply to angusrod@)
Contains mild peril

Dan

unread,
Nov 30, 2005, 2:55:21 PM11/30/05
to

Angus Rodgers wrote:
> Is buffer size ever a factor in choosing a laser printer for
> use with LaTeX?
>
> I usually print from the YAP previewer supplied with MiKTeX.
>
> I've never had any problems using my HP DeskJet 690C inkjet
> printer, but it is nearing the end of its working life, and
> I want to replace it with a cheap laser printer.
>
> The Samsung ML1610 laser printer that I'm considering has a
> 2MB buffer, which seems about half what is needed for an A4
> page of monochrome graphics (at 600dpi) but I don't know if
> this matters.

Size used to matter for speed: with a big enough buffer, a program
could dump the whole document to the printer and continue working while
the printer put it on paper.

Nowadays, the print spooler takes the whole file and (if necessary)
feeds it to the printer as required. This frees your program even
faster than before since communication across a printer cable is
typically slower than communication between programs.

There is the possibility that the print spooler could consume resources
and slow the computer down. A large buffer could free up the spooler
sooner. Whether this is a problem depends on the driver supplied with
the printer. I have heard passionate complaints about some HP drivers,
but I don't remember any model names.

To be able to print a file, the printer needs enough memory to generate
one scan line for the laser. I suppose this might be as small as as one
pixel high by the width of a printable page, requiring about 4.8K, but
efficient engineering might require a larger scan line. I don't
actually know anything about that; it just seems a possibility.

Memory tends to be very cheap these days (a one gigabyte thumb drive
was just advertised for about $80, before rebates), so if the printer
allows memory upgrades, increasing it to several pages worth should
cost a few dollars to a few tens of dollars.


Dan

Patrick TJ McPhee

unread,
Dec 1, 2005, 12:04:03 AM12/1/05
to
In article <1133380521.5...@o13g2000cwo.googlegroups.com>,
Dan <luec...@uark.edu> wrote:

% To be able to print a file, the printer needs enough memory to generate
% one scan line for the laser.

To be able to print a page, a laser printer needs enough memory to
generate the page. This can be a lot or a little depending on how
the page is created. e.g., a page of text using printer fonts will
require little memory, while a page of layered graphics might
require a great deal.
--

Patrick TJ McPhee
North York Canada
pt...@interlog.com

Dan

unread,
Dec 1, 2005, 12:04:01 PM12/1/05
to

Patrick TJ McPhee wrote:
> In article <1133380521.5...@o13g2000cwo.googlegroups.com>,
> Dan <luec...@uark.edu> wrote:
>
> % To be able to print a file, the printer needs enough memory to generate
> % one scan line for the laser.
>
> To be able to print a page, a laser printer needs enough memory to
> generate the page. This can be a lot or a little depending on how
> the page is created. e.g., a page of text using printer fonts will
> require little memory, while a page of layered graphics might
> require a great deal.

I was speaking theoretically. I have no idea what the actual practice
is. But I would consider a printer badly designed if it had no way to
handle partial pages in its memory.

My understanding is that a laser is used to alter the surface of a
rotating drum and when the drum has an entire page, it is used to
transfer toner to paper. *If * the laser does the writing to the drum
a line at a time the printer *could* retrieve one line from the buffer
and, while sending that line to the drum, another *could* be sent to
the buffer (dot matrix printers would do the analogous thing directly
onto paper and get by with very small memory).

I do know that I have printed a full page graphic on printers with less
than 1MB of memory so there would seem to be some strategy to receive
less than a page at a time, or perhaps some compression scheme. In my
experience, almost never do printers just refuse (except some
postscript printers -- where any part of the PS code can alter any part
of the page), though often they slow down drastically.


Dan

Robert Heller

unread,
Dec 1, 2005, 1:23:39 PM12/1/05
to
"Dan" <luec...@uark.edu>,

Generally, a *laser Postscript* printer has a screen buffer, internal
working memory (for the postscript stacks, dictionaries, etc.), plus an
input buffer (fifo connected to the I/O port). At least this is what
it *logically* needs to have. Generally, the PostScript 'engine' is
running on some sort of embedded processors (some early models had a
68000 processor). This processor runs a program something like
ghostscript. How this relates to the 'buffer size' in the specs is not
clear and probably depends on how the internal processor's memory is
arranged. It could be that the 'screen buffer' is like video RAM - it
is not counted as part of main memory. Also the 'buffer' can be just
the memory directly connected to the I/O port, and the main memory and
'video RAM' are counted separately.

I don't think a *Postscript* can generate one scan line at a time -- the
Postscript language is 'random access' and can draw stuff all over the
page in any random order. A whole 'page' has to be buffered somehow.

Inkjets all do one head's worth of scans line at a time and when
converting from postscript to inkjet, generally via GhostScript,
the conversion program (GhostScript) has the page buffer in host
computer memory, which is then written line by line to the printer (via
a pipe or a file).


">
">
"> Dan
">
">

\/
Robert Heller ||InterNet: hel...@deepsoft.com
http://www.deepsoft.com/ ||FidoNet: 1:321/153
http://www.deepsoft.com/~heller /\



David Lloyd Geering

unread,
Dec 1, 2005, 3:30:29 PM12/1/05
to

A 600 d.p.i. monochrome laser printer would only require a single bit of
memory for each possible dot on the page. Pretend we are printing on A4
at 600 d.p.i (for consistency we will stick with Imperial).

A4 is 11.7 inches in height and 8.25 inches in width. At 600 d.p.i.,
that equals 7020 dots high and 4950 wide. These multiplied give
34,749,000. Divide that by 8 * 1024 ^ 2 to get roughly 4.14 megabytes.
This is assuming the printer can print right to the very margins of the
page. Wouldn't it require at least this much memory to print a full-page
graphic?

David.

Dan

unread,
Dec 1, 2005, 6:06:30 PM12/1/05
to

David Lloyd Geering wrote:
> Robert Heller wrote:
> > "Dan" <luec...@uark.edu>,
> > In a message on 1 Dec 2005 09:04:01 -0800, wrote :
> >
> > "> > Dan <luec...@uark.edu> wrote:
> > "> >
> > "> > % To be able to print a file, the printer needs enough memory to generate
> > "> > % one scan line for the laser.
> > "> >
[...]

> > "> I do know that I have printed a full page graphic on printers with less
> > "> than 1MB of memory so there would seem to be some strategy to receive
> > "> less than a page at a time, or perhaps some compression scheme. In my
> > "> experience, almost never do printers just refuse (except some
> > "> postscript printers -- where any part of the PS code can alter any part
> > "> of the page), though often they slow down drastically.

> > I don't think a *Postscript* can generate one scan line at a time -- the


> > Postscript language is 'random access' and can draw stuff all over the
> > page in any random order. A whole 'page' has to be buffered somehow.

That's _exactly_ what I said in my parenthetical remark..

> > Inkjets all do one head's worth of scans line at a time and when
> > converting from postscript to inkjet, generally via GhostScript,
> > the conversion program (GhostScript) has the page buffer in host
> > computer memory, which is then written line by line to the printer (via
> > a pipe or a file).

There exist laser printers without Postscript. There's no reason they
couldn't do the same as inkjets (theoretically).

>
> A 600 d.p.i. monochrome laser printer would only require a single bit of
> memory for each possible dot on the page. Pretend we are printing on A4
> at 600 d.p.i (for consistency we will stick with Imperial).
>
> A4 is 11.7 inches in height and 8.25 inches in width. At 600 d.p.i.,
> that equals 7020 dots high and 4950 wide. These multiplied give
> 34,749,000. Divide that by 8 * 1024 ^ 2 to get roughly 4.14 megabytes.
> This is assuming the printer can print right to the very margins of the
> page. Wouldn't it require at least this much memory to print a full-page
> graphic?

Only if the entire page has to be in the printer's memory at the same
time (as would be the case for a PS printer).

The laser _could_ access memory and draw a part of the page, during
which time the buffer could be emptied and another part of the page
downloaded to the printer.

Theoretically, the laser head only needs to know whether the current
dot is to be black or white: as you said one bit of memory. If that's
all there was, it would go very slowly requiring many (many, many :-)
requests for more data, so a print buffer is used.

A print buffer reduces the number of requests, and the buffer can be
refilled while the printer is processing the previous bufferful. Often
that means while one page is printing, the next is downloaded, BUT it
doesn't have to mean that. It COULD be that a part of a page is applied
to the drum while more of the same page is downloaded.


Dan

Michael Zedler

unread,
Dec 1, 2005, 6:31:38 PM12/1/05
to
Angus Rodgers schrieb:

> Is buffer size ever a factor in choosing a laser printer for
> use with LaTeX?

Depends on what is on the page. What hasn't been mentioned in the other
postings to this thread is that printers compress the data stored in
memory. So only if your page is highly complex (lots of different fonts
with many different glyphs used on that particular page, really complex
vector graphics) and/or badly compressable (e.g., high resolution tiff
photos) you won't be able to print it. For normal office-like use 2MB is
fine.

Michael

Patrick TJ McPhee

unread,
Dec 2, 2005, 12:09:33 AM12/2/05
to
In article <1133478390.8...@g47g2000cwa.googlegroups.com>,
Dan <luec...@uark.edu> wrote:

% There exist laser printers without Postscript. There's no reason they
% couldn't do the same as inkjets (theoretically).

I think in practice most current laser printers use either postscript,
PCL, or the windows printer thing. As I understand it, windows printers
are similar to your theoretical model. Postscript and PCL printers both
have to have the full page in memory before they start printing.

They use simple compression schemes to reduce the memory required to
hold the page image, but it used to be quite common for laserjets to
fail to render graphics-heavy pages due to memory constraints.

I've never had that problem with my laserjet 4p, which is 600dpi and has,
I think, 2 megs of memory.

Piet van Oostrum

unread,
Dec 1, 2005, 3:42:21 PM12/1/05
to
>>>>> Robert Heller <hel...@deepsoft.com> (RH) wrote:

>RH> I don't think a *Postscript* can generate one scan line at a time -- the
>RH> Postscript language is 'random access' and can draw stuff all over the
>RH> page in any random order. A whole 'page' has to be buffered somehow.

Modern Postscript printers should have sufficient memory for a page full of
pixels plus enough Postscript working memory (and usually enough for
multiple pages).

For a RIP that needs a very large number of pixels, such as high
resolution typesetters, Postscript has some provisions to do `banding',
AFAIK. This means that you buffer the Postscript input, and generate a band
of information, discarding the pixels that fall outside the band. While
this band is printed the next band is generated. In a laserprinter this
would be risky as you don't have any guarantee that the next band is ready
in time during the rotation of the drum.
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi...@vanoostrum.org

0 new messages