Simple Document Imaging for Unix? 47
andylievertz asks: "I have developed a logical system of directories for storing my digital documents (i.e. *.doc, *.mp3, *.gif, etc.), and can usually find any obscure document with relative speed. These 'must-keep' hardcopies include everything from bills and shipping invoices to brochures and chinese-food menus. I've tried applying my electronic filing techniques to an actual, real-world filing cabinet, complete with folders and labels, but such a system: requires a great deal of effort to maintain relative to the electronic system, especially considering the frequent influx of new hardcopy material; and doesn't address the greater issue of reducing the sheer paper bulk, organized or not. What solutions have you, the Slashdot Reader, employed to solve this situation for yourself? Are there viable Unix-based Document Imaging packages, similar in function to the Microsoft Document Imaging utility packaged with Office? Do you use a Unix-based Document Imaging solution personally or professionally? If so, what package, and why does it work for you?"
"So, step one is to find ways to reduce the influx of hardcopy (i.e. electronic billing, etc.), but for me, the second step is to find and utilize a [Unix-based!] system that will allow me to scan and file hardcopies electronically so they may be indexed, searched, re-organized, shared, and retrieved as easily as their electronic counterparts. Naturally, any such system would need tolerances for multi-paged documents, and would need to store its output in a non-proprietary file format."
How often do you really need to look at old bills? (Score:5, Interesting)
If you want to track money, having the paper is not nearly as useful as entering the data into a financial program. Try GnuCash [gnucash.org] or something of that ilk.
Delivery menus are different story. I keep them under a magnet on the fridge. If you get a nice rare earth magnet [ebay.com] that can hold a half inch stack of menus, that problem is easy to solve (get at least the half inch cubes).
Any solution that requires every document to be scanned is not going to work for you if you can't even file the documents. what are the chances you are going to get around to that stack of stuff to be scanned?
Invest in a magnet, a big box, and a good paper shredder.
No solution for you but.. (Score:4, Interesting)
Seems to me that the solution would involve a scanner, a database, and a mechanical system for retrieving the documents.
1) Scan the document.
2) Slide document into doc protector with ID tag (UPC codes might work, but really it could just be sequentioal
3) Create DB entry for ID, BLOB of scanned image, (or perhaps a foreign key to keep the images out of the quesry, but realistically most DBs optimize this for you) and most importatntly, meta data about document.
The more I think about it, the more I realize a number system of 1,2,3,4...would work fine. The automated retrieval, which would be nice, is not really vital. The match between the doc ID and the scanned version is enough, so long as the document always goes back into the same folder.
Insertion O(1)
Search O(log(n))
Deletion O(log(n))
Note that garbage collection (compation is not really an option, which means to reaclaim discarded IDS (Reuse folders would crank insertion back up to O(log(n))
The question is whether the scanning process would be worth the time.
Kooka (Score:1, Interesting)
sane + ghostscript (Score:3, Interesting)
I have a very simple script that runs scanimage, then processes the output through convert to make it a rasterized postscript output, then processed that output through ps2pdf (part of ghostscript).
My scanner (epson 1640U) has a document feeder so the command line options for scanimage reflect that. A simple loop in the script handles all the pages.
The net result is a script called "scan2pdf" that I just specify the output PDF file name (something helpful, like the name of the document and the date). I've processed over a decade of financial records, easily 1000s of pages, in a day with this simple setup.