And I want to be able to treat a PDF file exactly as I would a sheaf of printed pages.

Then along comes someone who exploits yet another bug in someone’s PDF renderer. A few months ago Acrobat Reader was all over the news. Today I saw that all of the cool kids are jailbreaking their iPhones using a simple web site that exploits a PDF defect in mobile Safari in iOS4.

And if the slick website can inject code that does something as profound as jailbreaking your iPhone, it should be child’s play for a black hat to use the same thing to take over your iPhone and ring up millions of dollars of charges to some telephone extortion outfit in a remote part of Africa.

I guess all of the fancy PDF features are a double edged sword—recall that Active-X controls and DDT were both amazing and powerful when they were introduced, but the improper use of both have sullied their good names. I just hope that the goal of a pure paper replacement standard is not lost and that these events do not cause PDF to become a marginalized technology.

My situation is worse—both my wife and I are musicians, to one degree or another. Throw in the fact that she is a music teacher and you can imagine just how many pages of sheet music there are filling bins and flexing cheap shelving in my house.

What do I have and Where is it?

The biggest problem we face is knowing what we have and where it is. I have hundreds and hundreds of pages of classical and jazz guitar sheet music, but if I need to find Villalobos’ Choros no. 1, where do I look?

Shortly after I bought my ScanSnap, I began scanning in all of my sheet music (I have left much of my wife’s collection untouched—I’m sure you’ll understand). In most cases, I simply hacked the spine off of the original book and fed the sheets through the scanner. Now, I have less paper in the house and my music is searchable.

In most cases I didn’t bother to run OCR on the documents since there is little in the way of printed words on most sheet music that is worth indexing. I did take care to name the files well.

If you ever hope to find your music on your computer, make sure you include at least the composer/artist and song title in the file name.

Is this really cutting down on paper?

Whenever I find what I’m looking for I might play it directly off of the computer screen, but it is more likely that I’ll print it out. Doesn’t this kind of negate the idea of removing paper from my home? Not really. Think about it—most sheet music is never played. We have books with hundreds of songs in them and we play only  a handful. That’s just the way it is.

The fact that I print out five or ten pages in a month does not negate the many hundreds of pages that were scanned and then recycled.

Great for Music Lessons

I started taking jazz lessons again a month or two back, and my teacher gave me some lead sheets, with all kinds of useful annotations on them. As soon as I was home, I scanned those babies in, so I would not risk losing the valuable information. I also went through all of my notes from prior lessons and scanned them in as well. These kinds of things are precisely the sorts of paper that tend to get lost in some mismash of unsorted music.

Now, I can type in “Four” in my favorite PDF library application and find the lead sheet for Miles Davis’ Four.

Maybe you don’t have that many notebooks full of music lesson notes, but when you have been trying (poorly) to learn for as many years as I have, those notebooks begin to proliferate. Just scan them all in, give them some good filenames, add some keywords to help, and you’re in business.

What about copyright?

It seems that the jury is still out on digitizing works you own. There’s one fellow who made a right awesome device for scanning in textbooks in minutes, by photographing the pages. That guy’s machine has spurred much debate about whether or not you have the right to digitize your own stuff.

On the one hand, you bought the book and paid for it, so it would seem that fair use covers this; on the other hand, publishers are eager to monetize digital media, reselling the same works to you if they can.

So, is Daniel Reetz’s butt-kickin’ book scanner legal?

That would depend on who you talk to, says Pamela Samuelson, a professor at University of California at Berkeley, who specializes in digital-copyright law. Trade publishers are almost certain to cry copyright infringement, she says, though it may not necessarily be the case.

Google was recently forced to pay $125 million to settle with angry book publishers and authors who claimed copyright infringement as a result of the search giant’s book-scanning project.

But not so individual users who already own the book, says Samuelson. If you scan a book that you have already purchased, it is “fine, and fair use,” she says. “Personal-use copying should be deemed to be fair, unless there is a demonstrable showing of harm to the market for the copyright at work,” says Samuelson.

(Source: wired.com)

Here’s another take on this:

Question

I bought a book for school, can I make a copy of the book for my own use to write on so I don’t write in the book and can get my money back when I return the book to the campus store.

Accepted Answer

You have the right to make a copy of the book you purchased as long as you are using the copy for your personal use. The copyright laws merely prevent you from making copies to sell or distribute.

