A review of the Shortcovers app for the iPhone

Shortcovers launched yesterday. Being extremely interested in mobile publishing, I dropped everything to take a look at their iPhone application. It’s not bad, but there are certainly some rough edges. Here’s what I think:

1. UI elements take up too much space: On a tiny device such as the iPhone, I expect to be able to make use of the whole screen for reading. The app needs a fullscreen-mode. As it is at this time, a solid chunk is removed by the status bar, a navigation controller and a translucent toolbar. The translucency doesn’t help.
   
   
   
2. Flipping pages is too much work: In Shortcovers parlance, a ‘page’ is a multi-screen sequence where your only option to go from screenful to screenful is to flick or track across the screen with your finger. There are ‘previous page’ and ‘last page’ buttons, but these go to the next multi-screen chunk and not to any text contiguous to what is on the screen currently, unless you’re at either end of the ‘page’. Not only is this an unnecessary break from convention, I bet it’s more tiring to go through a whole book so physically. Not only are you flicking every few seconds or dragging a fingertip constantly, you must track your ‘point’ visually to resume reading and finally suffer the distraction of the bounce-scroll at page ends.
3. Connection problems: I have not been able to purchase a book at all; I’ve tried a few times. I get a ‘Shortcovers Error ...’ alert.
4. Autocorrection in Search should be off.

Finally, a non-complaint: the following screenshot shows Shortcovers approach to CoverFlow that is not CoverFlow, i.e., something in the category that has no chance of being mistaken by Apple as an instance of the use of their private frameworks.



I’m sick of the whole thing. The obsession with this class of silly gimmick has me perplexed. What’s wrong with a nice table?

Anyway, I hope they add a fullscreen mode soon (and support for Urdu?) because I have every intention of using this all day.

Adding BDF support to my Mobile Font Engine

Having designed my font engine to support proportional-width fonts from the start, I’d been thinking about how to store glyphs:

1. Should I store one large ‘global image’: an image with all glyphs laid out and a separate table of offsets and widths, particularly delectable samples of which can be found on Ben Fry’s website?
2. Should I store glyphs in individual files, which would be an implicit description of the same offsets and widths?

It then occurred to me that I was being a silly ass.

Of course there have been standards for this sort of thing before outline-based fonts came to rule the world. Supporting a once-popular standard might make available a related set of utilities, editors and possibly even some nice free fonts. That’s too much to pass up.

So I applied my careful method, as in all things, of indiscriminately picking the first option. Which happened to be the BDF. Calling it the BDF format, being the same as saying the Bitmap Distribution Format format, is a little on the uncouth side.

And here was some unexpected joy: BDF is a 7-bit format! Very nice; nothing niftier than editing a font in TextEdit. To be serious, FontForge seems to support BDF well enough. Or you could just use this fine editor written in Tcl/Tk: Thomas A Fine’s bdfedit.

Here’s a link to the BDF spec, and one to a description of Microsoft’s extension to BDF for anti-aliasing. And of course you can find plenty of BDF fonts (in a legally suspect manner, so don’t do it) with just a google search.

Starting on an embedded font engine for the iPhone

I’ve recently started work on an embeddable bitmap font engine for the iPhone, for the specific use of non-mainstream scripts such as the many Indian languages, Arabic, Farsi, etc.

Why write my own engine and not work with Apple’s system libraries?

1. I don’t trust Apple’s QA process for scripts that don’t represent a big market. They brought a Devanagari font (for Hindi) to the iPhone but shipped it with the chhoti-I matra broken; this is one high-impact bug. One possible explanation is that their system font library (FreeType?) doesn’t yet support OpenType features that enable glyph re-ordering etc., which Indic scripts rely on. But why ship the font with the phone if you know you can’t render it correctly yet? I have to assume that they intended to support this (because they owned the font anyway) but that their QA was broken.
   

In general it’s safe to assume that Apple isn’t interested in supporting non-mainstream scripts unless they have to; Arabic has to be a bigger market than Hindi and the iPhone still doesn’t support Arabic despite being available now in Jordan, as of early Feb 2009.



2. Fixes in the firmware henceforth won’t work for users who’re on older firmware. You can’t discount that some people might not upgrade.



3. It should be easier to port the font engine to the other prominent mobile platforms: Android, Symbian, Blackberry, Java ME, Palm, etc.

But why bitmap fonts? Doesn’t everyone use TrueType now?

1. They’re easier to construct than TrueType fonts, especially if you only need them at a small number of point-sizes. I expect redistributable licenses for existing Indic fonts will be hard to obtain and will be missing the more exotic diacritics and ligatures in any case. The fonts that do come with OS X are certainly missing some of these.



2. The rendering and glyph-alignment will be far simpler to code, and smaller, which is all good in a mobile app.

I’ve made a little progress; I’ll report it here as I go along.