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 bet that there’s a cute SELinux trick that could be used to stop Kindle Previewer having network access, but a simple stop-gap is to reinstall the old version, go to the directory where you installed it, and prevent autoupdate.jar from being used. In my case, that’s these two lines:

 $ cd ~/.wine/drive_c/Program\ Files/kindle\ previewer
 $ chmod 0 autoupdate.jar

Kindle Previewer now moans that it can’t access that jar file when it runs (duh), but pressing “OK” allows the rest of it to run just fine. I’ll investigate more when I decide I want to see how things look on the Kindle Fire, and that’s not going to be until they’re available in the UK.

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.

OTS is mainly designed to be added as a font condom for OpenType-consuming applications, as Firefox apply it, but it also has a standalone checker called ot-serialize. OTS isn’t packaged in Fedora yet, so I collected it from upstream and ran it over my font, with these results:

ERROR at /home/paul/projects/ots/ots-read-only/src/cff.cc:377 (bool::ParsePrivateDictData(const uint8_t*, size_t, size_t, size_t, ::DICT_DATA_TYPE, ots::OpenTypeCFF*))

Ugly. Still, it’s a “yes/no” tool, so I’m prepared to do a little hunting through the source to find out exactly why it hates me.

The answer is that my FontForge source had a definition of BlueValues in the Type 1 Private dictionary. I don’t remember how it got there, because it is optional, but I had put one in, and I had defined it as an empty array. OTS decided that, if arrays exist in the Private dictionary, they must not be empty. With a quick snip, my font works again.

I’ll certainly be adding OTS to my fonty toolchain, and it strikes me that this would be a useful tool for packaging and using in font reviews. You wouldn’t want to fail a review because of it, but it would certainly help to know whether a font will fail on the Web, which must be a large part of users’ expectations now.

It’s a bug in the Samsung BIOS no doubt, and it has an upstream kernel report, but the bisect points to a sane commit that’s good for everyone else.

Running without ACPI isn’t a realistic option on a laptop. I wouldn’t know when to plug it back into the mains, and shutting down requires rather more persuasion than should be necessary, so last night it was time to patch the kernel.

Fedora Wiki to the rescue. I followed the instructions on building a custom kernel to the letter, and eleven hours later, I had a functioning laptop. I’ll break that down, lest you think me hard of understanding: five minutes to read the page, 20 minutes to grab the kernel src.rpm and make the appropriate patch, and 10 hours and 35 minutes to compile the entire thing on the laptop. I went to bed for the last bit, after ensuring that the mains was plugged in and on so that my laptop wouldn’t do the same.

So, to everyone who has had a hand in that page on the wiki, thank you.

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.

Even so, if a glyph self-intersects, it might be impossible to spot how the intersection is happening until you zoom right in and see that what you thought was a sharp corner turns out to be a little twisted triangle of points. If the points are right on top of each other, you won’t see the problem at any zoom level, so you’ll need to trust the Simplify operation.

After all that work, I now have another FontForge bug to report. Try typing a some text ending in ‘+’, like ‘GPLv2+’ into the the TTF name fields. Save your work and observe that the UTF-7 (yes -7, not -8) encoding of the SFD turns this into ‘GPLv2+-’. Now read in the SFD and see that your license field says ‘GPLv2+-’, and subsequent saves will add another ‘-’ every time. Boo, hiss.

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

I’ve never met these errors before. Sure enough, close examination of Serafettin reveals that there are three copies of some of the glyphs in the font, with the same name and Unicode point. Now that Orcan has given me access to the Subversion repository, I’m currently working on removing the incorrect copies of glyphs, before simplifying the outlines of the rest, to allow it to build again.