Fonts on His Deeds Are Dust

PANOSE in the wild

Tue, 09 Oct 2012 11:56:33 +0100

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.

Turning to my Font Corpus database, I’ve extracted the following bare facts about PANOSE usage, and I’m quite buoyed up by the results.

From the 35420 fonts in the Corpus, I first get rid of fonts that have complete rubbish in the PANOSE field, which means discarding fonts with:

Family Kind of “Any”(0), which means no attempt at all was made at classification. (13863 fonts).
Facet values out of range. This is generally Weight, which for some reason, perhaps tool error, tends to have the values of 114 or 226. (409 fonts).
Family Kind > 5. Family Kind values up here, which would be used for non Latin, aren’t formalised in any document I can find. (12 fonts).
Weight of “Any”(0). Weight is the only facet that is present for all values of Family Kind, so it really ought to be set to something, even if “No Fit”(1) is the only appropriate value. (1540 fonts).

Having cleared out the rubbish, we are left with 19596 fonts, 55% of the total collection. Of these, just over 90% are Latin Text fonts.

For the Latin Text fonts, more complete classification means that more of the individual facets are set to any value other than “Any”(0). Even “No Fit”(1) gives us some information about the limitations of the classification system.

So, how many facets are set to non-zero in our remaining fonts?

Non-zero facets	No. of fonts
3	349
4	1718
5	135
6	1391
7	6712
8	226
9	66
10	8689

Some of these facets are derived from measured values, and some of them are picked by judgement, which may explain the somewhat uneven coverage of classifications. (And who’s going to classify nine of the facets without doing one extra to complete the job?)

I think the end result is that there are enough fonts with decent classification in the wild to make this something worth working on. Go to sleep, baby boy!

I call the individual numbers of a PANOSE number “facets” to help me from over-using the word “value”. ↩︎

Serafettin, part two

Fri, 20 Aug 2010 15:27:16 +0100

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.

Serafettin, part one

Fri, 13 Aug 2010 15:48:04 +0100

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.

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.

Off-curve misrendering

Wed, 07 Jul 2010 18:26:15 +0100

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. My investigations proceeded along the same lines, and suggested that more than just these two characters were affected.

I’ve modified the supplied font, Transmediale, to suggest how I think Illustrator will render all of the characters that I think will be misrendered. I’ve shown the “ears” in the image below.

The fix is simple enough in this case, as the start point of the contours can be changed in FontForge.

A quick test suggests that DejaVu fonts may also be misrendered. We will see.

An old video terminal, in vector form

Fri, 27 Nov 2009 15:03:34 +0000

I still have VT100 terminal, but it’s in storage. I figured I could pretend that it was on my desk if I made a font that looked like the old beast, including the gaps between scan lines.

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.

Resurrecting fonts

Wed, 11 Nov 2009 00:00:00 +0000

A while ago, I recovered my old font files from some crufty old SuperDisks, but did nothing more with them than copy them to my network storage, in the hope that that is a safer home.

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.