bloovis.com

The new Amazon Kindle app for Android stores its books in the “kindle” directory on the phone’s SD card. I naively assumed that I could copy any non-Amazon but Kindle-compatible books into that directory and have the app recognize them. I tried this with a mobipocket Jane Austen collection (a .prc file) that works just fine on the Kindle, but the Android app crashed immediately after display the book’s title and author.

The trick to getting such a book to be recognized on Android is to use Amazon’s free personal documents service to convert the file to a DRM-ified .azw file.

First, I emailed the .prc file as an attachment to my free personal documents email address: EXAMPLE@free.kindle.com (obviously, you must replace EXAMPLE with your configured Kindle email address). Within a few minutes Amazon converted the file to a .azw (DRM-ified version of the original file), and replied with an email that included a download link for the converted file.

I saved the file to a temporary directory on my computer and renamed it by changing the .azw extension back to .prc. This renaming is very important; otherwise, the Android app won’t recognize the file.

Finally, I copied the file to the kindle directory on the phone’s SD card. The Kindle app can see the file and display its contents.

The blogosphere is now full of ecstatic praise for the still-unavailable Apple iPad. Much of the commentary follows this pattern: a recitation of the known facts about the iPad (fast, multipurpose, “cool”), followed by the unwarranted conclusion that these facts make it a “Kindle killer”. This argument is similar to debates about religion, in which it is assumed that belief systems are a zero-sum game where there can be only one winner. But what is most noticeable about this argument is that it ignores some crucial facts. This isn’t too surprising, given the rich-geek myopia and herd mentality that pervades Silicon Valley culture. Here are the issues the geeks are ignoring:

Price: the cheapest iPad with 3G is $629. Add to this the $30/month data plan, and you have a two-year cost of $1349. Compare this to the cheapest Kindle, which is $259 and has no monthly charge for 3G access. Then consider the hints that Steve Jobs has given about raising eBook prices as a sop to the traditional publishers. Amazon won’t sit still, either. They’ve dropped the price on the Kindle at regular intervals, and are likely to do that again this year.

Battery life: the Kindle has a battery life of about two weeks when the 3G radio is turned off. I have confirmed this through personal use. This is a huge deal for me, especially when traveling. I don’t have to fret constantly about finding a place to recharge in outlet-starved airport terminals or train stations. It’s one of the key features of the Kindle that makes its use much closer to that of a real book than other electronic devices, including the iPad, which has a reported battery life of 10 hours.

Weight: the Kindle is much lighter than an iPad, which makes it more comfortable to use when reading in bed, or standing at a train station, or any other place where the device must be held in the hands. Even the larger Kindle DX is lighter than the iPad.

Simplicity: geeks with short attention spans and an addiction to email and Facebook won’t consider this a virtue, but the Kindle does one thing very well and offers no distractions. Again, this makes the device more like a real book. Admittedly, this factor may become less important as Amazon opens up the Kindle with their forthcoming developer’s kit.

Display: there is some debate about the readability of e-ink vs. LCDs, but the e-ink is definitely the winner in bright light, and I find it easier on the eyes than my laptop display. Amazon may switch to a different kind of display later this year, perhaps the Qualcomm Mirasol, but if it’s done right it should still offer the same benefits as e-ink: low power consumption and readability in sunlight.

The screen on the Kindle 2 is really too small for reading music at the piano, but it can be used as a replacement for the small pocket scores that are used for study. The trick is to convert the sheet music PDF file into a series of JPEG picture files. Here’s how to do that on Linux:

First, create a separate directory on your Linux machine for the sheet music score that you want to convert. This avoids clutter and accidents.

Then, convert the PDF file to one or more JPEG files using a command like this:

convert -geometry 600x800 op-118.pdf op-118.jpg

The convert program creates one JPEG file for each page in the PDF, using the second parameter as a filename template. In this example, it created the files op-118-0.jpg, op-118-1.jpg, etc. The -geometry option reduces the size of each picture to 600×800 pixels, which is the size of the Kindle 2 screen.

(The convert program is part of the ImageMagick suite; on Ubuntu you can install it using sudo aptitude install imagemagick.)

To avoid possible out-of-order sorting problems when there are more than 10 pages (op-118-2.jpg appearing after op-118-10.jpg), you can rename the first 10 files using this command:

rename 's/-([0-9])\.jpg/-0$1.jpg/' *.jpg

This ugly bit of regular expression magic renames op-118-0.jpg to op-118-00.jpg, op-118-1.jpg to op-118-01.jpg, etc.

Now you can copy the files to the Kindle. First, create a directory called pictures in the root of the mounted Kindle device. Then create a subdirectory of pictures with a recognizable name for your score. The Kindle will display this name in its home screen, so choose wisely. For this example, I created the directory pictures/brahms-op-118 on my Kindle.

Finally, copy the JPEG files to the directory you just created, unmount the device, and disconnect it.

The Kindle doesn’t show pictures by default. Press alt-Z on the home screen to force the Kindle to scan the pictures directory. It will now show each subdirectory of pictures as a separate “book”. When you navigate into such a book, the Kindle will display the series of pictures in that directory. The bottom of each picture may be chopped off, so press the F key to display it in full screen mode.

