After preparing ebooks for years with HTML and getting frustrated with a morass of divs and spans with classes, I’ve decided to experiment with preparing texts in the vocabulary of the Text Encoding Initiative. Conversion to XHTML for web, EPUB and Kindle formats will be taken care of by some scripts, which may be XSLT later, but for now are Perl scripts.

I am considering working on the PANOSE font matching part of Fontmatrix because I enjoy playing with Fontmatrix, but its idea of how PANOSE’s individual facets¹ are named or work seems to me to be a bit wonky. For instance, it only understands the names for Latin Text facets, and uses them even for Latin Decorative or Pictorial fonts.

The first step (apart from trying to persuade my one-year-old son to go to sleep long enough for me to even turn on the computer), is to take a look at whether improved matching or re-classifying facilities would do any good at all, and for that, I need to take a look at font classifications in the wild.

While working on the Kindle (Mobi) version of Antigua and the Antiguans, I found that I was spending too much time attempting to carefully craft some XHTML markup and a stylesheet that would get the final book to look the way I expected it to. Because the Mobi format is only HTML 3.2 with a few extra elements, and no stylesheet support at all, Kindlegen has to do a lot of wizardry to down-convert any EPUB (XHTML + CSS) you are starting with, and the results don’t appear to be consistent across an entire book.

While hunting for reading matter on the history of Brighton, I came across Anthony Pasquin’s New Brighton Guide. As well as being a very funny satirical poem, he also gives us this prose portrait of Brighton in a footnote:

Brighthelmstone, or Brighton, in Sussex, is 54 miles from London.​—​It was, like Amsterdam, a miserable-fishing town, but is now a place of importance, to which it was raised by the countenance and bounty of the Prince of Wales. The houses are, generally speaking, more inconvenient than unhandsome; and the streets are narrow and irregular. In the year 1699, more than 100 huts were swallowed by the sea; and in a few years more, all the tenements on the Cliffs will be similarly devoured, unless a very formidable embankment is erected to resist that imperious element.

Just when you think you’ve been all clever by putting zero width non joiner characters around em dashes, the Kindle renderer decides to get its knickers in a twist and does this:

The markup that produced the third line of that image was this:

<p width="0">Same bug with <i>italic</i>&#x200c;,
<b>bold</b>&#x200c; or
<span>spans</span>&#x200c;</p>

Do you see repeated words in the markup? No, me neither. Putting a ZWNJ (U+200C) character straight after the end of another element will cause the final word of that element to be repeated.

Kindle Previewer is a great time saver for checking formatting, and I’m very pleased that it runs under Wine, as I’m currently running Fedora 16 (Verne).

However, this morning when I ran it, it auto-updated to the latest version, and that crashes. Auto updating is bad enough when you know you have a set of software that works exactly as you like, but updating to a version that won’t run is just bloody rude.

I like em dashes, and use them when writing (or preserving the style of older books when I’m formatting them), but they need some taming for the Kindle, as discussions on MobileRead will show you.

If you attempt to insert them between two words without any spaces, the Kindle will stubbornly keep both words together when breaking lines. A simple way of getting round this would be to use a spaced en dash instead, as Jaye Manus suggests, but can we do any better?

My first upload to the reborn Open Font Library was Segment14, and it failed badly as a web font in Firefox 3.6.17 on Fedora, not displaying at all.

Christopher Adams confirmed that it worked on the WebKit-based browsers Safari and Midori, and it works on my HTC Desire.

After some minor, unrelated, cleanups, FontForge gave both the SFD and OTF files a clean bill of health, but it still wasn’t working in Firefox, so I took a deeper look and found that Mozilla had added the OTS font sanitizing library to Firefox from version 3.6.13, back in December 2010.

It seems that, whenever I get close to doing something interesting in fonty land, a tool fails.

I’m pleased to see that the Open Font Library is now accepting uploads again but I can’t see my first font, Segment14.

I’m using Firefox 3.6.17 on Fedora 14, and it stubbornly refuses to show up as a web font. As far as I can see, every other one of the 36 fonts on the site displays correctly, but Segment14 shows up as the fallback serif.

Wow, that was a meaty piece of work. Serafettin Cartoon fonts now builds with the latest release of FontForge, as well as CVS head, and taught me quite a bit about FontForge in the process.

Serafettin had a bunch of glyphs with self-intersection problems, and these were causing FontForge to crash on the Expand Stroke operation. Because Serafettin uses scripts to build the different weights, it was hard to see where the problem was until I made FontForge a lot more verbose about which glyphs it was processing.