The problem is this: with Outlook we will be limited to 1000 messages in our in-box; sadly, many of us have tens of thousands of emails in our old GroupWise mail. Even after a fairly rigorous slash and burn mission, hacking out all of the low hanging fruit, there will be many thousands remaining and I don’t want to lose that information. It might be useful to search and find how I set up a Zebra bar code printer in 2003, no?

A bundle of different freeware glue tools came to my rescue. Read on to hear about the toolset that has made it so I can keep those messages for years to come.

Possible Solutions

Right out of the gate, I began looking for ways to migrate messages from one mail client to the other. Some apps have this built right in, and if not, there are scripts and utilities out there to do this; but I was hampered by a few key facts:

• I have no control over the email clients and their configuration. Even if there is a menu option for exporting GroupWise messages from version 7.2, I’m stuck at 6.4 and cannot use that option.
• GroupWise is a minor player in the email world. I’m not sure if Outlook would import from GroupWise, but I doubt it.
• They are replacing the client in one shot. There will be no interim period where both GroupWise and Outlook will be available.
• There is no getting around the hard limit of 1000 messages.
• I don’t want to spend money on this.

With these constraints in mind, I immediately thought about PDF documents. I then considered the following questions:

• How do I convert my email to PDF?
• How can I do this automatically with thousands of emails?
• Once I’m done, how do I search these documents?

Here’s what I did:

Conversion to PDF

The first part was easy. I downloaded one of the many free print-to-PDF products available.

I chose PDFCreator, because I am familiar with its use and I know that it does not munge the fonts.

Like many other PDF generation utilities, PDFCreator functions by providing a virtual printer to which any application can print. For example, to make a PDF of a web page, you use the Firefox Print menu and select PDFCreator from the drop-down list of available printers.

You are provided with a list of metadata fields that you can fill in, and these fields are used in the PDF generation.

Here’s what the PDFCreator screen looks like:

A word of caution: PDF Creator is free, but you must be careful to deselect their spammy toolbar options in two different places during the installation process. I don’t like software that comes with preselected toolbars to install (even nice ones like Google’s) because I’m certain that 95% of the folks who actually install the toolbar would never have chosen to do so if it were unchecked by default.

Running Everything Automatically

This was the interesting bit. I work with Windows machines at work, so there was no AppleScript option available. So I did the next best thing: I used AutoIT.

I will warn you that AutoIT is pretty much the Windows analog of AppleScript, without the cutesy pseudo English syntax. In other words, you will need to roll up your sleeves and get your hands a little dirty in order to put together a decent AutoIT script.

The payoff comes when you finish your work and compile it into a tight executable that you can share with your friends, allowing them to automate some complex series of button clicks and copy/paste operations.

I walked through the manual process of exporting an email to PDF and listed each action:

• Get the date, sender, and subject
• Create a filename based on date + sender + subject
• Launch the Print dialog
• Select PDFCreator
• Fill in the Document Title, Creation Date, and Subject in the PDFCreator dialog
• Fill in the full file path in the Save dialog

In addition, I wanted to make the script a little better by adding the following:

• Check that user has PDFCreator installed
• Verify that GroupWise is running and that the user has selected one or more messages
• Prompt the user for a target directory before processing the messages
• Sanitize the filenames by replacing illegal characters with underscores and truncating to meet maximum filename and path length in Windows
• Skip over files that have already been generated, quickly, so that one doesn’t need to worry about accidentally selecting messages that were already printed

There were other adjustments needed, but the process was the same: run the script, hit a problem, tweak the script a little to address the problem, and repeat.

Here’s a little bit of the AutoIT script:

You can see that it is a bit more intense than AppleScript, but remember that the full script wasn’t written in one go. I had a little short ten-line script that I kept tweaking as small problems cropped up until I had adjusted things to my liking.

Note that this is a GUI macro language. The machine starts clicking and typing away right in front of you and you probably shouldn’t interfere until your script finishes.

As of this afternoon, I have generated around 4,000 PDF documents for my email messages.

Searching All of Those Documents

This was the easiest part. These days there is an excellent tool available for searching documents on your desktop: Google Desktop. This product indexes every useful file on your desktop and provides a full Google search with a quick double-tap of the <control> key.

So you can enter a search like “Zebra bar code”

And the results look exactly like a Google web search, but it’s showing your desktop files. And you can see inline previews too.

