bloovis.com

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.

Several years ago, the Ubuntu developers made a horrible decision to make dash the default shell instead of bash. This breaks numerous shell scripts, and I recently discovered it also broke one of my own Ruby scripts that depended on bash’s signal handling. The problem here was that when a TERM signal is sent to dash, it doesn’t kill off its child processes.

The problem isn’t fixed by making bash the login shell for a particular user, because some programs (such as Ruby) invoke /bin/sh, which is a symlink to /bin/dash. The fix for this problem is to make bash the default shell on a system-wide basis. The following command does that:

sudo dpkg-reconfigure dash

When you are asked whether to install dash as /bin/sh, answer No. This will update the symlink, among other things.

By default, Linux Mint 6 and 7 (and presumably, Ubuntu 8.10 and 9.04) come with a minimal set of somewhat ugly fonts. There are two things that can be done to improve the situation.

First, install the Microsoft TrueType fonts:

sudo aptitude install msttcorefonts

Then, if you are using an LCD monitor (e.g., a laptop), enable anti-aliasing (smoothing). On Linux Mint, start the Control Center from the main menu, then select Appearance. (On Ubuntu, I believe this is done using System > Preferences > Appearance.) Click the Font tab, and under Rendering, select Subpixel Smoothing.

You’ll see an immediate change in all fonts used in Gnome, but you may need to restart Firefox get it to see the new fonts and use smoothing.

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).

It’s nearly impossible to buy a PC without Windows unless you build it yourself. But one persistent person managed to get a refund from Dell, after only twelve emails back and forth and a lost day of work. That was easy!

My employers have given me a Windows XP-64 machine, which sits 3000 miles away on the opposite coast. Operating it remotely using TightVNC isn’t anywhere near as fast or convenient as ssh, but at least it works.

The machine seemed to be working fine when I disconnected from it on Saturday night. When I reconnected on Sunday morning, my session with all of its terminal windows was gone, and the login screen was showing. Today, after poking around with the Event Log GUI (nothing so easy as sudo less /var/log/messages), I figured out what went wrong. A process called the Windows Update Agent started running at 3 AM Sunday morning, and after five minutes it rebooted the machine. So apparently Windows has an automatic data loss feature that is built in and enabled by default.

A Google search turned up this article, which says that the way to fix the automatic reboot is to edit the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\Auto Update and create an entry called NoAutoRebootWithLoggedOnUsers with the value 1. I also found this article, which shows how to use a GUI to disable the feature; this is the method I used, though I don’t know if it actually works. Either way, you have to wade through many levels of settings to find the right one, something that would be almost impossible without Google. And people think editing plain-text configuration files on Linux is hard!

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.

When I was shopping for an inexpensive flatbed scanner, it was not always easy to figure out which ones would work in Linux. Many manufacturers use proprietary protocols in their products and generally ignore Linux. I bought an Epson V30 because it was cheap and because there are drivers available for download here. The drivers work on Linux Mint 6 (Ubuntu 8.10) or later, and on several other Linux variants. Unfortunately source code is not provided, so if you don’t have one of the popular distributions, you may be out of luck.

One of the things I wanted to do with the V30 was scan books and convert them to plain text (for personal use; I’m not a pirate). For this I used Tesseract, an open-source OCR package that was developed at HP in the 90s and is now being maintained by Google. (The package name in Mint / Ubuntu is “tesseract-ocr”.) This program has a slightly funky command line interface (only reads TIFF files; the input filename must end in “.tif”, not “.tiff” or anything else; the output filename must be given without an extension). But it works surprisingly well, and I was able to integrate it into xsane (a decent scan utility) by writing a wrapper shell script that makes its command line interface identical to the gocr program that xsane uses by default.

I experimented with varying the dots per inch when scanning a book, to see how that affected tesseract’s error rate. At 100 DPI, the output was gibberish. At 200 DPI, the output was nearly perfect, with only about four errors per page that needed to be corrected manually. At 300 DPI, the output was marginally better, with perhaps one or two fewer errors per page. As I mentioned, this seems remarkably good. After I scan a page and convert it to text, I’ll fix the obvious errors and remove any end-of-line hyphenation. Then I’ll run aspell on the text to find additional errors. The most common errors are missing spaces (”ofthe”) and “l” change to “1″.

Another approach to OCR is to buy the commercial, closed-source Vuescan. I owned a copy six years ago, when xsane was not quite up to snuff, and it worked beautifully. I’m trying the latest trial version, and it has a number of improvements. The most interesting new feature is the integration of tesseract-ocr. This saves several steps in the process of scanning text, and the speed-up may be worth the price.