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.
Christopher Adams took a look for me and says that it works just fine on Safari and Midori, which suggests that the fault lies with Firefox, but I’m left wondering which bug I’ve tripped over.
This is bug 789283 on OFLB’s Launchpad, in case anyone has any clues.
I have a Samsung X120 notebook. Commiserate with me, please, for ever since F13′s kernel went from 2.6.33 to 2.6.34, I’ve been without ACPI. Anything other than acpi=off in the boot settings produced a giant stack trace that scrolled off the tiny screen so fast and so early in the boot that only videoing the screen would have enabled me to transcribe it. Even boot_delay didn’t work, because that won’t delay every line of output when the kernel is curling up in a corner and dying.
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.
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.
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.