Macintosh users can install Google Desktop as well, but all of these files should already be indexed and searchable by Spotlight.

Closing Thoughts

Whenever I reach for tools like this I feel a twinge of guilt—it’s outright hackery, isn’t it?

But there is a place for quick and dirty jobs in every workplace. I needed to get my files from one place to another, one time only. It just didn’t make sense to spend money or time on a more elegant solution.

Play around with each of these tools a little. Especially AutoIT—it’s a handy Swiss Army Knife to have at your disposal.

As it turns out, my original script does not work in Snow Leopard, and I promised that I would one day clean up and publish my new and improved version.

Chris posted a comment today as a gentle reminder, so here is the new and improved version without further delay…

The Details

Unfortunately, Snow Leopard came around and caused some indigestion. For starters, the ScanSnap Manager didn’t work correctly and Abbyy Finereader would not process anything made by the ScanSnap. A couple of months later they got everything straightened out and delivered new versions of each product.

The new version of the Abbyy Finereader product does not play well with my original script.

Since I cannot do without this important functionality, I rolled up my sleeves and rewrote most of the script. The new version works in Snow Leopard quite nicely with one small annoyance: you really don’t want to try to use the machine for anything other than scanning or OCR while it is going because the new Finereader version keeps bouncing the darned icon all the time it is running and that is quite annoying to watch.

Fortunately, I really don’t need to use my machine for anything else while it is chewing on the docs; I just wanted to be able to continue scanning at the same time!

Note: Before going forward, note that you will need to upgrade the ScanSnap Manager and Abbyy Finereader to the Snow Leopard versions first! Get the files here.

Here is a link to the new script…

And here’s the code itself:

Installation

• Use the Script Editor to save this script as Run OCR on New Folder Items under User Home/Library/Scripts/Folder Action Scripts
  You may have to create the Folder Action Scripts folder.
• Now open a Finder window and navigate to the parent folder of your scanned documents folder.
• Right click (control-click) the scanned documents folder and choose Folder Actions Setup…
• At this point if folder actions are not enabled, you will likely have to enable them and add the script manually.
  • Check Enable Folder Actions
  • Use the “+” buttons on the left and right sides to add the scan folder and then this script.
• Otherwise, a list of scripts will come up. Choose this script from the Choose a Script to Attach dialog.
• Close all windows.

That’s it! The script will be invoked automatically every time a new file appears in your scanned documents folder.

Please let me know if you have any ideas that can improve this script. I’m not an AppleScript guru, so someone might just know how to keep that annoying Finereader icon from jumping.

I had promised that once I cleaned up the embarrassing bits of code I would post a perfect polished version here, but such promises are rarely fulfilled. A reader posted a comment asking for that source code, so I will post it here in its current state. The truth is, I have been using this script for months and, though it has some quirks, it works fine.

So this post is about Macintosh, AppleScript, and the ScanSnap-to-FineReader workflow. If these don’t interest you, better move on.

Update: The script on this page works only with Leopard (10.5). Get the Snow Leopard version here

The Original Problem

The Fujitsu ScanSnap S510m, my workhorse scanner, was designed to scan documents quickly and generate PDF files—this it does flawlessly. In order to provide OCR support, they have shipped a special version of FineReader, called FineReader for ScanSnap. The standard OCR configuration is to chain the output of the scanner to the FineReader program.

The problem is that this forces scanning and OCR to run in lockstep: you scan a document, you wait for OCR, and then you scan another document.

My desire was to write a simple AppleScript that would detach the “Scan a Document” process from the “OCR” process. By using this script, I can scan documents at whatever rate pleases me, and the OCR engine will chunk along at its own pace, consuming my scanned documents and producing OCR documents.

My Approach

I really looked hard at the OCR application, trying to find AppleScript hooks or special command line switches that might allow me to control it better. Sadly, it was not designed to be scriptable. The only thing I could do is call the FineReader application with a source file.

Given this limitation, I considered writing a script that would look at a particular folder, identifying new files as they appear and passing them on to FineReader.

Fortunately, AppleScript provides this kind of functionality with little effort in the form of Folder Actions. Perhaps the best way to see these in action (and try it out) is to see this post on Exploring the power of Folder Actions.

In order to achieve my goals, I did the following:

• Created a folder called “Pending Documents”
• Wrote the script to find the oldest-unprocessed-file and call FineReader with it
• Attached the script to the folder as a Folder Action

