Hi, > I do think I have observed behavior indicative of the scanner internally > buffering pages. If the network crashes during a scan over my software > shuts down. I have sometimes reopened it and hit the scan button after > carefully putting the pages back on the right order in the tray, but the > tray never feeds and I get 9 or 10 pages in rapid succession far faster > than the scanner has ever operated. > > I think the scanner has internal memory that it saves each page objects > too > and perhaps that memory is segmented in some way maybe partitioned just > big > enough to hold one legal size sheet of paper each. As opposed to holding > 10, 000 one-dimensional lines of pixels. > > That doesn't explain why it has to be that way but on my Epson > multifunction printer scanner it seems to be working that way. > > For scanning a delicate artifact like a roll of piano paper I might > imagine > sliding it between two sheets of glass that don't quite squeeze the paper > but keep it flat and then you can keep it moving at a constant speed like > it was intended, and use a moving camera that snaps a photo while moving > at > the speed of the paper and then jumps back the other direction just enough > to overlap an inch. You have to work really hard and getting the lighting > right. > > Or maybe act together two separate sheet feed scanners and put their > sensors at different positions along the glass. Then you have them take > 17-in scans and succession so that when one is starting the other one is > halfway done. Each of them I think it's only scanning one page at a time > but because of their positioning it would be creating overlapping pages of > one continuous document. Hacking existing scanners might be easier than > building your own and if their scanner element illuminates the page while > scanning it like mine does then you wouldn't have to mess with lighting so > much. > > I could also imagine wanting to shield both sides of the piano roll with a > clear backer ribbon Then you could feed the two backer layers between > rollers the same way you would feed the paper between a roller but with > less chance of damaging the paper. > > Interesting thought experiment. > > In the 90s I had something called a handheld scanner. Back when it was > quite a novelty to have images on a computer screen let alone photographs. > Looked like a really fat and mouse and you could drag it across the page > of > a bound book to scan a 6-in wide column. It had an optical sensor bar and > a black wheel that measured distance. > > I wonder how that worked. What would it have done if you dragged it > across > the gymnasium floor with a laptop? > Then again I remember you had to install an ISA card just for the scanner, > so, no laptops. I wonder where this thing went so many years ago. > Perhaps > the manufacturer just never planned on it scanning longer than two times > its cord length.
Now I remember something. I bought this scanner from Logitech decades ago: https://upload.wikimedia.org/wikipedia/commons/2/28/Logitech_ScanMan_32-P4191186-white.jpg Because I wanted it for my Commodore computer, it was either a Plus/4 or C128, I've analyzed the wire protocol on its connector, I think it was mini-DIN. I've then designed an interface card for the commodore and implemented some scan software in 6502 assembler, which has worked very well. Now, IIRC the scanner produced a quite simple data stream and you could scann almost endlessly with this device. At least it didn't seem to have a limit as it didn't have much memory to buffer more than a few lines. These were very interesting times :) Regards, Simon
