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.

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.

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.

I’ve recently been triaging FontForge bugs on Fedora, and hit a problem with bug 600108, in which the latest version of FontForge crashes while building Serafettin. I patched FontForge locally, so I could identify the glyphs that caused it to crash, but I’ve now come to the conclusion that Serafettin itself is the problem, and FontForge’s validation says as much, in these lines: Two glyphs have the same name. Two glyphs have the same unicode.

Adam Hyde came up with a question about a misrendering of a font on the FontForge Users’ mailing list. A colleague had designed a font in FontForge which looked fine except when used in Adobe Illustrator (of unspecified version). He provided two examples of characters whose shapes had developed distinct “ears”. Peter Baker suggested that the common feature in this case was that the first point of the contours was not on the curve.

A colleague of mine wanted to reduce the repetition in this fragment of C++: funcA(false); funcB(false); funcC(false); funcD(false); funcA(true); funcB(true); funcC(true); funcD(true); and, in a burst of sheer genius, came up with this solution: for (bool status = false; status <= true; ++status) { funcA(status); funcB(status); funcC(status); funcD(status); } He then scratched his head as the program looped for eternity. Who could have predicted that a common-or-garden bool could have so many values?