Displaying Code on the Kindle

So, I'm in a quandary.

Having used one now for a few months, I'm slowly warming to Amazon's Kindle 2. Sure, it still feels a bit cheap compared to the Sony 505, but it's fast, and the ability to download over their wireless network is a bit plus. (Stay tuned for an announcement from us about that...)

But my biggest issue with the Kindle is the markup it supports. Think 1995 browser, minus the <blink> tag. It is very, very limited.

I pride myself on the look of our books, so when I added support for eBooks on the Kindle, I worked hard to get something that looks half-way decent. We're still tuning it, but by and large I think our books look good. But we still have an issue. It is really hard to display code listings on the device. Let me explain why, and show you some examples. Then, at the end, I'll ask for your help.

First, the problem. When the Kindle was first launched, it lacked a fixed-width font. They recently added one. But the choice of sizes is limited, and the code tends to end up too big, even at <font size="-2"> This leads directly to the main problem. The Kindle display is narrow. You can get roughly 45 fixed-width characters across it at the smallest font size. That means code lines will either be truncated, or they'll wrap.

But, we went ahead and did our best. And we didn't much like the result. In particular, I didn't like the way long lines in the code wrapped onto the next line. So I went back to the drawing board and took a new approach.

In the books as currently published, code listings on the Kindle are actually images. That means I get to choose the font, and I get to choose the size. And I can do some cleverer things than I could do with straight HTML formatting. For example, if a listing is wide, I know before hand that it won't fit the horizontal size of the screen, so I scale the font down until it does. And, because the font I'm using is narrow, I can fit more code per line anyway. But there are some major downsides of this approach.

• The code doesn't scale up and down when you change the font size on the device.

• The font we're currently using in the images doesn't have bold and italic versions, so we're not syntax highlighting it. This is clearly fixable, but it would be something of a pita to do.

• The .mobi files we generate are about three times bigger than they'd otherwise be because of the embedded images.

• If an image is too big to fit on a page vertically, we currently chop it off.

So, there's no clear winner. Just to show you what I'm talking about, here are some comparison images taken from Daniel's Cocoa book. The ones on the left are pages from the books as we currently distribute them. The ones on the right use text, rather than images, do display code. (You can click on an image to see it at full size.)

Code As Image	Code as Text

So, given the pros and cons of each approach, what should we do? Stick with the current scheme? Move to text-based code? Or...?

Comments

[Chris]

I've been playing around with this on my Kindle 1. It seems to me that the fixed-width font is still a serif font. It's basically the same as the regular font with finer lines and fixed width. It takes up a lot more room. I've put some code examples on my kindle and compared, and I would rather have the non-fixed width font than the wrapping.

[Remko Tronçon]

@Jocke The horrible crippling of book typography is not an inherent eBook Reader thing. Other eBook readers like the iRex Illiad allow you to watch original PDFs, on reasonably-sized screens. I have seen these in action, and I can tell you that it's stunning. Downside is that these things are still slow, so that's a turnoff for me to buy one (despite the fact that I *really* want one).

But I'm with you otherwise: I would *never* buy a Kindle or any ePub book, because I also believe that a book is meant to be read with the exact same typography it was made. Why pay money for a crippled version of a book?

The examples in this article don't look bad though, so good work Dave. But still, it's not a PragProg PDF.

[Roland Halder]

I read the mobi files on my IPAQ, which is great, but the code-images are almost unreadable - even when I zoom they are!

Therefore I clearly vote for text - or both.

[Nathan Leavitt]

With the announcement of the Kindle2 DX, it obviously would be best to display in text. The DX will wrap less :)

[cbmeeks]

I'm not sure if anyone mentioned this yet but why not just have any large amounts of code as an image and then rotate the image?

The reader would have to spin their Kindle around 90 degrees to view but I don't think that is a big deal. I do that all of the time on my iPhone.

[Geo]

I'm wondering how PDF text shows in the bigger kindle DX (larger version). Supposedly it is a direct PDF reader, and might not break up the layout. Anyone know this for sure?

[Phil]

Looks like Kindle v1 users don't get the monospaced font (though it's not clear why this wasn't included as a firmware upgrade, maybe just an artificial incentive to upgrade? Boo.) I like the way it's handled via images. Word wrapping makes it very difficult to read, as I've seen in some converted PDFs. But I was pretty impressed with how Programming Clojure looked on my v1 Kindle. Very nicely done!

[Jon]

I prefer the text examples you've given. The wrapping is unfortunate, but at least with the examples you have shown, it doesn't make it less legible. Perhaps using text will provide motivation to Amazon to open up a smaller pitch fixed width font (or a decent Sans font).

[Rojotek]

Could you do the image approach, and then provide a link to the source code?

I've been recently reading an ebook that got it wrong using text. It was really very painful. It made me appreciate why people have gone with the image approach, and support that strategy more.

[Nesteruk.wordpress.com]

Don't forget that by rasterizing code as images you're making Kindle DX users really miserable because we get blurry, blown-out images we can't even scale. That's why it's only worth buying PDFs for the DX.

[Dave Thomas]

We decided to take the "code-as-text" approach several years ago now, so you won't see code images in our books.

The current issue is what to do about wrapped code lines—still a challenge, given that we don't control the width of the device, but nowhere near as obnoxious as the initial problem with a lack of code font support in the readers.