09 September 2005

The Toolbox

Dennis Crouch's useful blawg Patently-O has an item today concerning the PTO's move toward implementing a PDF-based electronic filing system for patent applications. I applaud the PTO's move in this direction; but I'm a bit concerned by Mr Crouch's concluding comment:

Sometime before March 2006, purchase a full version of Adobe Acrobat and figure out how it works. It is likely that every attorney is going to need this on his or her computer.

I think this excessive, and pointing in the wrong direction.

From what I can see, the only need for "editability" will be to use fill-in forms. For some people, this appears to be a problem: Most PDF forms cannot be directly saved with the data as filled in (at least, not with Adobe's PDFWriter; there are other, better "print to PDF" solutions available, some of which are free). That said, there's an inexpensive workaround that should be the default condition for production documents (more below) in any event: Print to a PostScript file, using a standard PostScript printer driver (there are 11 choices that ship with Windows and more drivers available on the web than I can conveniently count) and distill the resulting PostScript file. There are lots of solutions for distilling PostScript short of the full Acrobat package, too; and the two-step process, as opposed to using a PDF printer driver, handles graphics much more cleanly, more accurately… and, perhaps most important, more portably.

The real problem, though, is the underlying assumption that merely having the tool for final output is enough. Bluntly, none of the word processors on the market do a satisfactory job of integrating color graphics with text, or even grey-scale (as opposed to monochrome) graphics with text—and even monochrome graphics have hidden limitations to resolution built into the software. They are the wrong tool for this purpose. The right tool is layout software—my current preference is InDesign, which has the bonus of including Adobe's "official" PostScript distiller in the package—operated by somebody who knows what he or she is doing, preferably under the guidance of a graphic artist. That guidance can be a one-time consultation to create document templates and formats.

The problem isn't getting Document X into a PDF file; that's trivial. The problem is making Document X a good fit for a PDF file, which is not trivial when one is working with intermixed graphics and text. Anybody who has ever struggled with someone's book-length Microsoft Word document converted to PDF—especially if it has much in the way of nontextual material—knows what I mean. When we're creating documents that we know in advance will have legal weight for years to come, we owe it to our clients and ourselves to use the right tools, with the right training, to do so.

Admittedly, this is a matter of emphasis as much as anything else. I have some up-close-and-personal familiarity with the problems of doing desktop publishing with the wrong tools for the job. If all one ever does is write briefs, complaints, and letters, with the occasional line graphic imported for comic relief, a word processor is all one needs. That's not what a patent application is, though; a patent application, despite the bizarre rules governing its format, is (or at least should be) a tight integration of text and graphics, and it needs to be completely portable (that is, the graphics need to be stored in the files in ASCII format, not binary--an option that is not provided in PDFWriter).

Don't hold your breath waiting for the Copyright Office to follow suit, though; it has much bigger computerization fish to fry at the moment.