Ray Rischpater’s Blog

Improving Interaction Between the Sony eReader and Mac OS X

I have always read a ridiculous amount. Sadly, in recent years as I’ve taken greater advantage of resources such as the Association for Computing Machinery‘s Digital Library, what that really means is that I print a lot.  There’s a definite advantage to paper; you can stick it in your bag, or put your feet up and lean back more so than with a laptop or desktop PC. At the same time, I don’t archive what I read on paper; I either make notes citing the papers I’ve read, or if the paper is really important to me, I archive a copy of the PDF itself. As a result, my professional reading workflow is one of researching, printing, reading, and recycling the results. This is a tremendous waste of paper.

While I’ve tried various ebook solutions on PDAs over the years, I’ve never been particularly happy with PDF handling on mobile devices.  I’ve watched with interest the growing market for ebooks on devices including the Sony eReader and the Amazon Kindle, although until recently neither has had particularly good PDF handling either.

Last month I laid hands on a Sony eReader, and really liked what I saw. PDF presentation with later firmware in the PRS 505 is much improved over previous firmware releases, and both the PRS 505 and PRS 700 support Secure Digital cards. As USB devices, these products show up as a mass storage device when mounted on Mac OS X. As an added bonus, Kovid Goyal’s Calibre application supports both format translation and automatic harvesting of Web content from RSS feeds. I have to admit that it’s pretty spiffy to get up in the morning, grab the eReader from my desk and have the latest content from both The New York Times and The Economist at my fingertips. In conjunction with the large number of freely available books from Feedbooks, it’s a leisure reader’s dream.

Although the eReader’s appearance as a mass storage device in the Mac OS X Finder is useful, I quickly tired of downloading papers and manually copying them to the device. Intuitively, it seemed that what I wanted to be able to do was to treat the eReader as another printer.

Upon reflection, this idea is quite compelling. It doesn’t require me to change my work flow at all; moreover, there is something cool about the idea of an eInk device being directly accessible as a printer.

First on the list was creating a printer that saves its output as PDF files. This is no harder than installing and configuring CUPS-PDF for Mac OS X, a build of CUPS-PDF from codepoetry that streamlines printing to PDF files. CUPS-PDF let me print documents to PDF without the need to choose “Save as PDF” anywhere or enter a file name.

CUPS-PDF is actually more useful than it sounds, because once I installed it I could easily create PDF content for the eReader from sources other than PDF documents.  While Calibre converts between a number of formats and has both command-line and GUI interfaces, I quickly found that in practice the additional number of steps meant that I didn’t put the content on the eReader but printed it or pasted it to Evernote anyway.

By default, CUPS-PDF dumps its output in a directory on the desktop. This is fine, but I’d already established a directory hierarchy for eBooks and PDFs anyway, so I changed that. You can, too: simply open up Terminal and as root using sudo edit /etc/cups/cups-pdf.conf and change the Out directive. (As I recall, you’ll need to reboot your system for the change to take effect.) As an added convenience, I shared this printer using Mac OS X printer sharing so I could print to the eReader from any computer on our home network.

Of course, I wanted to be able to create PDFs for the eReader whether or not the eReader was connected. I was impressed that Calibre handled news transfers automatically; ideally the process of connecting the eReader should update not just the Calibre news stories on the eReader, but transfer any new PDFs I had created as well.

Given that the eReader’s memory shows up as folders on Mac OS X in /Volumes, I knew it was time to see what Mac OS X Automator could do. Within an afternoon, I had an Automator action that moves PDFs to the eReader every time it mounts, complete with Growl status notifications.

The trick was to take advantage of Mac OS X’s Folder Actions, which can run a script any time the contents of a folder changes. By hooking a Folder Action to the /Volumes, I can trigger the PDF transfer whenever the eReader is connected, because on connection the eReader’s storage appears as directories in /Volumes.

I use a simple Bourne shell to actually perform the document transfer. The script looks like this:

#!/usr/bin/env sh
PATH=/opt/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin
export PATH

readermain="/Volumes/PRS 700"
readercard="/Volumes/700 CARD"
spool="/Users/kf6gpe/Documents/eBooks/Spool"
pdfdest="$readercard/PDFs/"