The Script

Let’s jump right in to the AppleScript. Download the script here.

Installation

• Use the Script Editor to save this script as Run OCR on New Folder Items under User Home/Library/Scripts/Folder Action ScriptsYou may have to create the Folder Action Scripts folder.
• Now open a Finder window, control-click and choose More / Configure Folder Actions…
• Check the Enable Folder Actions checkbox, if not checked
• Click the “+” in the bottom left
• Select a folder and click Open
• Choose the script Run OCR on New Folder Items and click Attach

Picky Details

As you can see in the source code, there were several issues to address:

• I had to make sure the script didn’t step on itself. If FineReader was running, I would wait until it was ready before processing.
• The script needed to determine which files had been processed already. This was handled fairly trivially by looking for a matching file with the processed by FineReader.pdf suffix. In other words, if I was looking at Scan001.pdf, I would see if there was a matching Scan001 processed by FineReader.pdf file.
• Part of checking for a source file’s “buddy” was stripping off the PDF suffix. This was done in a hackish way by using a one-line shell script, at lines 106-107.
• I thought it was important to verify that the source file was, indeed, a ScanSnap file—the FineReader will not process other PDF documents. This was done at lines 117-121 by looking at the Spotlight metadata for the Creator of the source file. That took some more shell scripting (133-154).
• The actual work was done by a single line, line 63.

The real work was fairly simple, while the bulk of the code was needed to polish pesky little details. Isn’t that the way code development often is?

If anyone has any improvements on my script, please let me know!

I have always been a big fan of HowStuffWorks, with their detailed in-depth articles describing such disparate topics as manual transmissions and money laundering.

Anyway, author Diane Dannenfeldt has written a lengthy article on How Paperless Offices Work, giving ample coverage to myriad aspects of the topic:

• Introduction to How Paperless Offices Work
• Benefits of a Paperless Office
• Transitioning to a Paperless Office
• Managing Digital Documents
• Going Paperless at Home
• Paperless Office Solutions

Take a look at the full article here: How Paperless Offices Work (howstuffworks.com)

The basic tool required to bridge the gap between the carbon-intensive paper document present and the greener electronic document future was invented in 1993 as a way to streamline communications between publishers and printers.

Today, the humble PDF file is the file format of choice for “final” electronic documents. Properly created and deployed, PDF alone serves a critical need in reducing both business costs and environmental impacts.

Duff Johnson of Planet PDF wrote an article about two of my favorite topics: PDF Documents and Paperless Offices.

In the article, he discusses several key motivating factors for fitting PDF into your own workflow, with the underlying goal of making your office a little bit greener.

Read it all here: PDF is green tech for your office

Here are a few thoughts I have to share on these great media library projects. Not only are they never-ending, but the longevity of the task should guide some key decisions you make as you plod along.

Accept that it’s Never Going to End

I currently have ongoing projects to scan in every scrap of paper in my house, rip every CD to MP3, and scan in every pre-digital-era photograph. But the corpus is just too large. And I haven’t even considered ripping video; I have accepted that a full digital video library is a little too ambitious for me these days.

We need to be aware of this from the very beginning; if you feel like you bit off more than you can chew, you are normal.

Never Give Up

Try to keep your goals clear, so that you don’t lose steam and give up. Perhaps you are looking forward to being able to place the plastic boxes all in storage. Perhaps you can’t wait to be able to make those uber party mixes from your rich collection. In any case, every hour you spend doing the drudgery of ripping CDs brings you a little closer to these goals.

Prioritize Your Work

It is a whole lot better to spend your first days ripping your favorite music to MP3 than to be ripping some weird CDs your roommate left behind in college. Today I happily skipped over the Talking Heads CDs that I inherited from my brother—those don’t really need to be in my iTunes library, do they?

Keep it Simple

Make your work flow as simple as possible. You may still be doing this in three years—don’t over complicate things.

I have been working on my own collection for the past three years. When I first started, I was ripping the music on a PC using a tool called cdex to rip the MP3s and another tool called Mp3tag to edit the tags. These days I use iTunes on my Mac to do both of these tasks. If I had some really fancy work flow going, it might not have been so easy to change machines. By keeping things simple, I was able to do exactly the same thing today that I did three years ago.

Choose Good Settings