Look here for additional information on the Kindle picture viewer (scroll down to Kindle 2 Tip #4).

I’ve used the Kindle DX for a week, and it’s a lovely device despite the limitations I’ve been pushing against. I spent a few days vacationing in a town that has Sprint cell service, and can say that the Whispernet really is the killer feature that sets this device apart. I also tried it as a sheet music viewer at the piano, and it was fine for that, though I think it’s best used as a reminder tool for music that you already know; paper is still best for pieces that you’re actively learning.

But in my home town, the only available cell service is AT&T, making Whispernet useless here. So when I learned two days after the DX arrived that a version using the AT&T cell network was going to be available next year, I decided to send the DX back and wait for the AT&T version. Thank goodness for Amazon’s liberal 30-day trial period. I’ll be sorry to see it go, because I was looking forward to using it on an upcoming plane trip instead of lugging around dead tree books.

Perhaps by the time the AT&T DX (which will probably be called the “US and International” version) is out, some of the PDF limitations will have been removed, though I’m not counting on it.

I had heard that the Kindle would recognize (and display correctly) HTML documents, if you renamed them to have a .txt filename suffix. My hope was that it would also recognize internal and external links. If this were the case, then it would be possible to write scripts that would help with the lack of organizational tools. These scripts could walk the documents directory tree and construct HTML files that represented that tree. It would also be possible to extract metadata (such as author, title, and keywords) and represent them appropriately in HTML.

But it turns out that this is not possible. The Kindle displays the formatting of HTML documents correctly, and even supports external links of type http:. But it does not support other types of links, such as file: or internal links.

These are limitations in the file viewer that the Kindle launches when you select an HTML (.txt) file from your home screen. (Such files show up in the “Books” section.) The experimental browser is slightly better, though. It recognizes file: links and allows you to select them, and will jump to the appropriate document. To get this to work, your HTML documents must have the extension .html, not .txt. Also, the external links in your document must have the prefix file:///mnt/us/. In other words, if you want to create a link to the file documents/test.html, the href attribute in the link must be file:///mnt/us/documents/test.html.

But there are some serious limitation in the browser’s support for links that make it unusable for my original purpose. First, the browser will not work if Whispernet is unavailable; in fact, it will hang the Kindle, forcing you to do a hard reset. Secondly, it does not allow links to other types of files besides HTML. I tried linking to a .azw file in the documents directory, and the browser complained that it could not open the file. The browser does recognize such a file when it is in an http: link, though, and will offer to download the file.

So it looks like there is no easy way to construct organizational tools using the Kindle’s HTML support.

One of the most common complaints about the Amazon Kindle is its lack of support for “folders”. In Linux terms, this means that the Kindle flattens your “documents” directory tree when it displays the list of your books on its home screen. However, a directory-browsing UI would be much less flexible than a tagging system, because it would require you to impose an arbitrary hierarchy on your documents. Fortunately, there is a workaround for this that implements a kind of pseudo-tagging using annotations. The advantage of this workaround is that it’s performed on the Kindle and doesn’t require a separate computer.

Even without tagging, the Kindle allows your document list to be sorted either by author or title. Then you can jump to authors or titles starting with a particular letter by pressing that letter key and clicking the 5-way controller. I find this shortcut adequate for most purposes.

But PDF documents, which are supported in a limited fashion on the Kindle DX, present special problems. First, the tagging workaround can’t be used because annotations are not supported. Secondly, if the author and title aren’t set correctly in the PDF file’s metadata, the Kindle will fall back to using the filename as the title of the document. Even if the title is set correctly, the Kindle won’t display it in the home screen; it will display the filename instead, and only show the actual title when you highlight the file and then 5-way to the right. And finally, many PDF files, such as sheet music from the IMSLP, will have missing or incorrect metadata. (This is a problem with non-PDF ebooks too, such as those from the Baen free library.)

So in order to sort through large numbers of PDF files on the DX, it’s very important to set the author metadata correctly. The free calibre program supposedly can do this, but I choose not to use it because I wanted to use my own scripts and have more control over my directory structure. So instead, I’m using the pdftk utility to modify the metadata in my PDF files. In particular, I’m setting the Author and Title fields, which appear to be the only ones that the Kindle recognizes. (I had hoped that the Kindle would also recognize Keywords, but that doesn’t appear to be the case.)

However, pdftk is a little clumsy to use in this fashion. It reads and writes metadata in a format that’s not very convenient. You have to prepare a text file that looks like this:

InfoKey: Title
InfoValue: Six Piano Pieces Op. 118
InfoKey: Author
InfoValue: Brahms


Then you pass this text file to pdftk using its update_info subcommand. I found this usage annoying, so I wrote a wrapper script in Ruby called pdfmeta that lets you specify the author and title on a single command line. Using the above example, here’s how I would update the author and title for a piece of sheet music that I downloaded from the IMSLP:

pdfmeta -a Brahms -t "Six Piano Pieces Op. 118" op-118.pdf


There’s one catch with this: If you transfer a PDF file to the Kindle, then discover that you need to change the metadata, you’ll need to delete the old file on the Kindle, then rename the updated file (changing or adding one letter is enough) before copying it to the Kindle. Otherwise, the Kindle will continue to use the old, incorrect metadata; apparently it stores this information in a separate index keyed by filename, and doesn’t delete or update that information when you update the file.