growl()
{
    message="$*"
    which growlnotify > /dev/null
    if [ $? -eq 0 ]; then
        echo $message | growlnotify -t "eReader" -p -2 -a /Applications/calibre.app
    fi
}

if [ -d "$readermain" -a -d "$readercard" ];
then
    growl "Device detetected.";
        for f in `ls $spool/*.pdf`
        do
            mv $f "$pdfdest"
            growl "Transferred `basename $f`."
        done
    growl "PDF transfer complete.";
fi



You’re welcome to the script. If you take it, be sure to update the readermain, readercard, spool, and pdfdest variables, as follows:

  • readermain should be the path to the eReader’s directory for its main storage.
  • If you use a memory card with your eReader, readercard should point to the path to the card. (If you’re not using a memory card, you’ll need to remove this variable and modify the if statement to test only for the presence of the eReader’s main directory. In addition, you’d probably need to make additional changes if you’re using a PRS 700 with memory cards in both slots.)
  • spool must be the directory where CUPS-PDFs dumps your PDFs.
  • pdfdest must be the already-created directory on the eReader where you want your PDFs.

Integrating the script with Automator wasn’t hard, but getting it as a Folder Action on the /Volumes directory was tricker than I imagined. To do this, follow these steps:

  1. Start Automator. (It’s in Applications).
  2. In the window that appears, choose “Custom” and press “Choose”.
  3. From the Library of the Actions Pane, choose “Utilities” and drag “Run Shell Script” to the empty region on the right.
  4. In the “Run Shell Script” that appears, choose /bin/sh as the shell and paste the aforementioned shell script in the main region.
  5. Save the workflow using “Save As…” from the “File” menu. This is important, because once you export it as a Folder Action, you can’t seem to edit the results easily. I learned this the hard way.
  6. Save the script as a plug-in by
    1. Choose the “Save as Plug-in…” from the “File” menu.
    2. In the dialog that appears, select “Folder Actions” as the plug-in type.
    3. Select the “Attached to Folder” menu and choose “Other…”
    4. In the file dialog that appears, type a ~. A new input line labeled “Go to the folder:” appears.
    5. In input line, delete the ~ you typed and enter /Volumes. Press “Go”.
    6. Press “Open”.
    7. Give the plug-in a reasonable name.
    8. If it’s visible, be sure that the “Enable Folder Actions” box is checked.
    9. Press “Save”

Phew!

Frustratingly, this didn’t work right away for me. If you have problems, it’s worth reading this page by Ben Waldie, which explains much of what happens in the Finder behind the scenes to make Folder Actions work. Strangely, when I first put all this together it didn’t work because one of the directories the Finder uses (I think it was  ~/Library/Scripts/Folder Action Scripts/, but I really don’t recall now) mysteriously was given read-only file permissions and Automator’s plug-in creation process would silently fail. So if you’ve never used Folder Actions or Automator, it’s worth looking at some of the other tutorials on the Web before you try to wire one to a shell script.

While it’s pretty slick and I’m quite pleased with the results, the resulting interaction between the Macintosh and the eReader still leaves room for improvement.

First, I’d like to add an eReader-specific paper size to the CUPS-PDF printer options for when I print content such as Web pages. Adding a custom paper size to Mac OS X is easy, although for some reason it doesn’t show up for the CUPS-PDF printer. I’m now starting to look at how CUPS uses PostScript Printer Definition (PPD) files to describe printers and figure out how to do this, although frankly the whole thing makes my head spin.

Second, about 90% of what goes to the eReader this way starts its life as a PDF generated using TeX; such is the stuff of a paper typeset by and for computer scientists. I love TeX and its output, especially the wide margins, because the result is so easy to read. Unfortunately, those same margins occupy a ridiculous amount of space on the eReader screen, space that’s probably better used for the text itself. The Comprehensive TeX Archive Network has a script called pdfcrop that determines the bounding box of each page in a PDF and creates a new PDF consisting of pages without their margins, and I’ve been experimenting with that. Either that or more work with CUPS itself would enable me to rid myself of margins, which would make better use of the eReader’s screen.

Written by kf6gpe

January 3rd, 2009 at 1:07 pm

Leave a Reply

You must be logged in to post a comment.