(Source: justanswer.com)

Of course, if you go passing your PDF documents around to all of your friends, all bets are off.

Final thoughts
Music is a hobby that seems to accumulate great stacks of paper, but these music sheets are peculiar in that you only need one or two out of every hundred. Why not digitize the whole lot and keep those book shelves from sagging?

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.

I am of the opinion that rather than allowing an application to shuffle your life randomly, why not do it the old fashioned way and move your documents into folders of your choosing?

This article discusses some of the advantages of old-school folder management and gives a few hints along the way.

Why bother?

By creating your own well thought out folder structure, you gain the following advantages:

• You can find something fairly easily without needing to launch the special app.
• You can copy reasonable subsets of your document sets to friends or for backups.
• Someone else can find something without needing the special app.
• You can place files in a common network drive that others can see, from PC, Linux, or Mac.
• You do not lose all of the metadata about your files if the document management app ceases to exist.

People have been managing their documents this way for decades, so this is not anything new. What is new, however, is that folks don’t necessarily see what flexibility they give up when they allow the computer to squirrel things away on their behalf.

What kind of folders?

In short, pick some categories of documents that you will be filing, and optionally pick a timeframe which to partition the folders. This mirrors what we do with paper folders, doesn’t it? We create dozens of manila folders with tabs, and optionally create subsets of these files by date (e.g. Receipts, 2009).

One key difference helps us: Computer folders enjoy one feature that their physical counterparts lack—they can be nested several layers deep.

A few examples are probably in order…

I like to keep several kinds of scanned documents relating to day to day home paperwork. Over time, it has become clear that I scan lots of receipts, health insurance papers, banking papers, bills, and … everything else.

As such, I created the following top-level folders: Banking, Bills, Health Insurance, Receipts, and Miscellaneous.

Over time, they start to get stuffed to the gills with things, especially the Bills and the Receipts folders. My answer to this was to split them out by date. Within each category folder I have subfolders by date. This is because some categories need lots of years, while others might not need to be broken down by date at all.

Digital photos are a different creature: I feel that the date of the photo is the most important piece of information, and subject matter is secondary. For this reason, I store my photos in a series of top-level folders labeled with the years.

With photos I have a three-level system: Year, Month, and Subject. For example, within the Photos folder there is a 2009 folder. That contains a 2009-02 folder, and that one contains a folder called Cats. There are many ways to arrange these, I have chosen this approach.

I like iPhoto as much as anyone, and I use it for my photos. The difference is that, for me, iPhoto only holds a copy of each photo—the original photos are all stored on a NAS using the file structure I describe above.

Put a little thought into it and come up with a system that works for you.

Closing thoughts

We are looking for ease of use here, as well as avoiding lock-in to some proprietary app. We also want it to be easy to back up specific bits of the data and share specific bits.

By looking at my example above, you can see how easy it would be to find a bill from 2009. By following a specific naming convention, you can see that each document is fairly descriptive as well. You don’t need DEVONthink or its brethren to tell you how to find the Allstate bill from June of 2009. In addition, the folder names are now easily searchable by my operating system, as are the filenames.

This might create extra work for you in the beginning, but do you really want to be at the mercy of someone else’s application?

Oh, and about making those folders? There are applications out there that can generate a bunch of folders for you following your own chosen rules. One I use is The Big Mean Folder Machine.  I wouldn’t want to depend on an automatic system for daily use, but as a one-time jump start, tools like this can work wonders.

Don’t forget to back up your files!

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.

Apparently this is not the case

It seems that the TSA has leaked their official document of airport security guidelines. ABC News says Online Posting Reveals a “How To” for Terrorists to Get Through Airport Security

A Rookie Mistake

Look at the screenshot of the document at the top of this post. Even though a certain part of the document has been blacked out, it is possible to select the text and copy/paste to find out what is hidden behind the black text.

What kinds of things are listed in this document?

• Photographs of all kinds of official ID cards. Ever wondered what a U.S. Senator’s ID card looks like?
• Procedures for calibrating equipment, such as where guns should be hidden for the testing and such.
• Guidelines for who gets searched and who doesn’t.
• Guidelines for what objects get searched and which don’t.
• And much much more!

In other words, this was a most unfortunate event.