…for your software. You don’t want to have to do this again, do you? And don’t go cheap on the bit rate, if you have the space.

In addition, you will probably want to decide between the convenience of a universal format versus the power of a proprietary or niche format. In my example, I opted to use MP3 for all of my music instead of some of the other, more powerful, formats available. I was stung once by the switch from PC to Mac where the handful of CDs that I had ripped to .wmf files were no longer usable.

If you are ripping everything to some killer lossless format, be sure you are looking far down the road and considering compatibility issues.

Back it up!

Make sure your backup process is ready for the increased load. If your backups consist of burning DVDs (or worse, CDs) of your data, you will very quickly tire of this, and you may just abandon one of the most important parts of your work flow. Oh, and remember, if there aren’t two copies in separate places, it isn’t a backup.

A couple of months ago I bought two of those nice pocket-size portable hard drives, and I always leave one at the office and I swap them once per week. This works for me: they are 320GB hard drives, providing plenty of room for all of my thousands of scanned documents, tens of thousands of photographs, and many thousands of MP3s, with plenty of elbow room.

When ripping a CD collection, the data risk is lower since you still retain the original CDs, but it still is a lot of work to rip them all. Don’t overlook the backup, or you will cry when the hard drive crashes.

Know Where You Have Been

Come up with a simple “bread crumb” mechanism to know where you have already been. You want to be able to quickly identify the music CDs you already ripped, without having to bring up iTunes every time. Keep the three year horizon in mind, so you choose a technique that will not be mysterious to you after some time passes (Hmmmm…. did I dog ear the corner of the CD insert to mark it? Where did I put that notebook where I wrote them down?)

I chose simplicity: I have one of those nice metallic Sharpie markers, the silvery kind. I put a small dot on the hub of each CD after I ripped it, just above the center hole. This way, several years from now, I should easily be able to spot the CDs that haven’t been introduced to my digital library.

I do this with photographs as well. As I scan them, I put a small marker dot on the back of each photograph, in the corner.

Finally, Enjoy Your Music!

I am quite capable of getting all wrapped up in the process for the sake of the process. Don’t forget to actually listen to the music you ripped!

Of course, it is only a matter of days, or even hours, before the new glow has worn off and I begin to grouse about the things I wish they had done and I grumble about the nit-picky little bugs that are always there.

Even when the program works perfectly, we often want to use it in a work flow, using each program for what it does best.

Work flow is inherent in the kind of work that we do when scanning, indexing, searching, filing, tagging, and backing up all of our documents, photos, music, and video. Once you are committed to digital media, you will find that you often need to cobble together different programs in order to do away with some of the tedious manual labor.

Scripting tools can be as simple as macro recorders, as fancy as drag-and-drop pipelining tools, and as complex as full programming languages. Choose one that fits you and use it to bridge the gaps in your work flow.

An Example

I have never had a harsh thought about my sheet-fed scanner, the venerable ScanSnap S510m. But one thing has always annoyed me about the software package they provide: you can’t start scanning a new document until the OCR process is complete on the first.

What happens is this: you scan in a document; ScanSnap Manager receives it as a PDF and immediately passes it to Abbyy FineReader for OCR. All is good at this point.

But, the OCR process can take anywhere from 10 seconds to a few minutes, and if you were to scan in another document, FineReader complains:

This is where a little bit of AppleScript magic smoothed over this minor work flow annoyance.

I found that you can attach a bit of AppleScript as a “folder action” to a folder, and when a file appears in that folder, your AppleScript gets called. All I needed to do was figure out a way to get AppleScript to do the following:

• Wake up when a file appears
• Grab the first unprocessed PDF file
• Tell FineReader to start up, if it isn’t running
• Tell FineReader to open the file
• Wait for the processing to finish
• Go back to step 2 until all files are done.

It wasn’t exactly trivial—FineReader doesn’t actually have any special AppleScript support built in. But after a few experiments (i.e. a full weekend of fussing around) it was working smoothly.

Now I can scan as many documents as I want, knowing that OCR is happening at its own pace in a totally different flow.

Some day, when I have cleaned up the embarrassing bits of the code, I will share it here for fellow ScanSnap users.

What scripting tools are out there

The automation tools you use will depend on what software you are working with and what operating system you are using. On the Macintosh side, AppleScript and Automator will probably cover the bases. Things aren’t so pretty on the Windows side, but if you are willing to get a little dirty, Windows scripting can work miracles.

