spolsky-joel@CS.YALE.EDU (Joel Spolsky) (10/20/88)
I have a dumb question. Why does anybody bother to send complete bitmaps to laser printers, especially 2M bitmaps? wouldn't it be trivial to compress them for tranmission using ZLW or such? I'll bet you could get 90% compression or more for plain text. surely the time saved in transmission would pay for the compression time, especially if compression is implemented in hardware. Not to mention the savings in ethernet traffic on networks. +----------------+---------------------------------------------------+ | Joel Spolsky | bitnet: spolsky@yalecs uucp: ...!yale!spolsky | | | arpa: spolsky@yale.edu voicenet: 203-436-1483 | +----------------+---------------------------------------------------+ #include <disclaimer.h>
casey@admin.cognet.ucla.edu (Casey Leedom) (10/20/88)
| From: spolsky-joel@CS.YALE.EDU (Joel Spolsky) | | I have a dumb question. Why does anybody bother to send complete bitmaps | to laser printers, especially 2M bitmaps? Wouldn't it be trivial to | compress them for transmission using ZLW or such? I'll bet you could get | 90% compression or more for plain text. Surely the time saved in | transmission would pay for the compression time, especially if | compression is implemented in hardware. Not to mention the savings in | ethernet traffic on networks. Someone said earlier that the NeXT lpr transfers PostScript across the net, not bitmaps. Compressing the data stream to the laser printer would require that significantly complex hardware be put into the printer. This would in turn drive up the cost of the printer. At 300dpi the NeXT sends data to the printer at 1.8mbps and at 400dpi it transmits at 3.2mbps [1]. The fact that it transmits faster at the higher density indicates that the printing process is printer engine bound rather than data transfer bound. A quick check shows: 300dpi: 300x300 bits/inch^2 / 1.8e6 bits/second == 5e-2 seconds/inch^2 400dpi: 400x400 bits/inch/inch / 3.2e6 bits/second == 5e-2 seconds/inch^2 At a conservative 8.5 x 11 inch^2 / page (the whole page is not really printable, but I've forgotten what the minimum border is), this gives us 8.5 x 11 inch^2 x 5e-2 seconds/inch^2 == 4.675 seconds/page == 12.834 pages/minute I think the minimum border is something like 1/4 inch which gives a more realistic 4.2 seconds/page == 14.286 pages/minute. Casey [1] First Impressions - The NeXT Computer; Tom Thompson, Nick Baran; BYTE BIX, October 15, 1988 -------- The problems and issues are complex and inextricably linked: the national deficit, defense spending, foreign policy, the foreign trade deficit, the environment, homelessness, affordable health care, ... No simple answer will suffice. And yet Bush claims that things are fine and can be left as is. Where has he been for the last eight years??? Disneyland?
wb1j+@andrew.cmu.edu (William M. Bumgarner) (10/20/88)
There is no need to compress the BitMap for port blast to the printer-- the printer has it's on channel on the DSP that is very, very fast. The bottle neck is the printer itself-- it prints at 8 PPM, not because of data transfer, but because that is all the faster the Cannon print engine will print. I would suspect that the computer has to wait for the printer when blasting-- unless the printer has a 2+ meg buffer on board. b.bum wb1j+@andrew.cmu.edu
byron@pyr.gatech.EDU (Byron A Jeff) (10/20/88)
In article <40784@yale-celray.yale.UUCP> spolsky-joel@CS.YALE.EDU (Joel Spolsky) writes:
-I have a dumb question. Why does anybody bother to send complete
-bitmaps to laser printers, especially 2M bitmaps? wouldn't it be
-trivial to compress them for tranmission using ZLW or such? I'll bet
-you could get 90% compression or more for plain text. surely the time
-saved in transmission would pay for the compression time, especially
-if compression is implemented in hardware. Not to mention the savings
-in ethernet traffic on networks.
It's already been stated that the remote print servers will send postscript
to the machine with the printer and that machine creates the bitmap.
Software compression can be performed on both ends if you wish. In fact
the DSP chip can perform the operation without bothering the '030 much
at all.
Also the printer is assigned it's own DMA channel. The amount of data
being sent to printer doesn't slow the processor down at all.
And at 3M/sec (is this right?) for 400dpi bitmaps on an 8ppm printer
I don't think the size of the bitmaps is a bottleneck.
Is the "best" solution to have a real postcript printer that
has it's own DMA channel? Of course the price of that printer
will at least double the price of the printer. Aren't tradeoffs wonderful?
Compression requires smarts on the part of the printer which increases the
cost. And since the print engine is the bottleneck you get no increase
in print speed by doing so.
400dpi @ $2000 is absolutely nothing to complain about. I think the
current setup was a great idea. It's not necessary to outthink the bitmap
size, just outrun it.
If anything a faster printer would have been a nice. Do any current
laser printer engines run faster than 8ppm? How much do they cost?
-
-+----------------+---------------------------------------------------+
-| Joel Spolsky | bitnet: spolsky@yalecs uucp: ...!yale!spolsky |
-| | arpa: spolsky@yale.edu voicenet: 203-436-1483 |
-+----------------+---------------------------------------------------+
- #include <disclaimer.h>
--
Another random extraction from the mental bit stream of...
Byron A. Jeff
Georgia Tech, Atlanta GA 30332
Internet: byron@pyr.gatech.edu uucp: ...!gatech!pyr!byronsean@ms.uky.edu (Sean Casey) (10/22/88)
In article <gXLRbzy00UgXI4b39n@andrew.cmu.edu> wb1j+@andrew.cmu.edu (William M. Bumgarner) writes: >There is no need to compress the BitMap for port blast to the printer-- the >printer has it's on channel on the DSP that is very, very fast. The bottle >neck is the printer itself-- it prints at 8 PPM, not because of data transfer, >but because that is all the faster the Cannon print engine will print. I >would suspect that the computer has to wait for the printer when blasting-- >unless the printer has a 2+ meg buffer on board. There's always the problem of postscript having to generate complex pages. People seem to have forgotten the biggest complaint about postscript, it's lack of speed. I wonder how many here have had to wait a solid minute for a postscript printer to process a complex page. And this is a printer with it's cpu dedicated to processing postscript. It doesn't have to manage memory or run user processes at the same time. Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** The Hacker from Hell. {backbone|rutgers|uunet}!ukma!sean *** U of K, Lexington Kentucky, USA ..where christian movies are censored. *** ``The World... she's a flat! She's a round! Flat! Round! Flat! Round!''