41

The first HP Laserjet only had 128K of memory. To print an area of 7.5 by 10 inches at 300 DPI requires 844K if it's kept as a single bitmapped image. Obviously they were doing something clever to minimize the hardware requirements, but was it ever described anywhere?

10
  • 5
    I do remember that our old Laserjet 4L with the minimum 1 MB memory would fail if one tried to print a large bitmap file - it would print out just the beginning of it and the rest of the page would be blank. – jpa Apr 13 at 10:27
  • 3
    Weren't those old printers strictly black and white? Like not even greyscale, just black or white. That would significantly reduce the size of the data... – Darrel Hoffman Apr 13 at 13:49
  • 7
    I think you might be attributing the Apple LaserWriter specifications (1.5MB and a 12 MHz 68K CPU) to the inferior HP Laserjet. If you aren't asking the printer to process a page description language, like Postscript, then the printer just needs to paint text glyphs into a bitmap buffer fast enough to keep up with the drum rotation. – Brian H Apr 13 at 14:07
  • 5
    @DarrelHoffman are there any laser printers even today that can do greyscale? My calculation of 844K was with one bit per pixel. – Mark Ransom Apr 13 at 15:11
  • 2
    @BrianH I believe the original Laserjet could also print arbitrary graphics, and I know the Laserjet II could. But painting glyphs into a buffer at high speed isn't a trivial thing either, I was wondering if the process was ever documented. – Mark Ransom Apr 13 at 15:14

11 Answers 11

42

To print an area of 7.5 by 10 inches at 300 DPI requires 844K if it's kept as a single bitmapped image.

Does it? Maybe.

Then again one cold think of many simple ways (like RLL) to compress a rendered image fast and decompress it at a speed quite capable to keep up with the print-'head'.

Obviously they were doing something clever to minimize the hardware requirements, but was it ever described anywhere?

Not sure what 'clever' thing is there to be done. Laser printers operate in a line by line base. Much like a TV, which as well needs zero buffer RAM. Of course in a digital environment it's handy to do this on a line by line base, so having the data for a whole scan line prepared before it's drawn, and prepare the next while that one is outputted. Much like double buffering is used in games to give a smooth screen.

With 300 DPI that's about 7 times 300 = 2100 bits, or less than 300 bytes. Times 2 gives less than 1 KiB as preparation and scan buffer.

Beside that, printers are meant to print text. That's as well true for laser printers. So all the task needs is a buffer with the actual line of text. Having that it transforms the character codes one by one into the dot image for that character and hands it over to the scan process modulating the laser beam. This gets repeated for the same line until all sub (scan) lines are done - again much like with a classic video card.

A line of text is most likely less than 200 bytes, so let's make that another KiB including double buffering.

Having the next line at hand before the last is exhausted is again an advantage. In fact, considering the usual comparably slow interface speed back then - serial 9,600 for a laser wasn't uncommon slow - it did help having the whole page already transmitted (*1. So for regular text that's less than 6 Kib, but for the sake (and the way I used my first one in 1984 *2) lets assume 100 lines of 140 characters, so 14 KiB.

And let's use double buffering again, for whatever reason, making it 28 KiB.

With the scan buffers and memory management and whatsoever that comes down to needed RAM size of 32 KiB for a working laser printer.

A laser does only need to buffer a single page, as it can quite well stop between pages. The original HP Laserjet came in 1984 with 128 KiB. That's plenty to store several pages of text, including format control and maybe even some small graphics - which in turn would as well be rather low in memory usage, as no software would consider more than like 72 DPI

Yes, I already see the 'BUT', but hold it and think about. Back then PCs didn't bur out whole pages in bitmap - that would not only have been slow but as well looked quite ugly (*3). It was about text. Everything else were niche applications (*4).

It was text, and it stayed that for quite some time - at least in a professional environment - the one able to afford a laser in the first place (*5). Two years after the LJ, the LJ+ was introduced, bringing 512 KiB of RAM and optional parallel interface (*1). While RAM had become quite less expensive, HP raised the price by about 1k USD, rectified that it now could print full resolution graphics up to two third the size of a page.