Whatever tool you use, I recommend finding as many simple examples on the Web as you can and running them and tweaking them slightly until you make them do what you want.

I am not an AppleScript programmer; I simply downloaded other people’s sample scripts that did file manipulations and poked and prodded them into shape.

AppleScript

In the Macintosh world, the old standby has always been AppleScript, with its quirky syntax that attempts to look like English. It is surprisingly easy to do some fairly heavy lifting with a minimal of effort.

In fact, though I find its syntax challenging and condescending at the same time, I heartily recommend AppleScript. The key is that Apple has built in AppleScript support to most of the main Macintosh applications.

For a taste of what AppleScript can do, here’s a whole mess of cool scripts for automating iTunes.

Imagine running a script that builds playlists for you or tags files automatically or finds duplicates and marks them.

This is the main AppleScript site, and here’s a tutorial from Apple.

Automator

Another Macintosh product, that provides a more graphical approach to hooking your apps together, is Automator. Here is an article that gives a good overview of the tool.

This is what a simple work flow looks like in designer mode:

You can see more or less what is going on here: You use a predefined set of actions, on the left side, to build up a pipeline on the right side.

In this case, the new automation action will get the selected documents, sort them, combine them into one PDF document, and then open that document in a PDF viewer.

I have always been a little confused with the utility of this product: it’s great if your application provides Automator actions, but what do you do if your app is like FineReader, with no special hooks built in?

Nevertheless, with Automator, you can do some pretty fancy things with many common tasks such as file management, email, and browsing. And there are plenty of custom Automator actions out there for the downloading.

Both Automator and AppleScript are Macintosh OS X built-ins.

For the serious Mac user, there is Bash Unix shell scripting, but that’s all I’m going to say about that. It’s there if you want it!

Windows Scripting

Things are somewhat different on the Windows side.

On the positive side, I believe that Microsoft’s COM object architecture makes it possible to script some pretty fancy things using off-the-shelf software.

In addition, the Office suite has amazing macro facilities that have been used by many as a full programming language, as the core of many successful commercial products.

But Windows just doesn’t seem to have anything analogous to AppleScript for gluing things together without getting your hands too dirty.

As a trivial example of the power of the Windows COM architecture, this short script will launch Excel, create a fresh spreadsheet, and automatically feed in some data. To try it out, save the script to your desktop and double click it.

This is what I saw on my machine when I ran the script:

Just like AppleScript on the Macintosh side, many Windows applications provide hooks for scripting.

The down side is that the scripting language is much more like a programming language, so it’s more comparable to writing shell scripts than to using a drag-and-drop automation tool like Automator.

But when you do the same thing over and over every day, it may be worth it to roll up your sleeves and get down and dirty with some VBScript.

An added benefit of this approach is that the language shares much of its functionality with Visual Basic for Applications, found in Word and Excel macros. If you are writing standalone Windows scripts, you can also write very complex Word and Excel macros. You also have the ability to do much of the same application automation within Word/Excel macros.

AutoIT

This is a freeware tool that many use for scripting their applications.

From the product website:

• Easy to learn BASIC-like syntax
• Simulate keystrokes and mouse movements
• Manipulate windows and processes
• Interact with all standard windows controls
• Scripts can be compiled into standalone executables
• Create Graphical User Interfaces (GUIs)

What more could you ask for?

Closing Thoughts

There are other tools out there; don’t be afraid to check them out and try some of the examples. If you can automate just one annoying task that you do every day, it may be worth the hassle of spending a weekend writing the script.

Epilogue

Yesterday at work I finally rolled up my sleeves at work to tackle a nagging document problem that had been lingering for months.

We have a large quantity of PowerPoint slide decks that have critical company information embedded within. I work in the pharmaceutical industry, so many of those PowerPoint slides had chemical structures for various drug molecules embedded within as OLE objects.

The problem was that we wanted to extract that knowledge (the molecule files) electronically and text mine the slides, but our tools did not support PowerPoint. They did, however, support Microsoft Word.

How could I convert the slides to Word documents? There are dozens of ways on the Net to go in the other direction, but the only way to do what I wanted resulted in the OLE objects being converted to pictures—no good for my purpose. I did find that a copy/paste of each molecule from PowerPoint to Word worked correctly, but who wants to do that by hand with hundreds of documents?