See for yourself—ABC News (and others) have posted the document with redactions removed.

Easy as Pie

Here’s a screenshot of the original document, opened in Adobe Acrobat Professional.

As you can see, it was a trivial matter to use the TouchUp Object tool to gently slide the black rectangle off of the secret stuff (I have blurred the text here, though you can read it from ABC News if you wish).

If you are working with confidential documents that could potentially cause disaster if leaked, please learn how to redact your documents correctly!

I was reading a post on a board I frequent where a person was describing exactly this kind of activity—removing sensitive information from PDF documents. Several suggestions were made, but one individual suggested opening the file in Acrobat Pro and replacing the sensitive text with good old Lorem Ipsum.

It was at that moment that I recalled a peculiar feature of the PDF file format: it is designed to support nondestructive updates, allowing people to make vast changes to a PDF document while still retaining the original document, fully intact. I did a few experiments and was surprised with the results.

A Brief Note on the PDF File Format

For the geeky types among us, one place to begin is this article:

Portable Document Format: An Introduction for Programmers

The key points to get out of the article is this: A PDF document is comprised of several distinct sections, a Header, a Body, an “xref” Table, and a Trailer. At the very end of the file you will find the character sequence %%EOF

The PDF standard was designed to allow multiple updates to a document, while retaining the original version. This is accomplished by appending anything new to the end of the document, after the original EOF tag. The document will now have two EOF tags: one indicating where the original document ended, and a new EOF tag indicating where the new changes end.

If we wish to revert PDF changes, it should be a simple matter of opening the PDF file in a binary editor, searching for the first EOF tag, and deleting everything following.

A Simple Experiment

Let’s start with a proper secret document containing missile plans…

Suppose we want to obscure some special information in paragraph 37. We can open the file in Acrobat Professional and use its text editing features to swap in the venerable Lorem Ipsum text.

Here’s what it looks like after the switch:

You can see here that the first seven lines of text starting on paragraph 37 have been replaced with appropriate unreadable text.

Now, open the new PDF file in a binary editor (since PDF files contain a mix of text and binary, the editor must be a binary editor).

Note the %%EOF character sequence embedded in the text. This is the first EOF tag, indicating where the original file ended. All we need to do is place the cursor to the right of the EOF and delete everything to the end of the file.

Once we have done so, it’s like magic:

The edits that replaced lines of paragraph 37 with gibberish have neatly been undone!

More Details

From the PDF Intro document linked earlier:

“The trailer, it turns out, plays an important role in the way PDF implements incremental updating. The key concept to understand here is that a PDF file is never overwritten, only added to. That goes for all portions of the PDF file – even the trailer itself, and the end-of-file marker. In other words, a multiply-updated PDF document may contain multiple trailers – and multiple end-of-file markers! (There may be numerous occurrences of %%EOF.) Each time the file is edited, an addendum is written to the tail of the file, consisting of the content objects that have changed, a new xref section, and a new trailer containing all the information that was in the previous trailer, as well as a /Prev key specifying the byte offset (from the beginning of the file) of the previous xref section. The cross-reference info will then be distributed across more than one xref section. To access all of the cross-references, the reader must walk the list of /Prev keys in all the trailers, in reverse order.

