Archive for June 2008

[Update The site webfonts.info has a list of the fonts available for embedding, and two of the three fonts I list below (Liberation and Vera) aren’t present. So although these fonts are freely redistributable, it seems they’re not actually available for embedding. I’m not what the legal distinction is—?]

Safari now supports downloadable fonts, meaning that—from a technical perspective—web pages can appear in pretty much any font the designer chooses. (A clumsy Flash-based technique called sIFR made it possible to use different fonts for headings, though not body text.) In fact, if you’re using a recent version of Safari, and are viewing this on the web, this sentence will appear in Gentium Basic.

Unfortunately, the license agreement for almost every high-quality font prevents them from being redistributed, and therefore from being used on web pages in this way. However, there are a few exceptions:

• Gentium Book Basic — from SIL
  
• Liberation — from Ascender/RedHat; has the same metrics as Times New Roman, Arial
  
• Vera — from Bitstream/GNOME; no seriffed italic
  

An article on A List Apart describes how to create web pages with embeddable fonts; here’s CSS files for Gentium, Liberation and Vera.

For some reason quite a few browsers seem to be erroneously downloading these fonts: only Safari supports embedded fonts at this point, but the server log files indicate the clients with IE 6.0 and IE 7.0 user agents are downloading them as well. Does anyone know why this is happening? Are they indiscriminately downloading all url() links?

[On a separate note, the reason why the SIL are interested in fonts is somewhat interesting: they’re an evangelical Christian organisation with a focus on unwritten languages. (I’m guessing their ultimate aim is to expose as many people as possible to the Bible, though their academic linguistic work seems reasonably separate from their missionary activities, and their work is respected in academic circles.)]

Something that’s been interesting me recently: London’s surprisingly strict hierarchy of high street stores (chains/franchises). There’s shops that are found in rich areas, and shops that are found in poor areas, and never the twain shall meet—you can get a pretty feel for how rich an area is from its shops, as well as what other stores might open up soon. Similar “rules” probably apply to other big cities, but I think London is particularly consistent—you don’t often find a shop in the “wrong” area.

Pearlie and I made up this list (most affleunt to least affluent):

Space NK
Muji
Paul’s
Body Shop
Wagamamas
Pizza Express
Eat
itsu
Pret
Starbucks
Office
Costa
Caffe Nero
Coffee Republic
Blacks
Fat Face
Odd Bins
Sainsburys Local
Tesco Express
Network Mobile Phone Shop (e.g. O2 shop)
Threshers
Rymans
Carphone Warehouse
Snappy Snaps
Holland & Barrett
Foot Locker
JD Sports
Boots
Blockbuster
Londis
Somerfield
Superdrug
Domino’s
McDonald’s
Burger King
Subway
KFC

The rules for what gets included are a little loose, but basically any chain with at least 10 stores in London were included. We didn’t count bigger stores (like H&M, supermarkets) because they’re often destinations in their own right. In some cases, there is a small amount of movement upward. (The fast food chains, for example, are sometimes found about Starbucks level.) Betting shops (William Hill, Ladbrokes) are pretty much the only shops we could think of that can be found pretty much anywhere.

A geohash is a way to encode latitude/longitude into a string such as gcpvjk3c that includes only number and letters, making it easy to pass around in URLs, etc. The Wikipedia entry makes the algorithm seem more complicated than it actually is. The steps are:

1. normalise latitude and longitude to the range [0, 1)
2. convert normalised latitude and longitude to binary (in the conventional way)
3. interlace the bits of the two binary representations to create one binary number
4. convert this number to base-32 (i.e. every 5 bits becomes a character) using a alphabet that includes all the numbers and all the alphabet, with the exception of a, i, l, o

A geohash also supposedly has the property that similar locations have a similar prefix, making it easier for computer programs to figure out similar locations, without resorting to complicated and slow trigonometry that won’t scale to hundreds of thousands of points.

Geohashes do have this property for many geospatial neighbours, but there’s still a most significant bit, and locations either side of it are going to have very different geohashes. Unfortunately, given the location of Greenwich—about 10km to the east of central London—a whole bunch of London locations have very different geohashes. u10hb7951 and gcpuzewfz, for example, are very close to each other.

