OS X Image Manipulation – Convert Multi-page PDF with sips and pdftk

Awhile back I wrote the article ‘OS X Command line Image Manipulation‘ which shows how to use the ’sips’ command to rasterize a PDF document into a PNG, JPG or any other image format file.

A reader then asked how to do this with a multi-page PDF document. From what I can tell, its not possible with the ’sips’ command by itself. However, a little poking around on the internet revealed another very useful command-line tool when dealing with PDF documents – ‘pdftk’.

http://www.accesspdf.com/pdftk/index.html

‘pdftk’ is an open source command line tool for manipulating PDF documents. In particular, it can extract the pages of a single PDF document into their own PDF document files.

By using ‘pdftk’ to extract each page into a its own PDF document file, we can now use ’sips’ to convert the files into our desired rasterized image format.

Installing ‘pdftk’

Easiest method is to download it from the web -

http://www.pdfhacks.com/pdftk/OSX-10.3/pdftk1.12_OSX10.3.dmg.gz

Note – I have not tried this version as I found the next method more to my liking…

Mac Ports
If you’re running Mac ports, you can install it via command line

sudo port install pdftk

This can take a *long* time if gcc needs to be built. Just be patient, it’ll finish eventually!

Using ‘pdftk’

Once installed, simply issue the command

pdftk multi-page.pdf burst

where multi-page.pdf contains the pages you want extracted. This will result in each page being written as its own PDF document in your current working directory. The filenames will be ‘pg_000x.pdf’ where x is the page number.

Integrating with ’sips’ at this point is trivial, as you can customize the output file naming scheme of pdftk to whatever you need.

Safari 4 Beta + Webkit Nightly

Here are a couple of pictures of the nightly webkit build after having installed Safari 4 Beta -

Notice the Safari 4 top tab browsing and debugging button. Also, the top-sites and ‘cover flow’ history navigation all appear intact as well. I guess Safari is the window dressing to Webkit’s browser engine.

It took a few moments to get used to the eye-candy features like top-sites but I am settling into it and definitely like the top tab positioning.

Eclipse 3.5M5 Cocoa vs. Carbon

I have downloaded and tried the following builds of Eclipse 3.5 M5

• Mac OS X Cocoa Intel x86 / 64bit
• Mac OS X Cocoa
• Mac OS X Carbon

I used each one to complete a specific development task end-to-end to make sure I didn’t miss something in a normal development cycle. These tasks included team synchronization via CVS, coding, refactoring, common keyboard shortcuts for editing, and of course debugging.

Setup

The setup I used is my everyday machine – a 17″ Macbook Pro with

• 2.33 Ghz Intel Core 2 Duo
• 2 GB RAM
• OS X 10.5.6
• Java Version 1.5.0-16 (update 3)

Cocoa is Slow…is it my JVM?

Lets cut to the chase – I was able to complete all coding tasks in all of the tested versions of Eclipse. However, both Cocoa versions exhibited two showstopper UI issues.

Issue #1 – Slow Editor Scrolling
The editor scrolled extremely slow when holding the up or down arrow keys. The editor scrolled at expected speeds when using the scrollbar or touchpad, but slowed down considerably when scrolling via keyboard. Perhaps it has something to do with the selected line/focus changing in the editor.

Issue #2 – Painting Issues
I noticed painting problems when closing or opening editor panels. Sometimes the editor would get half-repainted or not at all. An ‘open/close’ of the file resolved this.

These two issues alone though were enough for me to *not* use either of the Eclipse 3.5M5 Cocoa versions for everyday use.

That said, I am running Java 1.5.0-16 and didn’t get a chance to see how these versions might perform on the Java 6 VM.

Carbon is Fast but missing Cocoa UI niceties

The carbon version runs great. In fact, I’m still using it a few days after trying out the Cocoa versions and haven’t had the need to revert back to Eclipse 3.4.1, yet.

The only issue with the Carbon version is really a non-issue as far as development usage is concerned – the Cocoa versions sport some ‘more native’ UI enhancements.

Most noticeable in the Cocoa versions are the lack of scrollbar spacers and a ‘transparent’ resize grip instead of the all white one.

Looking Ahead

There are some things on the SWT 3.5 road map that I really hope come to pass for the Cocoa version

• Unified Toolbar
• Support for Dialog Sheets

I’ve been following the work of Laurent Mihalkovic, co-author of SWT/JFace in Action, since last April when he actually implemented a unified toolbar for the Carbon based version of SWT.

It turns out he also figured out how to make sheets available in SWT.

Since the SWT team was starting serious work on the Cocoa port, I held off on investing time into his Carbon implementations.

That said, its great to see others working to make SWT look truly native on OS X and I think his work helped reinforce the importance of this to the SWT team.

SWT 3.5M5 Improved Search Field

http://download.eclipse.org/eclipse/downloads/drops/S-3.5M5-200902021535/eclipse-news-M5.html.

M5 improves the existing search text input style and goes a long a way towards making SWT look more native on OS X.

The SWT.SEARCH style is now supported on all platforms, allowing the application to display a text message when the control is awaiting input. The SWT.ICON_SEARCH and SWT.ICON_CANCEL hints control the appearance of the search field.

It’s Nice to be Acknowledged :)

http://informagen.com/JarBundler/

About 6-8 months ago, I submitted a patch to allow the ’startOnMainThread’ option to be set in JarBundler. In the meantime I’ve been using my patched version to automate Mac OS X bundling of SWT applications.

Well lo and behold, it looks like the patch got accepted and is now part of JarBundler – sweet!