After weeks of trying to find a real Microsoft developer at work to do the task, I finally gave in and tried my hand using VBScript and the Windows Scripting Host. In four hours I had the basics of a script going.

My simple VBScript file does the following:

• Prompt the user for a PowerPoint file and target directory
• Launch PowerPoint and Word in the background
• Loop through every slide, inspecting any OLE objects found within to see if it was created by ChemDraw or IsisBase Sketch, two common chemistry editor tools
• If any such molecules are found, the following happens:
  • All of the “shapes” on the slide are copied to the clipboard
  • A new Word document is created with “Slide (1..n)” appended to the file name
  • The clipboard contents are pasted into the document

Sure, there are plenty of warts to work out, but I was happy to be able to run my script and watch as it magically consumed huge slide decks and spit out Word documents containing the exact data I was looking for. Windows Scripting Host is a powerful tool, as good as, if not better than AppleScript.

[Update: Added epilogue singing the joys of Windows Scripting Host]

I’m not kidding about the saw. Last Sunday I decided to scan in some aging technical manuals, but they were at least an inch thick each, and there was absolutely no way I was going to scan them on a flatbed scanner. Let me tell you how it went..

Table Saw and Band Saw

Since the books were already destined for the recycle bin, I took them to the basement and very carefully fed them to my table saw, using a special guide known to woodworkers as a “sled” to keep the book on solid ground while making it much easier for me to keep my hands away.

The result was actually pretty satisfying. I was able to trim off about a sixteenth of an inch of spine, leaving a rough finish, just like the edges of the pages on cheap book-club hardbacks. I then fed all of the pages through the sheet-fed scanner in a matter of ten or fifteen minutes.

Some time back I tried a less scary method and used my band saw for the job. A band saw is somewhat less dangerous than a table saw, but the cut line was a little wavy for my taste. The books scanned in fine anyway.

Book Guillotines

There really is a better way, if you are willing to pay a couple of bucks. Just go on down to your local office supply/copy-and-print center and ask them to cut the spines off for you. They have a hujamungous paper cutter that can cut phone books clean in half without breaking a sweat.

This afternoon, I called up both Staples and the Copy Center Formerly Known as Kinkos (a.k.a. “FedEx Office”) and I asked them what they would charge per cut of their killer paper guillotine. Staples wanted two dollars, while Kinkos was willing to chop away for a buck thirty.

Of course, your mileage may vary, since these were stores in Jersey, and yours might charge differently.

I didn’t ask them what they considered a “cut”—can you just hand them a foot-thick stack of magazines and ask them to do all of them in one shot? You probably should clarify the total price before they start cutting.

The next time I have a book to scan, I’m going to leave the power tools alone and stop by Kinkos.