There was no postscript or any similar document language. It was simple serial data, much like the generation before. Text was transferred as ASCII, embraced by escape sequences for attributes like underlined, bold or maybe a second font, and graphics were delivered as 8 bits at a time, interpreted according to previous resolution setting.

It wasn't until another year or so later that the high end models could be expanded to a megabyte and being able to deliver a whole page of graphics. Of course after waiting of 5-10 minutes for transferring the data :)

Postscript as a built in feature was again several years later, ca 1990 or 1991.

Long story short, never implicit assume today's use case for yesterdays devices.


*1 - Speed is not just an issue of the printer receiving, but as well of the computer sending. But in this case, the LaserJet had already a hard time to keep up with text at 9,600. It could take image data a bit faster, but so make it worthwhile.

The LJ+ could optionally be fitted with a parallel interface, but that wasn't faster at all. While it peaked out at 80 KiB/s, average speed was much like with 9,600 serial.

The speed wasn't much of an issue. At 9600 a filled text page could be send in less than 10 seconds, so still faster than it could print. Of course, with graphics that changed a bit :))

*2 - To print Assembler listings from our mainframe - it did quite well with the smallest front readable. After all, most important in a listing is to have as much visible at first sight, to avoid paging.

*3 - That was one of the main drawbacks of early Macintosh and one reason for its bad sales. Graphics were great and looked awesome, but text simply sucked. build in fonts, at least for better printers looked several times better than what the Mac produced.

*4 - There were of course applications, and theyused massive enhanced printers.

*5 - Original first HP LJ in 1984 was around 3.5 kUSD

1
26

In addition to Raffzahn's usual excellent answer, a few important things to note:

  1. PCL still exists. You can (I do...) still write software that sends simple PCL commands to a printer to select fonts, print text, etc. Sending an entire page, of text, as a bitmap to a printer is the way GDI printers work - and is a Very Bad Thing.

  2. The original HP LaserJet had a few built-in bitmap fonts. Scalable fonts required both more memory and more CPU speed, and they came later. Downloadable bitmap fonts came later (and they still work). In ye olden days, if you wanted additional fonts, you got them on a ROM cartridge. Probably the most famous was a cartridge with tax fonts so that you could do the magical task of creating pixel-perfect IRS tax forms without graphics. That seems like no big deal today, but in the mid-1980s it was groundbreaking, and it didn't need tons of memory.

  3. After the LaserJet series evolved to have enough memory for full-page bitmapped graphics, along came the DeskJet (inkjet) series for the budget side of things. This repeated the original problem of memory limitations. In fact, the first DeskJet couldn't print landscape format, and I am pretty sure that is because of this same memory limitation. (I'm actually not sure how they handled landscape in the original LaserJet.)

  4. A real 300-dpi resolution resulted in the best text (except perhaps a daisywheel) on a computer, short of a typesetting (film-based) system. Being able to produce fully formatted high-quality output at 6 pages per minute was incredible! This compared really well to:

  • daisywheel printers (incredibly slow)
  • line printers (yes, you could hook up a big line printer to a PC, but they were moderate quality - fully formed characters but typically fixed pitch and only one font optimized for readability and not "style")
  • dot-matrix printers - decent speed in low quality, low speed in high-quality, and the high-quality was nowhere near true 300-dpi

Printing fancy graphics just wasn't as much of an issue. Consider that the typical business display was EGA 640x350 16 colors or Hercules 720x348. Besides, if your computer didn't even have 1 Meg. of RAM, why would your printer?