Space doesn’t permit a detailed exploration of updates here, but you can find several examples in Appendix A of the PDF 1.3 specification (available at http://partners.adobe.com/asn/developer).”

Summary

It is important to understand that the PDF standard allows for appended updates to files that leave the original document intact, regardless of how drastic the changes are. If you are intent on redacting text from PDF documents, do not depend on simply deleting the secrets using a PDF editor—you must use a proper redaction tool that addresses these issues correctly.

That said, I did some experimenting with a few utilities (Apple Preview, PDFpen, and Adobe Acrobat Pro) and found that some write the file from scratch each time, with no lingering cruft from former versions, while others respect the original intent of the PDF standard. This means that you can’t trust that older revisions are being retained in your file and you can’t trust that they aren’t.

Be conservative: use a redaction tool for secrecy and proper backups for versioning.

[UPDATE: I spoke too soon—they only delivered half of the goods. See below.]

[UPDATE 2: Hurray! It's fixed! The birds are chirping and the sun is shining and life is good!]

When Snow Leopard came out back in August, I ordered my copy the first week and was so excited that I installed it the day it arrived. My joy was short-lived, however: the most important software package I use did not work!

I depend greatly on the OCR capabilities of the ABBYY FineReader software that comes with the ScanSnap scanners, and this was one of the many pieces of software that did not smoothly transition to Snow Leopard. I could scan documents, with limited functionality, but the OCR feature did not work.

Now that Fujitsu has released their official update, I will probably be installing Snow Leopard tomorrow evening. Now, do I do an upgrade or a full install? Hmmmm…

UPDATE

Well, they only delivered half of the goods.

I was reading through the seven-step process for updating the ScanSnap drivers and I arrived at step seven:

Step 7: The download for FineReader for ScanSnap update to Snow Leopard will be hosted by ABBYY but is not yet available. If you have already subscribed to be notified by Fujitsu regarding the Snow Leopard updates, an email will be sent to you when it is posted.

How displeasing. The only thing I really cared about was getting the OCR to work, and apparently Abbyy has not yet delivered their part (How hard can it be to update the part in your code that says “If the PDF metadata doesn’t match X then the document isn’t a ScanSnap doc” ?).

UPDATE 2

Instead of making us wait another month or two, ABBYY has delivered their patch in record time . I quickly installed the update and tested my ScanSnap script…

There are a few kinks to work out, but it is pretty clear that I will have my same old workflow AppleScript folder action up and running in short order. I will post the newer script as soon as I have it running properly.

And, as a side note, I had already purchased PDFpen from SmileOnMyMac as a backup plan. Their tool incorporates the OmniPage OCR engine, an engine that rivals that of ABBYY. My script was already running with PDFpen, but there were some issues with tables in documents that I forwarded on to SmileOnMyMac. One of these days I’ll post my scripts for PDFpen.

As it would turn out, there were several thousand other documents on a file server that shared the same funny behavior. By the time we were done struggling with this problem I had gained new respect for PDF corruption issues and their prevention.

The Problem

We were looking to load a few thousand of these scientific reports into a fancy-schmancy new database, with linguistics searching and other bells and whistles. Much to our chagrin, these documents just weren’t loading, and we couldn’t understand why. They were text documents, with some embedded images, but mostly straightforward text.

Here is an excerpt:

And you can tell that it is right and proper text because when I blow it up all the way, the fonts are nice and smooth—this isn’t just an image of text.

But if I copy and paste that particular paragraph into any handy editor (Notepad, in this case), this is what I see:

And as far as I know, at this point the actual text is beyond the reach of average folks like me. We tried, believe me we tried.

What went wrong?

A quick Google of the subject led us to understand that many PDF generation tools embed subsets of fonts, with nonstandard mappings from the text to the font.

This fellow explains it nicely:

“The PDF file does not contain all the information to extract the text. The problem is that a character in a PDF file may not contain information what “real” character it relates to. Some PDF generators do a pretty bad job when they embed fonts into PDF files. They use a proprietary encoding mechanism (e.g. 1 is A, 2 is B, 3 is C, …) in both the embedded font and when they place glyphs on the page. Without a table that implements the reverse (e.g. character code 1 is ‘A’) you cannot extract text from such a file.

There is nothing you can do (besides to complain to whoever created the PDF file, and the author of the software that created this file).”
— from khkremer on experts-exchange.com

As it would turn out, many of the reports had been generated by printing to Adobe Distiller from Microsoft Word. It would seem that the default settings used for Distiller included the “totally hose my document content” switch.

The Solution

We fretted over this quite a bit. These are important scientific reports, and there is no way to easily ungarble them. We finally ended up contacting the Abbyy Finereader folks and trying out their OCR toolkit for Linux: not only did this product make fast work of running optical character recognition on the sample document, but once we had a script running, we managed to blow through the 10,000 pages the trial license gave us, in a day or two.

Imperfect, at best

I am happy that we were able to salvage the bulk of the electronic knowledge found within those thousands of files, but our work barely scratched the surface.

For example, most of these documents have rich bookmarking of sections and keywording, such as this (content tastefully blurred on purpose).

In addition, scientific documents typically have loads of tables full of numbers. Though it is possible to mine this data with a good OCR tool (the FineReader API provides tools for just this purpose), the tables are far more difficult to extract correctly once the original text information is lost.

Final thoughts

I wrote a few weeks about document formats, mentioning the PDF/A document standard. This is worth investigating, regardless of what your document needs are.

If our thousands of files had been originally generated as PDF/A, it is certain that we would have been able to copy/paste from them without problem: PDF/A prohibits such font shenanigans as were perpetrated on our garbled reports.

In the end, our OCR sledgehammer approach worked like a charm, and is probably sufficient for our needs. Text mining is a pretty slushy business, so no-one will complain if there are a few typos on each page—if they find the doc in a search, they can print it and read it the old fashioned way.

I trust my digital life to PDF. Almost everything I scan and most documents I write eventually end up squirreled away somewhere as PDF documents.

Have you ever considered just how portable those documents really are?

What’s wrong with PDF?

It seems strange to question the portability of these files, doesn’t it?

For the past ten or fifteen years Adobe has been providing Acrobat Reader and singing the wonders of their new universal document format. And it seemed to be all that, too—regardless of the audible groan we give when Acrobat launches after we click a link, isn’t it amazing that we can download press-ready copies of our income tax forms, that are guaranteed to look exactly the same when you print them as when I print them? Read on to see what dangers lurk within.

What’s the Problem?

In order to understand the nature of the PDF portability issues, one need only look as far as the web browser for an analogy. Consider how the web browser went from a barebones tool that could display a simple language, HTML, in a neutral way, fitting the web content onto each user’s screen, to a memory hogging behemoth that is an integral part of your operating system. It didn’t happen all at one; it has been death by a thousand cuts.

Mirroring the evolution of web browsers, the PDF document standard has adapted over the years to include many bells and whistles such as embedded audio, video, and JavaScript. It is these features that chip away at the core purpose and raison d’être of the PDF standard.

An example: Font Issues

A simple example of the weakness of these extended PDF features is the humble text font. When your application generates a PDF document, there is the option of using 14 standard PDF fonts, local machine fonts, or embedded TTF or Postscript fonts.

There are 14 standard fonts that should be available by default in each PDF reader. These fonts are Courier, Courier Bold, Courier Italic (Oblique), Courier Bold and Italic, Helvetica, Helvetica Bold, Helvetica Italic (Oblique), Helvetica Bold and Italic, Times Roman, Times Roman Bold, Times Roman Italic, Times Roman Bold and Italic, Symbol and ZapfDingBats® (source)

Guess what happens when you set your document in Mona Lisa Solid ITC and then print to PDF and send to all of your colleagues? Does your friend’s machine have a copy of this font? Maybe, and maybe not.

As I was writing this, I planned on putting together a cute demo by saving a document set in Mona Lisa Solid ITC in PDF from my Mac and then opening it on a PC. Much to my surprise (and delight), I found that the default “Print to PDF” functionality on my Mac does, in fact, embed the font within the document.

Regardless, if you have always just trusted that the fonts would be identical across platforms, you could get quite a surprise when your friend tries to print your beautiful document.

PDF/A Standard

Some time back, Adobe recognized the need for a more tightly controlled standard, for creating really portable documents, instead of mere portable documents. This standard, dating from 2005, is referred to as PDF/A, where the A stands for Archive.

A key element to … reproducibility is the requirement for PDF/A documents to be 100 % self-contained. All of the information necessary for displaying the document in the same manner every time is embedded in the file. This includes, but is not limited to, all content (text, raster images and vector graphics), fonts, and color information. A PDF/A document is not permitted to be reliant on information from external sources (e.g. font programs and hyperlinks). (Wikipedia)

Basically PDF/A forbids all of the flashy stuff and sticks to the basics: good solid document rendering.

Banned features include:

• Audio and Video
• JavaScript
• Encryption
• Nonstandard metadata
• Transparent images

In addition to the loss of several features, PDF/A documents can be somewhat larger, due to the embedded fonts, and they might have rendering issues with images that depend on transparency.

With all that, it still sounds like an enticing concept. Many PDF tools speak fluent PDF/A. Check out your own toolkit and see if you can future-proof your documents a little more

Here’s more on PDF/A documents

Long-term digital archiving with PDF/A (The PDF Blog)
PDF/A (Wikipedia)
PDF/A – A new Standard for Long-Term Archiving (PDF/A Competence Center)