[UPDATE: I stopped by the local Kinko's today and asked the guy at the counter if he would cut a whole stack of magazines at once. He said "Sorry, but our guillotine paper cutter is for cutting paper only." Oops. Undeterred, I called a different Kinko's when I got home and asked very clearly if they would cut a stack of magazines, and they said they would. I guess it depends on which person you ask, so if it doesn't work, try a different place.]

[UPDATE 2: Here's a page from a fellow who agrees with the guillotine approach, saying that Kinkos et al. will do the chop; he warns you to remove all staples first!]

After the scanning was complete, I combined the resulting files into one and prepared to run OCR on the whole lot.

Before starting that long-running process, however, I quickly paged through the final document looking for glaring errors.

As it turned out, my scanner software had been fooled by some pages that had large technical drawings on them, and the software had automatically flipped a handful of pages. Good thing I checked before trying to OCR upside-down text!

This is what I look for when I do my quick inspection of my work…

Missing Pages

If your source document has page numbers, this is fairly easy to check. I simply count off, hitting the page-down key ten times, then verify that the page number incremented exactly ten pages. I can go through a three-hundred page document in a minute or two using this technique, and I can be certain that I got all of the pages.

Why would there be any pages missing? Usually, it is because a couple of pages stuck together and went through the scanner as one sheet.

You can help prevent this problem by carefully riffling all of the pages, top and bottom, prior to scanning.

Incorrect Orientation

Sometimes scanner software (like mine) thinks its pretty smart and automatically interprets the orientation of the scanned pages. This is usually a good thing, since many items we scan are printed in “landscape” fashion, requiring a 90-degree rotation to be correct. However, sometimes the scanner will make a mistake in a large document, resulting in one or more flipped pages.

You can either turn off the auto-rotation feature of your software, or you can fix any flipped pages by hand. I choose the latter, mostly because I’m certain I will forget to turn the auto-rotation back on.

Document Feed Problems

You have seen it before: you flip through the pages you recently scanned in, only to find one that is on some totally cockeyed angle. There’s nothing you can do about this once it has happened, other than to rescan the sheet and insert it in the document in the right place.

You can try to prevent feed problems by verifying that the pages aren’t stuck together at all, by a folded corner perhaps, and by verifying that the pages don’t have any dog ears or tears that might catch on the mechanism as they go through.

If I have a document with a tear in it that won’t feed, I will try one of the following: scan it upside-down; scan it in the plastic sheet feeder that came with my scanner; use a bit of transparent tape to cover the tear; or scan it in a flatbed scanner.

Illegible Scans

Sometimes you will realize that something made your scan less than usable—perhaps a moiré pattern appeared as a result of the scan process, or perhaps your resolution just wasn’t good enough to capture the fine detail.

In this case, you will need to make adjustments to your scanning software and rescan.

Once you have discarded the original pages, you can never reconstruct information that was lost. Always inspect the finished product.

If you carefully select one system and stick with it, your entire document workflow will improve.

Here are a few things to consider as your paperless life grows.

Consistent names are good

You probably do need a consistent style for your document names. Arbitrary names such as “Homework assignment 1″ work fine when you have a few dozen documents, but as your library grows, the file names become less helpful. Imagine trying to find that document in a deep folder structure with thousands of similar items.

Remember that anything of importance that you have in your personal digital library is likely to be moved around quite a bit in your lifetime. Operating systems change. Software companies go out of business. Having a good “lowest common denominator” in your file names can help protect you as your files are tossed about over the years.

Pick one system and stick with it

Once you have a substantial collection of documents, it becomes quite tedious to go through them on some great name-changing expedition. In addition, changing file names causes indigestion in your backups, and is particularly hard to implement if you keep permanent backups on media such as CDs and DVDs.

Keep the name relatively computer friendly

There was once a time when savvy users would never embed a space character in a filename. Those days are all but gone, and we can happily use spaces to improve the readability of filenames. This doesn’t mean that you don’t need to consider other limitations.

Don’t make big long cumbersome names that choke “open file” windows and folder views.

Avoid funny characters, even if the operating system allows them. For example, Mac OS X allows you to use characters such as “/” in names, but when you do so, OS X silently substitutes them, keeping a “display name” and a “real name” for each file.

In the example above you can see that I named a file “bozo/clown.jpg” but the terminal window on the left shows that OS X kindly replaced the Unix-unfriendly “/” with a “:”.

Imagine the challenges you will face when you try sharing this file with a Windows user or searching for duplicates of this file in your backups.

Make the name meaningful

There are loads of content management applications out there, but they pretty much all depend on maintaining their own special repository of keywords, tags, and annotations for your files. Guess what happens if you ever have to change to a new document management application? All of those fancy duds are stripped away, leaving your documents bare, with only their names and their content.

There are many situations where the filename is all you have to go on; quite often, filenames are the only thing you can search for.

In other words, put some meaning in the name. Instead of “Homework assignment #1″ try “EN-101 Writing assignment 1, My Summer Vacation.” I’ll admit, that’s a bit wordy, but you see that it includes the course name, the type of document, and a bit of the title.

Consider putting dates in your filenames. Files get copied all the time, and sometimes the “creation date” doesn’t survive the copy operation. In addition, if you are scanning in a paper document that is dated “March 25, 1992,” you might want to have the file name reflect the original paper document’s date and not an arbitrary file system date.

My own preferred style

This is how I like to name my documents:

yyyymmdd {General Topic} – {Specific Title}.pdf

For example:

20090207 Auto - Registration for Jetta.pdf

When I scan in a document, I try to find the most appropriate date for the creation date; in the example, I might have chosen either the date that NJ DMV wrote on the renewal letter, or the postmark.

I include the eight-digit date in exactly that format because it sorts perfectly. If you have a folder with a hundred files that have been named in this way, you can sort on the file name and they will appear in chronological order.

There are as many different systems for naming files as there are people—find one that works for you and stick with it.

Here’s a short page on the subject from Get-it-Done Guy’s Quick and Dirty Tips.