7
  • 4
    Thanks for mentioning GDI. I did remove that, 'cause I expected my usual comment about how useful it is to fall not well with everyone :)) landscape was done 'left to right' so essentially using a 'horizontal' character buffer. Learned that by doing a font cartridge to fast printing of 64 level gray scale pictures (essentially four font with two sets of 64 character each, giving 8 possible rasterisations per 'pixel' , selected by random to minimize artefacts - so output was strictly a fixed font text :)) – Raffzahn Apr 12 at 21:28
  • 4
    One time I had a customer who decided to save me some trouble by picking up an additional laser (Brother) and have me hook it up to my medical records system when I was on-site. I hook it up, Windows prints, my software doesn't print! Turns out it was a GDI - for very little more (I think like $20 at the time) they could have gotten the next model up (same speed, paper handling, etc. but with PCL instead of GDI) and everything would have been fine - they wasted more than that on my time hooking up the "wrong" printer. All because they didn't ask me first what printer to get. – manassehkatz-Moving 2 Codidact Apr 12 at 21:33
  • 2
    About 15 years ago I worked at a place that used a ROM cartridge font to do barcode printing. One of my tasks was to replace those font sequences with a graphic, because the cartridges and/or printers were becoming impossible to find. – Mark Ransom Apr 12 at 22:55
  • 2
    @manassehkatz-Moving2Codidact the software that needed the barcodes wasn't easily modified to download the fonts. And we used the opportunity to introduce other features, including a different barcode symbology. – Mark Ransom Apr 13 at 0:27
  • 6
    Bit OT, but take for example a word-processor like WordPerefect on MS-DOS... It certainly wasn't WYSIWYG! Instead, you had ordinary text (no special font) with things like colour-inversion, coloured text and cloured blocks around text to show where text was bold, slanted or underlined, or where you used another font. First after you'd printed it, you saw how it really looked. – Baard Kopperud Apr 13 at 12:16
12

To add to the other answers: Under Windows and GEM, printer drivers could store the current page as a metafile and rasterize it repeatedly as a series of horizontal bands, each band being large enough to fit into printer memory. This was slower than sending the data directly to the printer (since each page had to be rasterized repeatedly) but allowed an entire page of bitmap data when this was larger than the memory available to the printer.

Microsoft Knowledge Base article Q75471 gives an outline of the process for Windows.

14
  • 1
    That's interesting, thanks. But the printer couldn't pause once it started printing a page, so how did it ensure the data for the second band had been received by the time it exposed the drum for the first? – Mark Ransom Apr 13 at 0:31
  • 3
    This is GDI. Which works relatively well for dot-matrix and inkjet printers. For laser printers, because of the timing issue (as noted, "printer couldn't pause once it started printing a page") really only works with either a printer with a full page buffer (typically 1 Meg., i.e., not the first couple of HP LaserJet generations) or a relatively high-speed interface (8 ppm = ~ 8 seconds, 1 Meg. = 125 kbytes/second - a lot more than standard serial interfaces and even the typical 1980s parallel port). – manassehkatz-Moving 2 Codidact Apr 13 at 2:30
  • 2
    Macintosh could also do banding. – DrSheldon Apr 13 at 3:18
  • @DrSheldon: I use a similar approach to handle screen layout on a 128x64 LCD with a PIC, using 256 bytes of buffering to render 8-pixel vertical stripes (having an extra 8 pixels of height on the stripe buffer greatly facilitates placement of 8-pixel font stripes that straddle display stripes). – supercat Apr 14 at 21:36
  • Banding doesn't necessarily mean rendering on the PC and then sending the page to the printer in a series of bitmaps. For text and most drawing commands, the page description (PCL, PostScript, EMF, etc.) could be sent to the printer which actually did the rendering. If the entire page description fit in memory, then some printers would handle the banding on their side. If it didn't, then the PC might be asked to stream the page description for subsequent bands. And if you handled the banding yourself, you could prune the page description to commands that affect the current band. – Adrian McCarthy Apr 15 at 4:33
11

They simply didn't let you send much of a bitmap

The first HP LaserJet printers on the market required you send jobs via PCL language. The language was tuned to pretty much not let you do anything the printer couldn't handle. PCL for the whole page needed to fit in the very limited RAM.

Needless to say, PostScript was out of the question on these early printers, as PostScript was architected for "professional typesetter" level functionality at all costs, full knowing this would make a page buffer necessary and dramatically drive up the costs of the printer's rasterizer. Adobe was not after the low-end market.

Yes, the onboard CPU on the printer was rasterizing PCL "on the fly" trying to keep ahead of the drum/laser. First, this was nothing new: video games were already doing that. Second, you were married to the fonts HP provided in the printer, and nobody minded that because every printer up to this point did exactly the same thing.

