PDF to Keynote

Uses for PDF to Keynote

Possible uses include

• Using Keynote as your presenter…

  Make slides in your favorite tool but present them with Keynote. Great for people who make their slides in

  • Beamer
  • Prosper
  • foiltex

• Use Keynote to export PDF to other formats (e.g., as a QuickTime movie)…

  You can do this with PDF slides, but you can also do it with documents. It's pretty wacky to see, say, the Keynote manual, played as a movie.

• Convert your old slides into Keynote slides…

  If you want to move over to Keynote, but have some investment in some other tool, you can ease that transition by using images of your existing slides as a starting point. If you can print or export to PostScript or PDF, you're all set. Possible sources include

  • Claris Impact
  • Scanned transparencies

  You may even have access to an auto-feeding scanner that can make short work of scanning your old paper notes or transparences to a PDF file—many multifunction office copier/printers can do this task.

• Mark-up documents in OmniGraffle…

  As a bonus, if you have a form in PDF or a PDF file for a fax that you want to annotate, PDF to Keynote can help. It also converts to OmniGraffle format, where you can add whatever annotations you need. (Why? Because we can!)

Why Keynote?

Presenting in Keynote has several advantages over Preview or Adobe Reader, including a highly configurable presenter display, rehearsal support, notes and annotations visible only to the presenter, and, of course, Keynote's trademark transitions.

Why OmniGraffle?

OmniGraffle is cool! If you don't own it, you should (many folks got it free with their Mac, courtesy of Apple). Because of the way PDF to Keynote works, it was “trivial” (at least in theory) to also export to OmniGraffle.

Release Notes

PDF to Keynote began as a Perl script (called pdf2keynote). It was sometimes a bit slow, so I thought it would be nice if it had a graphical interface so you could watch its progress as it saved the file. I also figured that such a tool could be useful to more people than just me, but that most other people would would prefer a GUI application.

1.04a

Minor bugfix.

1.04

Improve Keynote '09 export compatibility. Now works with QuickLook, Keynote 6.0 as well as iPad and iCloud Keynote.

1.03

Issue a warning when people try to run PDF to Keynote as 64-bit on 10.5. (Also, recompiled so that it is 32-bit only on PowerPC.)

1.02

Switch from using TrimBox by default to using CropBox (which works better with Preview's "Crop Pages" functionality). But in case people want to use any of the other various boxes PDF has, it's now user selectable via a preference. And in case people can't remember what it's supposed to be, there is also an option to reset the preferences back to their defaults.

1.01

Compile as 64-bit for good citizenship in Snow Leopard, added support for more recent Keynote file formats (including iWork '09's zipfile-based bundles), fixed bug with automatic conversion when the file already exists.
Note: Under 10.5 Leopard, I recommend running as 32-bit [in the Finder, inspect the application and click open as 32-bit] because Apple's 64-bit PDF output libraries have some bugs not present in their 32-bit counterparts. You might speculate that there are no such issues in Snow Leopard, but I cannot confirm or deny such speculation because if I were testing the application under Snow Leopard, I would be under a non-disclosure agreement, which would be violated by comments such as "It works fine in 64-bit under Snow Leopard", so I offer no such comment.

0.99

Fixed problem with Localized.strings

0.98

Actually clip to PDF bounds

0.97

Handle auto-save when file exists

0.96

Added auto-save

0.95

Added auto-open / auto-close

0.94

Include the size of the current page as an available presentation size

0.93

Use TrimBox, then CropBox, then MediaBox to determine bounds of the image.

0.92

Generalized file-format support (If you can write a Perl/Python/whatever script to make an index file for your favorite file format that's saved as a “bundle”, you can make PDF to Keynote write that format. Write the script, and edit Config.plist and Info.plist and you're done.)

0.91

Provide names for the sizes

0.90

Added OmniGraffle support

0.89

Added basic AppleScript support, fixed minor bug

0.88

Improved error checking on save, run under 10.3.9.

0.87

Allow presentation size(s) to be customized via non-UI preferences, use

defaults write net.clawpaws.PDFtoKeynote presentationSizes '("600 x 800", "1600 x 1800")'

and

defaults write net.clawpaws.PDFtoKeynote presentationSize "600 x 800"

0.86

Fixed bug with rotated PDF files

0.85

First public release (not widely publicized)

How Does it Work?

Many applications store their files in “packages”. You can examine these packages with the Finder's Show Package Contents contextual menu?try it on a Keynote document and you'll see that it is really just a folder containing all the images used in the document (as separate files) and an all-important file (index.apxl.gz in the case of Keynote) describing everything else about the document. PDF to Keynote creates the folder and the image files, and then calls a Perl script to build the necessary index.apxl.gz file. The Perl script is remarkably “dumb”—it just pieces together three templates: the opening stuff that the file needs to begin with, a piece that is repeated for each slide, and the closing stuff that the file needs to end with.

An XML Rant

Human-readable files are a good thing. Human editable files are good, too. If the file-formats of Keynote and OmniGraffle weren't, at least to some extent, human readable, I wouldn't have been able to write PDF to Keynote, at least not this way.

But go on, take a look at the XML produced by Keynote, especially versions two and three. It's barely readable?you need to be a masochist to wade your way through the grotesquely tangled and verbose mess. It is, in essence, a dump of the internal data structures used by Keynote. And it isn't writable by anything except Keynote, because only the authors of Keynote know exactly what the rules are for the composition of a Keynote XML file. I worked out how to convert to Keynote only by taking an existing file saved by Keynote and experimenting by trial and error to see what I could throw out and what seemed to be required. The Keynote XML format is so bad that it isn't merely an embarrassment to Apple, it actually makes baby Jesus cry.

Keynote XML format is just one of several examples of ill-thought-out use of XML. XML does have its place, but before choosing XML as a format, you should understand the trade-offs involved in that choice. Know when you should use XML, how you should use it, and what the alternatives are. In particular, be aware of

• XML rah-rah-ism—It's dying down a bit now, but there was a time when it seemed like everything needed to be done with XML, even when there was no real logic to doing so. If you want to use XML, please have a reason. Can you give an informed argument as to why you shouldn't just use a simple text format? If you can, cool, but otherwise, don't let marketing and fashion win over technical merit. Apple's decision to switch its Property List files from the simple and readable text-based OpenStep format to a far less readable XML format seems like a classic case of putting buzzword compliance ahead of techical merit.
• Syntax vs Semantics—XML “solves” the syntax problem, which is a problem that was already largely solved?most applications didn't need and don't benefit from the “new solution to the syntax problem” that XML provides. For many applications, OpenStep's textual Property Lists or Lisp's S-expressions provide a more compact and more elegant representation. XML does not solve the semantics problem. Even if a public DTD existed for the Keynote XML format (it doesn't), I can give you plenty of files that are valid XML that Keynote won't open.

So first, remember that XML is not a panacea—if you take crap and encode it in XML, it's still crap. Second, if you do use XML, you should either

• Keep things so simple that the structure of your XML files is blatantly obvious.
• Write a DTD for your XML, make it publicly available, and then document all the invariants for your files that can't be described in the DTD. For example, in your DTD, you might have defined rotation-angle as a floating-point number, but perhaps you should document that it is in degrees, not radians, and the valid range is -179.999 to +180.0; that rotation happens after the object is placed at the given x and y coordinates; and that rotation is performed at the bottom left corner, not the center. Those kinds of semantic details matter.

And remember, in the time it takes to write a DTD, you could have written a grammar specification for a parser generator like Yacc or Antlr.