bloovis.com

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.