While the language tried to discourage it, and application developers tried to avoid it, one "could" create a job that the printer could not print for lack of ability of the CPU to keep up with the laser raster. This would end in failure.


Apple's first printer was a totally different deal. That did come with 1MB of RAM and that was used to pre-rasterize the entire page. It was a really big deal, and added to the cost of the printer. It then came with PostScript, which could do all the modern stuff you expect from printers today. Note that the PostScript could take literal minutes to rasterize a page, even though the LaserWriter CPU was often more powerful than the Mac CPU.

It wasn't until the HP LaserJet III that it had (or could be made to have) enough RAM to rasterize a whole page. And then yeah... you could get a PostScript cartridge that went in one of the font cartridge slots.

Font cartridges. Really. It was like that.

This didn't offend the market because Windows hadn't "arrived" yet. PC screens were 25x80, character cells were 8x8 (except the lavish IBM MGA which was 9x14) and PC display fonts still came from the video card hardware. Printers up til now had the font(s) they had. So people were not picky. The text "character" was still the basic currency of computing.

7
  • 1
    Ermmm ... no, but. Of course one could send bitmap. With 75 DPI it was even enough for a whole page and still comparable to existing DMP. It was as well possible to send a 300 DPI, except in this cases only rather small images would work. Oh, and you should put that paragraph about rasterisation time for postscript in BLINK and MARQUE tags. It was an extreme disappointment when hit first - then again, a friend made a business out of high sped upgrades for laser printers :) – Raffzahn Apr 13 at 20:20
  • @Raffzahn: I wonder if the page-to-page alignment would have been adequate to allow one to produce something like a newsletter page by feeding the paper through the printer multiple times, e.g. once for the banner headline and footer, once for the left column, and once for the right column? – supercat Apr 13 at 20:31
  • 5
    @supercat I've done that, mainly for mail merges when I have complex graphics on the same page as the mail-merged address data. Either due to software limits (PageMaker didn't do mail merge) or to avoid a time-consuming rasterization per page. But I wouldn't count on registration being any finer than 1/4". – Harper - Reinstate Monica Apr 13 at 21:40
  • 1
    I remember driving the HP LaserJet IID with Ghostscript at 300 DPI. Had to install an addon RAM card to do that. – David42 Apr 15 at 2:15
  • 2
    @wrosecrans I would say that if you failed to grasp that PostScript is a non-starter on these early printers, then my answer has failed to educate you. Edited. Perhaps you are making a false equivalence between PCL and PostScript, they were not competitor variants of the same thing like "Coke and Pepsi". More like Coke vs '80 Chateau Margaux. – Harper - Reinstate Monica Apr 17 at 20:15
9

Looking at the Wikipedia article on the LaserJet, it looks like the printer couldn't rasterize a whole page of graphics and you needed a 512K LaserJet Plus to be able to do graphics covering most of a page. That would mean the controller would be rasterizing text to the drum using the built-in ROM raster fonts.

The LaserJet Plus followed in September 1985, priced at US$3,995. It introduced "soft fonts", treatments like bold and italic and other features including a parallel (Centronics) interface. It also included 512 kilobytes of memory, which was sufficient to print graphics at 300 dpi that covered about 70% of the letter-size page area.

7

The NeXT Laser Printer had no memory, but a fast non-standard interface fed it bits from its NeXTcube. The NeXT hardware architecture was built around a flexible multichannel DMA controller, so it was really efficient at copying bits from one place to another.

2
  • 2
    "Think different" indeed. – Mark Ransom Apr 13 at 16:22
  • 3
    They essentially repeating what Atari did a about two years before with the SLM 804. The printer was essentially just the printer mechanics, connected with an interface/buffer the computer which had to provide all image data right in time to be printed. Took them some time to get it running. – Raffzahn Apr 13 at 20:18
6

First of all, don't underestimate what can be done with 128K of memory. The original LaserJet was released in the era of the IBM 5150, whose base configuration had only 16-64K memory. As another comparison, the original Game Boy handheld had just 4K of memory and game cartridges were as small as 32K, yet were capable of doing quite a bit graphics-wise. They accomplished this not by storing all their graphics in fully-rendered bitmap format, but by storing a sequence of drawing instructions that would generate the desired output image.

