It seems that The Boy Genius Report has gotten some leaked photos of the next generation Kindle. The full article is available here, although there is very little information from their source besides the photos. Apparently the next generation of Kindle doesn’t have an SD card slot.
This is the second part of my continuing exploration into the Kindle Topaz file format. This will probably not make much sense until you read the first part.
Topaz files contain a set of headers and corresponding blocks. Each header and block has a type. It appears that there are seven types: DICT, DKEY, GLYPHS, IMG, METADATA, OTHER and PAGE. For each header there are one or more corresponding blocks, and the header provides the number, location and sizes of the blocks, and probably some other information I haven’t decoded yet. Topaz files seem to only ever contain a single block for the DICT, DKEY, METADATA and OTHER types. There are typically many blocks for the GLYPHS, IMG and PAGE types. Hardly surprising given that GLYPHS contains font data, IMG contains image data, and PAGE contains book text.
I’ve recently been playing with the Amazon Kindle, Amazon’s electronic book reader. Despite looking like a throwback to ’80s computing, it’s actually a surprisingly good product. It’s by far the best ebook reader on the market, and transparent wireless purchasing and downloading is a killer feature. If they can improve their product design and invest in future e-Ink improvements they will own this space as it grows. Printed books have some time yet, but the writing is on the wall. Music paved the way, video will follow as internet bandwidth increases, and books will *eventually* go digital.
Beyond reading books on the thing, I’ve been looking at how the Kindle stores its books. Amazon uses two primary file formats for Kindle ebooks; a modified form of Mobipocket and something called Topaz.
I’m going to start posting what I’m calling tidbits - morsel sized pieces of code for common tasks on Mac OS X.
The first of these is computing a file checksum (MD5 to be precise). Apple provides the functionality in CommonCrypto/CommonDigest.h. This uses routines in libSystem and avoids loading the entire of OpenSSL to simply compute a checksum. The code is really simple:
#include <CommonCrypto/CommonDigest.h> NSString* fileName = @"PATHTOFILE"; unsigned char md5[16]; NSData* data = [NSData dataWithContentsOfFile:fileName]; CC_MD5([data bytes], [data length], md5); // md5 now contains the md5 digest for the file contents
Trivially easy. The CommonDigest.h header contains functions for MD2, MD4, MD5, and SHA1.
Safari has a surprising number of keyboard shortcuts.
Some of the more useful shortcuts:
Command-F Find (Search) Command-G Find Next (Search) Command-L Jump to the Address Bar Command-Option-F Jump to the Search Bar Command-T Open new tab Command-W Close current tab or window Command-Shift-Left Go to previous tab Command-Shift-Right Go to next tab Command-D Bookmark current page
This local URL will give you a comprehensive list of all the keyboard shortcuts supported in Safari:
file:///Applications/Safari.app/Contents/Resources/Shortcuts.html
Pretty neat.
John Gruber of Daring Fireball fame wrote a great article on the fonts that shipped with the iPhone back in July 2007. However, with the iPhone SDK launch, the article is somewhat out of date. Based on the latest available iPhone SDK here’s the current state of play in regards to built-in iPhone fonts.
Sometimes you want to time things in your code. The usual pattern is to store the current time, do something, store the current time, compute the difference, and then convert it to something useful, like seconds elapsed. That pattern gets old fast, so here’s a little Cocoa stopwatch class that neatly encapsulates stopwatch timing on Mac OS X.
Xcode 3 was a pretty significant upgrade, and included some desperately needed improvements to Interface Builder. Now, although the new version of Interface Builder is significantly improved, it still suffers from some eccentricities and a lack of good example-driven documentation. It’s an amazingly powerful tool, but a lot of its features can be somewhat hard to discover without help. This post contains a few things I’ve discovered about Interface Builder over time that I’ve found really useful.
Muscle memory is a powerful thing. I’ve been using Mac OS X for over six years, but my history with Windows, and DOS before it, have defined how my brain expects certain tasks to map to keys on the keyboard. I’ve never gotten used to the text editing key bindings on Mac OS X. I grew up with things like CONTROL-LEFT and CONTROL-RIGHT moving the cursor by a word, and SHIFT-DELETE, CONTROL-INSERT, and SHIFT-INSERT being cut, copy and paste respectively. Luckily, Mac OS X provides for customization of key bindings, and I managed to create a set of key bindings that met most of my needs… Until Leopard arrived.
One thing I like to do in any development project is generate a build number, and I want it to be an automated process. This number represents the version of the source code that was used for the build. Coupled with source code control, this enables you track the version of the source code that corresponds to a customer’s installation of the product. In a large team with centralized builds, you typically increment the build number on every centralized build, whether they are kicked off on a time basis, or a check-in basis. For a single developer project, it’s nice to be able to increment the build number for every build you make locally. Here’s a simple way to enable automated build numbering in Xcode for a single developer project.
