A closer look at Classics.app

A Screenshot of Classics

Classics” is a great product, it shows us iPhone developers what an elegant ebook reader can be, so I bought it almost instantly after it’s released. I’ve been chatting with my friends about this app for a while, now I’d like to give a more closer examination to it from the perspective of a typographer and a programmer. Especially its weaknesses.

Illustrated by my favorite graphic designer, David Lanham, Classics tries its best to provide a traditional book reading experience (that’s why it’s called “Classics”). It contains the following books, even I’ve read most of them in Chinese long time ago, thanks to Classics, it’s still a fascinating experience to read them again in English:

However, there are still some details to be improved.

Classics's mistakes on word spacing and hyphenation

First of all, Classics shows the entire interface in a portrait way, it’s more like traditional books, but has an unavoidable drawback: the iPhone/iPod Touch screen is not wide enough, if you make the characters large enough (otherwise people won’t be able to read them clearly), breaking paragraphs into lines will be extraordinarily hard, you either have to introduce a lot of hyphens, or make the word spacing too loose or too tight. From the following screenshot, we can see Classics made both mistakes.

The spots I marked made the reading experience much worse, if you’re a picky reader like me. And it happens on almost every pages! So why, why couldn’t Classics support landscape mode to improve the situation a little bit?

To understand this, we must first find out how Classics is implemented. Let’s take a look (yeah I know I shouldn’t do such reverse-engineering, but I just can’t help). First, copy it from where it’s saved, expand it as a zip archive:

$ cp ~/Music/iTunes/Mobile\ Applications/Classics\ 1.1.ipa classics.zip
$ unzip classics.zip
    Archive:  classics.zip
   creating: Payload/
   creating: Payload/Classics.app/
   creating: Payload/Classics.app/20,000 Leagues.classic/
  inflating: Payload/Classics.app/20,000 Leagues.classic/0.pdf  
  inflating: Payload/Classics.app/20,000 Leagues.classic/1.pdf  
 ...
  inflating: iTunesMetadata.plist    
  inflating: Payload/Classics.app/SC_Info/Classics.sinf  
  inflating: iTunesArtwork           
finishing deferred symbolic links:
  Payload/Classics.app/CodeResources -> _CodeSignature/CodeResources

OK, now it’s clearer, let’s open up Finder so that you can see it in a more structured way:

Internal structure of Classics

See? It turns out every book Classics loads and displays:

  1. Is a .classic ended directory with PDFs for each chapter,
  2. Contains a Info.plist describes it,
  3. Has a cover image called Art.png.

Let’s first look at one of these plists,

$ cd Payload/Classics.app/A\ Christmas\ Carol.classic
$ plutil -convert xml1 Info.plist -o -
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
    "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>author</key>
    <string>Charles Dickens</string>
    <key>language</key>
    <string>English</string>
    <key>sections</key>
    <array>
        <string>Preface</string>
        <string>Marley’s Ghost</string>
        <string>The First of the Three Spirits</string>
        <string>The Second of the Three Spirits</string>
        <string>The Last of the Spirits</string>
        <string>The End of It</string>
    </array>
    <key>title</key>
    <string>A Christmas Carol</string>
    <key>year</key>
    <string>1843</string>
</dict>
</plist>

So the file contains sufficient metadata for Classics to load this book, but it seems quite “preliminary”, thus, not flexible enough IMHO. For instance, PDF files must be named from 0 to n, each corresponds to a chapter (0 → Preface, 1 → Marley’s Ghost, etc.)

A Chapter from Alice in Wonderland

And then, how are these PDFs look? Here is a screenshot taken from Quick Look. pdffonts and pdfinfo from xpdf can give us more information:

$ pdfinfo 0.pdf 
Title:          untitled4
Author:         Phillip Ryu
Creator:        Pages
Producer:       Mac OS X 10.5.4 Quartz PDFContext
CreationDate:   Fri Nov 14 00:12:37 2008
ModDate:        Fri Nov 14 00:12:37 2008
Tagged:         no
Pages:          2
Encrypted:      no
Page size:      216 x 316.8 pts
File size:      27175 bytes
Optimized:      no
PDF version:    1.3

So it’s typesetted manually by Phillip Ryu with Pages, doesn’t sound very high-tech, huh?

$ pdffonts 0.pdf 
name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
VLFBFB+Georgia                       TrueType          yes yes no      10  0
LMPSPR+Georgia-Bold                  TrueType          yes yes no       9  0
BXMTAW+Georgia-Italic                TrueType          yes yes no      19  0

Yeah, the only font family used is Georgia. To admit, I was actually hoping some fonts more suitable for book typesetting, say, Garamond or Sabon.

Enough said, now we have a better understanding of the internal architecture of Classics. As we can see, using PDF for all the books is the chief decision that affects the rest of the app. There are pros and cons for this decision.

Pros:

  1. No need to calculate the layout when the user is reading, thus loading a new page will be generally faster than a book reader that loading text and doing layout dynamically.
  2. With PDF, one can embeded arbitrary fonts as wish, bypassing iPhone’s limitation. (Classics does not make use of this advantage, sadly.)

Cons:

  1. The layout is fixed, no way to adapt it to a screen in landscape mode.
  2. Loading PDF through iPhone still has noticeable sluggish, thus, you can’t tap a chapter and have it shown instantly. The worse thing is, there is no way for the developer to optimize it, as long as they still use Apple’s frameworks for PDF rendering.

Except for this, is there anything else can be improved? Yes,

  • After compressed, Classics is a 22M beast. Downloading it in bad bandwidth condition can be a problem, not to mention every once it’s updated, you have to download 22M (or even more) again, while most of them you downloaded are just duplicated resource files you already had!

    Even though we can see it greatly simplified application deployment, this part can certainly be improved. For instance, instead of bundle these books with the app, setup a site for it to retrieve books dynamically, books can be downloaded the first time user tries to read, and cached in his Documents directory.

  • Pages is definitely not a serious typesetting tool. If I were Phillip1, I’ll try to build an automatic conversion infrastructure with XeTeX, it will be much easier to maintain, and gives noticeably better text layout results, especially on line breaking, I suspect.


  1. However, if I’m really going to implement such a book reader, PDF won’t be the best option for me though. 

Author: jjgod

A software engineer from China, working on text rendering for a fruit company. Interested in typography and science fiction.

3 thoughts on “A closer look at Classics.app”

  1. i find it funny that something as arbitrary as spacing bothers you so much when you wrote “And then, how are these PDFs look?”… stop being so damn picky; you’re getting a collection of books for 99 measly cents.

Leave a Reply

Your email address will not be published. Required fields are marked *