Similarly, printers used a Page Description Language (PDL) instead of being sent a bitmap. This allows the page's contents to be described at a higher level and can save a considerable amount of space vs. a bitmap. Graphics could be sent in a vector format, and the printer would rasterize them as it went down the page.

One of the more popular PDLs was PostScript. I recommend reading though the Wikipedia article for it, as it contains a lot of good information about the problems that printers had at the time and the things that PostScript (and other technologies) did to work around them. Another popular PDL was HP's PCL.

As an example, printing a simple line of text would look like this in PostScript:

%!PS
/Courier
20 selectfont
72 500 moveto
(Hello world!) show
showpage

You tell the printer what text to print, at what page coordinates and using which font. The printer figures out the rest as it goes. That's 75 bytes compared to the >800K that would be required for a bitmap of the same page. IIRC, HP's PCL was even more compact (at the expense of easy readability by humans).

This is just a slight evolution of the way existing print devices worked. At that time, text was printed using a daisy-wheel printer (works like an automated typewriter) or a dot-matrix printer. You had extremely limited options for things like font or print size, and what was sent to the printer was mostly just the text to print. Plotters were used for drawing graphics. They used vector images, and the commands to control them consisted of commands like "lift pen" or "put pen down and draw line to point (x,y)". The PDLs used on the first LaserJet printers followed the same concepts as the plotter control languages.

You are correct that there isn't enough space to store a full-page bitmap for printing, but that sort of thing wasn't even on anybody's mind at the time. It wasn't really a consideration until the "desktop publishing revolution" of the late 80s/early 90s where inkjet printers became common household items. Businesses were accustomed to using a professional print shop for full-page images, and it was several LaserJet generations before that changed.

A big problem in those times was a printed page not quite looking the same way that it looked on the screen. You told the printer to use "Courier" but its hard-wired Courier font might be slightly different than yours so the results were not quite what you were expecting. Some LaserJet models supported an add-on cartridge that contained font definitions that matched the fonts pre-installed with Windows. Eventually, printers started supporting the ability to upload fonts for it to use for a particular document. I can remember in the early 90s buying a collection of "printer-friendly" fonts, which were designed to look the same way on the screen and when printed. These fonts are stored as a sequence of curves (vectors), unlike the more-traditional bitmapped fonts. They could be scaled to any size and since they were small enough to fit into a printer's limited memory, you could ensure the exact same font was used when printing as when displaying on the screen.

6
  • 2
    A PostScript laser printer would need to have enough memory to buffer a full page of memory at the output resolution, in addition to the storage necessary to hold any uploaded procedures, fonts, and anything else that needed to be kept in memory to make the language work. – supercat Apr 13 at 21:03
  • @supercat Fonts were often hard-wired into the ROM but yes, PostScript required a non-trivial amount of memory. That's a big reason why it declined in usage and was largely replaced by other languages (like HP's PCL) and eventually offloaded onto the host PC. Which is kind of a shame, it's a well-built little language and integrates nicely with typesetting programs like LaTeX. – bta Apr 13 at 21:35
  • 2
    Cool, except that the original 128 KiB LJ did not support Postscript. IIRC the most basic device to do so was the Apple Laser Writer with 1 MiB of memory - exactly the size one would need to rasterize it at once, before outputting - which is as well needed, as Postcript allows to place elements in any order and arbitrary orientation and position, so it must be fully 'executed' before any print could be started. Kike Supercat mentiones. – Raffzahn Apr 13 at 21:56
  • @bta: Postscript was an interesting language; I think the decline in popularity was an increase in the amount of memory and processing power in personal computers, as well as the speed with which they could exchange data with a printer. It doesn't really make sense to have print speed limited by the performance of the printer's CPU, but nor does it make sense to spend the money equipping a printer with a desktop-quality CPU that's going to sit idle 99% of the time. – supercat Apr 13 at 22:41
  • 1
    @Raffzahn No, the Laserjet used PCL. I used PostScript for the examples because it's more human-readable than PCL and makes it easier to illustrate the concept. – bta Apr 14 at 0:21
2