Moving the 0, 0 point to into the middle of the Atlantic (or anywhere not as inhabited as London) helps with this, but it’s obviously not a robust fix. I wonder how the geospatial extensions to MySQL and PostgreSQL actually work? It’s fairly efficient to convert hashes based on one origin to another, so perhaps they store multiple hashes per location? There must be some clever algorithms for this.

OS X comes standard with many Emacs keybindings (Ctrl-A to move the cursor to the start of the line, Ctrl-E to go to the end, Ctrl-N and Ctrl-P for next and previous line, etc.), and since I’ve been using these keybindings for about 15 years it’s pretty difficult to not hit, say, Ctrl-P when it happens to conflict with WordPress’s shortcut to publish a post… This is pretty much guaranteed to happen at least once whilst writing a post, so this needed to be fixed.

There’s no configuration option to turn this off, and accesskey=”p” is buried in the HTML source and I couldn’t figure out a way to filter it out—so the only thing left is JavaScript.

The fix I came up with is below; I’m just dumping this here instead of packaging it up because I haven’t tested it on IE and it doesn’t work at all on Firefox (though see below for a solution for Firefox). You basically need a plugin like this:

function disable_accesskeys() {
    ?>
        <script type="text/javascript">
        jQuery(function () {
        var l = document.getElementsByTagName("input");
        for (var i = 0; i < l.length; i++) {
            if (l[i].accessKey) l[i].accessKey = '';
        }
        });
        </script>
    <?php
}

add_filter('admin_head', 'disable_accesskeys');

Note: for some reason this doesn’t work with Firefox. (Though neither does Wikipedia’s JavaScript solution, upon which this is based.) However, there’s a better solution for Firefox: you can disable access keys/shortcuts completely by setting the ui.key.contentAccess (access via about:config) preference to 0 (i.e. zero). (Is there an equivalent for Safari?)

Access keys are a bit of a failure, I think. They’re not consistent, not transparent (you don’t know what’s going to happen before hitting a combination), and they can conflict with whatever bindings your users might be using already.

*  *  *

Turns out that the original Emacs keybindings were fixed the way they are because, when Guy Steele was putting them together, about 20 people at the AI lab at MIT were already using Emacs, and so he couldn’t change the bindings without alienating existing users…

A few years ago I asked Google answers for a good, authoritative, durable reference for Emacs keybindings (I wanted to pass this on to people) and didn’t get any good replies. I wonder if one exists now?

Final Emacs keybinding-related note: on OS X, putting DefaultKeyBinding.dict in ~/Library/KeyBindings makes a whole lot more Emacs keybindings available, as well as making Home and End work the way they do on Windows. (i.e. move cursor to the beginning and end of the line.)

This site, like just about every other, links to itself from the header, footer and sidebar. It’s somewhat interesting (and maybe even useful) to know which of these regions are actually being used, and the other day I realised this can be tracked fairly reliably and non-invasively using a cookie with a very short lifetime to store the region.

The way it works is, if you’re on a.html and click on a link that takes you to b.html, as you click on the link on a.html, some JavaScript runs that figures out which region you’re in, and writes this to a cookie with a very short lifetime. Then b.html loads as normal. Then, once b.html has finished loading, the tracking code pulls the region value out of the cookie and sends it on.

The Prototype code to trap clicks:

document.observe('click', function(v) {
    var e = v.element();
    while (e.id == "" && e != document.body) {
        e = e.parentNode;
    }
    Cookie.set("region", e.id != "" ? e.id : null, 20); // short lifetime
});

This finds the first ancestor of the clicked-on element that has a id attribute, and saves that as the region. It is run on every click—not just links—but my site is mostly flat HTML so most clicks do end up as page loads. (If this is not the case, you could add some code to filter out the non-page load clicks.) The 20 seconds is basically a guess that b.html will have loaded completely in 20 seconds—too long and you risk capturing regions from different sessions or browser tabs, too short and you won’t capture regions at all.

In b.html, the region is extracted with Cookie.get(”region”); see init.js (which also defines Cookie.set() and Cookie.get().)