At 300dpi (which is pretty minimally low), an 8.5x11 image is 8.4 Mpixels. At any decent compression, that's going to be more like 1MB/page, or 20,000 pages.

Maybe we're talking monochrome? That reduces image size, but I'm not sure how to calculate that.

Don't worry, it's not "every" page like the journalist sId, it's only the last 20,000. Somehow, I don't think that will make anyone feel better.

It's "every" by any normal definition, particularly in this context.

So the answer is to have the work-experience kid press the copy/scan button 20,000 times! :P

Well, monochrome is 1bpp, so it makes the raw image about 8Mbit or 1MB. The rest you'd only be able to determine empirically, and it depends quite a bit on what you're scanning and the scan quality.

"Noisy" images, including poor-quality scans or scans of halftones, don't compress well, but a crisp scan of high-contrast text or line art will be a fraction of that 1MB even with a trivial compression scheme like RLE. If you store as a TIFF with LZW, or something proprietary but similar to that, you're probably talking about an average of 200kB or less for a high-resolution scan. And this is assuming a fairly generous size/speed tradeoff, since you have a local hard drive to burn. I've seen huge document archives that go the other way (scan at lower resolutions, compress hard) that average 30-50kB/page.

They don't compress the images - they are written as essentially bitmaps from the scanning engine then read back to the printing engine. Most actually record 8bits/pixel even in mono because it lets you do lighter/darker and background level in software. so a typical page at 300dpi is something like 100sq in * 90000 pixels = 9Mb

Have a reference?

(boy, I'd hate to have to type that name to log in...)

Not that hard on a qwerty keyboard. Try it.