Back in 1991 we had an HP LaserJet with a very small amount of memory. It was sold as "software rendering" (or something like that). We bought it because it was way cheaper than the standard model. We didn't have too much money, and heck... we wanted a laser printer!

The thing is, all the image was rendered as bitmap in the workstation, not in the printer itself. I hated it, since my whole workstation would freeze for 10 seconds every time I wanted to print anything (or worse, my coworker wanted to print a few pages).

The little memory the printer had was for buffering purposes only, not for processing anything.

3
  • 1
    You had a GDI printer. Truth is that now they're not so bad, between high speed interfaces (USB or network) and fast computers to render the bitmap, but back then they were generally a bad idea. – manassehkatz-Moving 2 Codidact Apr 14 at 13:39
  • @manassehkatz-Moving2Codidact Probably it was something like GDI. In this case the workstation was a Solaris one, so it probably was the equivalent tech for unix. – The Impaler Apr 14 at 13:43
  • @manassehkatz-Moving2Codidact: They were a design compromise. For many users who would have nothing better to do while a document was printing, they offered a more favorable balance between price and performance than would otherwise be possible, by exploiting computing resources that would otherwise be going unused while printing. Using a 386DX desktop CPU for rendering and a microcontroller for print buffering could offer faster printing performance at a lower cost than using a 386SX-equivalent CPU in the printer while the desktop CPU sits idle. – supercat Apr 14 at 16:41
2

Anecdote reinforcing how much they broke things up due limited memory.

This was from a page layout printing program, full page of real estate advert text to which they manually fixed high res photos of houses then photo-reproduced the lot. (I'm sure many of you have seen such paper magazines outside real estate agents).

This was a solution replacing manual layout of text.

I wrote it running on Mac Classics with an Apple LaserWriter I think around 1992.

One thing I realised was that the printer spent significant time creating the bitmap images for the fonts as it rendered different styles. It only had enough memory to keep one font's bitmaps at a time.

I reordered all the drawing commmands so all the font in a given style was printed drawn in one batch, scattered over the page. eg: Helvetica Bold 18pt, Helvetica 18pt, Helvetica 12pt...

This printed pages on average seven times faster.

2

The first HP Laserjet only had 128K of memory.

The first LaserWriter, released the next year, had 1.5M. It imaged pages in complete form when the appropriate PS command was received. This was its big advantage over the HP machines, allowing it to construct more complex graphics. That did not last long, however, as improvements to the HP printers and PCL eroded any difference.

1
  • True, but you might want to add the price tag as well: 7000 USD, more than double that of a LaserJet. – Raffzahn Apr 16 at 16:01
1

The statement "Laser printer operate in a line by line base" is very misleading. (I'd make this a comment on that answer, but StackExchange won't let me). Yes, they might have had a mode of operation to emulate line printers and dot-matrix printers, but that's not their intrinsic behaviour. And the timelines seem a bit out too. I first had access to a laser printer some time around 1986, and we sent it Postscript generated by Ventura Publisher and Harvard Graphics. I remember also writing Postscript "by hand" to generate our company logo.

3
  • 2
    I think the phrase was meant that it operates on scan lines of a single pixel thickness, not a line of characters. Certainly it was possible to use positioning to make lines of characters that weren't aligned. And the question was about a Laserjet, which at least in the first few versions did not even have an option for Postscript - you might be thinking of Apple's Laserwriter which was based on the same Canon laser engine. – Mark Ransom Apr 13 at 20:05
  • 2
    Michael, could there be a mix up between the view presented to high level programmers with the way the printer itself works, like described? Of course does a laser printer work line by line, that's the way the mechanic is build. There is no other way. The mentioned Postscript is a high level add on software, running on top of the rasterizer and laser driver. It translates high level data (like drawing command) into a binary image, which in turn will be handed to the laser driver, outputting line by line. – Raffzahn Apr 13 at 20:14
  • 1
    My memory was that the printer was Panasonic, but my memory might well be faulty. Yes, we need to distinguish at least three different levels of operation: the API presented to application programmers, the wire protocol, and the internal mechanism. You're right that I misread "line by line" as meaning lines of characters, not lines of pixels. – Michael Kay Apr 14 at 22:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.