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.

The simplest starting point seems to be TTX, which can take a TrueType font and convert some or all of it to an XML document. From then, anything that can parse XML or plain text should help. I’ll just extract the TrueType “name” table:

$ ttx -t name font.ttf

This creates a file called font.ttx. Annoying, I can’t send the output to stdout, and I can’t ask that it overwrites any old file of the same name; it’ll just insist on creating font.ttx, font#1.ttx, font#2.ttx and so on.

If we take a look at font.ttx, we can see the field I’m interested in, in a namerecord element with attribute nameID of 13:

<namerecord nameID="13" platformID="1" platEncID="0" langID="0x0">
       This font software is copyright (c) 2007, Frixxon Wanglewurx. All rights reserved.&#13;&#10;"Frixxon Muck" is a Reserved ...
</namerecord>

The entire licence is extracted as one line in the XML output, with carriage returns and line feeds encoded as 
 and 
, respectively. There may be more than one copy of this licence, with different platformID values.

To go from here to a text file with no more than 80 characters per line and LF endings, I could either use sed or xsltproc. Let’s take a look at how both would work. Here’s getlicence.sed:

/<namerecord nameID="13"/ {
  n
  s/^ \+//
  s/&#13;//g
  s/&#9;/\t/g
  s/&#10;/\n/g
  s/&amp;/\&/g
  p
  q
}

Which reads as: find the namerecord, skip to the next line, strip leading spaces, convert some XML entities to text, print it and quit.

I’d invoke this with:

$ sed -nf getlicence.sed font.ttx | fold -s > LICENSE.txt

Yes, despite using the British spelling of licence normally, I’ll use license for packaging.

The XML entity conversion is a bit of a faff which a proper XML tool could take care of for me. Here’s getlicence.xsl:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text"/>
<xsl:template match='/'>
  <xsl:value-of select="//namerecord[@nameID='13'][position()=1]"/>
</xsl:template>
</xsl:stylesheet>

I’d use this with:

$ xsltproc getlicence.xsl font.ttx | dos2unix | fold -s > LICENSE.txt

There are plenty more tiny hacks that TTX and XSLT can help with. I haven’t yet tried many round trip conversions with TTX, but if I lose my way in FontForge’s Font Information menus and dialogs, I could be tempted.

Once I’d started, I needed the reverse video form of it, and the forms correctly underlined, and double width, and double height and double width. Blinking is more problematic

The challenge with the double height, double width font is that the VT100 had escape sequences that made particular character rows either display just the top half of characters, or the bottom half. To display characters double height, you had to put the same characters on two consecutive rows, and set the line attributes correctly. In fact, you could make up some funky alien characters by setting the line attributes and typing different characters on each row.

In order to reproduce this effect (yes, I’m carrying on digging), I had to make an upper half font, and a lower half font. And that gives me a problem with Fontconfig, because that takes a look through fonts as it caches them, and marks glyphs as broken if they don’t make any marks, but they are encoded at positions which aren’t space characters in Unicode. My “upper half” font doesn’t have any marks for the underscore glyph, and my “lower half” font doesn’t have any marks for the double quotes, for example.

There isn’t a way of telling Fontconfig that my font isn’t broken just because it didn’t fancy making any marks for a particular glyph, so I’ll have to do some pre-processing when generating “screen shots” of my old terminal. I can locally configure Fontconfig to not do this, but that wouldn’t help anyone else.

Last weekend I was reading about the Fedora Fonts SIG, and decided to bring the old font files back to life. The Fonts SIG is concerned with packaging fonts for Fedora, but their pages have some interesting pointers on how they might be created as well, so I grabbed an old font and explored the tools that are available.

The font I picked is one I created when I was working with an old Stag PROM programmer, back in 1996. The programmer had a 14-segment LED display. The real thing doesn’t look much like the clean vertical pictures you’ll see in that Wikipeda article. The real characters are slightly oblique and there seems to be a kind of hexagonal mesh over the top that makes the segments look like the figure at the top of this posting.

I originally created the font by hand-coding the Type 1 format on a Sun workstation with Ghostscript installed, using my own tools to transform some readable path descriptions into the encrypted form.

This time, it seemed sensible to update the font to OpenType format, and I decided to use FontForge for the job.

Importing the old PFB file worked OK, and exporting is a doddle, except for FontForge complaining about overlapping segments in the font. There aren’t any, but there are some subroutines that move back to the glyph origin, causing some empty subpaths, which FontForge doesn’t ignore.

The only other problem was my attempt to upload the font to the Open Font Library, because the upload facility is broken. Ho hum.

Here’s the result of my hacking, a font called Segment14, released under the SIL Open Font License (OFL): segment14-1.0.tar.gz.

However, I have confirmed that grabbing and patching kernel-2.6.30.9-90.fc11.src.rpm works me.