iFiddling

BDF support added to Mobile Font Engine

2009-03-01T21:04:00.001+05:30

As I suspected, BDF was not hard to support. Here are a couple of layouts in iPhone-sized screens, 320x480 and 480x320.

The following features Thomas A. Fine’s Atari-Small:

And this is -Bitstream-Charter-Medium-I-Normal--19-180-75-75-P-103-ISO8859-1:

A review of the Shortcovers app for the iPhone

2009-02-27T08:19:00.002+05:30

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:

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

2009-02-23T07:38:00.000+05:30

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

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?
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

2009-02-10T12:35:00.002+05:30

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?

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.

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.

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?

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.

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.

A temporary fix for Hindi (Devanagari) on the iPhone

2009-01-27T19:49:00.006+05:30

As I explained in my last post, the Devanagari rendering situation on the iPhone is dead on arrival. To wit, the chhoti-I matra (the vowel ‘i’ as in kick) is always rendered one position to the right of its conventional placement.

While explaining the problem to a keen-eared buddy this evening, it occurred to me that there was a simple fix ad hoc:

shift the chhoti-I matra one position to the left in the encoding

This is just fixing the symptom but there’s nothing else to be done (short of providing one’s own font engine) while we wait for Apple to fix this in the firmware. In any case, the lack of any symptoms is all that the discerning public cares for.

I’d remember to check for firmware version to be at most 2.2 with a message to [[UIDevice currentDevice] systemVersion], and remember to update things accordingly when the next firmware version is released.

Xcode:

iPhone simulator (correct - for now):

Hindi is broken on iPhone (as of 2.2)

2009-01-21T21:51:00.003+05:30

This afternoon I decided to wrap the (public-domain) text of a Hindi short story (by) in a little application to run on my iPod Touch, as what you might call a standalone e-book. I hadn’t really done any Hindi browsing on the device so far but when I’d first tried it I had easily managed to rename a well-known Hindi song successfully from ‘Mere Mehboob’ to , and it’d showed as such on the iPod.

So, naturally, I was encouraged and had expected things to go smoothly with the little ebook app.

Fail! The Devanagari script (Hindi as it is written) is badly broken on the iPhone platform. The chhoti-I matra, the short ‘i’ sound as in kick does not render correctly at all.

It should be before the consonant to which it is attached:

It renders instead as follows, after the consonant:

This is not a valid expression in Devanagari. It is lamentable that Apple went far enough to support the script at all and then neglected this little show-stopper at the tail end. Especially because it works well on OS X and you’d think they’d share some tests with the iPhone platform.

Xcode (correct):

iPhone simulator (incorrect):

You could disregard this and get by with a mental re-ordering of the I-matra if you must, but it’s still not what you’d expect in an Apple device.

Use the Mac's accelerometer in the iPhone Simulator

2009-01-06T16:06:00.003+05:30

The accelerometer is not simulated in the current iPhone SDK (for iPhone OS 2.2).

Otto Chrons has posted a neat package that sends accelerometer data from an iPhone or iPod Touch to an application running in the iPhone simulator. This package is in two parts: a ‘server’ that runs on your iPhone hardware and a ‘client’ in the form of source code that you can drop into your project (adding just an #import statement).

This works really well, except when:
1) you don’t have an iPhone or iPod Touch, or
2) you’re not registered in the Standard or Enterprise iPhone Development programme; I wasn’t registered at the time, and so I had no way to push Otto’s server application to my iPod Touch.

But then it occurred to me that my MacBook did have an accelerometer. If only that could serve data to the fake accelerometer in the simulator... So I looked, and providentially enough, UniMotion hove into view.

So I browsed the source for the two packages for a bit, with a view to nefarious smash-and-grab, but by more happy chance it turned out that the relevant pieces in both were modular enough to fit as they were, with a little python for glue.

Otto’s client expects a string with timestamp and x,y,z readings over UDP, and UniMotion’s motion is kind enough to spew x, y and z readings to standard output, though they’re not oriented in the same directions as those in the iPhone SDK’s UIAcceleration.

On my late 2006 MacBook, motion emits x,y,z with a positive magnitude to the left, towards me and downwards, respectively. UIAcceleration expects readings to be positive to the right, away from me and upwards, respectively.

So all I needed to do was to grab motion’s output (with the -f flag for acceleration in units of G), multipy each value by -1, add a timestamp and broadcast over UDP on the given port in the format that Otto’s client expects. I did need to run calibrate in the UniMotion suite first.

Here’s my python glue:

import sys, socket, time, traceback

kCFAbsoluteTimeIntervalSince1970 = 978307200.0 # from CFDate.c

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(('',0))
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)

while 1:
  try:
   line = sys.stdin.readline()[:-1] # read line and strip EOL
   fields = line.split() # split around space character
   floatfields = map(float, fields) # convert to floats

   # transform co-ordinate system, from SMS- to UIAcceleration-format,
   # for my macbook (late 2006)
   x, y, z = map(lambda x: -1 * x, floatfields)

   # change epoch to be compatible with CFAbsoluteTimeGetCurrent()
   currentTime = time.time() - kCFAbsoluteTimeIntervalSince1970

   accdata = ','.join(map(str,('ACC: 0',currentTime,x,y,z)))

   sock.sendto(accdata, ('<broadcast>', 10552))
   # print '% .2f % .2f % .2f' % (x, y, z)
  except (ValueError, KeyboardInterrupt):
   sock.close()
   sys.exit(-1)
  except:
   traceback.print_exc()

I call this sendaccsim.py and run it as:
$ ./motion -f 17 | python sendaccsim.py

It’s just a bit awkward swinging the Mac around like a tea tray.