Blackcap Blog

Published at 08:28 on 2 May 2018

Because I’ve had a strange fixation on how to do it (it’s not really practical, given the many limitations and deficiencies of the program), here’s how to add fonts to Groff. Note that when I write “Groff” here, I mean Groff with the PostScript output option.

1. Obtain Ghostscript and Fontforge. You will need both in order to add fonts (and if you don’t have Ghostscript, Groff’s usefulness is severely compromised, as per the first link in this article).
2. Determine the location of your installation of Groff’s textmap file. Typically this will be in a location like /usr/share/groff/version/font/devps/generate/textmap.
3. Create a directory to hold the Groff fonts and font metrics files you will be generating.
4. Create a devps subdirectory to this directory. All the files you create should be in this subdirectory.
5. Open each font in Fontforge. Note that a typical font family contains four fonts: a normal font, an italic font, a bold font, and a bold italic font. You will have to do the steps below for each of the four fonts in each font family you wish to use.
6. Perform the editing steps in the list immediately below on each font.
7. Close Fontforge, if desired.
8. For each type 42 font you generated, extract an AFM file:
   printafm name.t42 > name.afm
9. Think of a name you wish to call the font on the Groff side. The Groff convention is to have families of fonts that end in “R,” “I,” “B,” and “BI” (for roman, italic, bold, and bold italic variants). E.g. “BaskervilleR,” “BaskervilleI,” “BaskervilleB,” and “BaskervilleBI.”
10. For each AFM file, generate a Groff font metrics file (replace textmap-path with the location of the textmap file you determined in step 2 and groff-font-name with the name you came up with in the previous step). If the font is not italic, type:
    afmtodit -i0 -m name.afm textmap-path groff-font-name
    If it is italic, type:
    afmtodit -i50 name.afm textmap-path groff-font-name
11. If your font contained ligatures, verify the ligatures line in your Groff metrics file is present and contains all ligatures.
12. Create a download file in the font directory by following the final list of instructions below.

Editing steps in Fontforge:

1. Disable all Apple Mac features, as they are broken in Fontforge: Go to File > Preferences > Mac, delete all entries in the Features tab, then verify the list in the Mapping tab is empty as well. You should only have to do this once for each editing session.
2. Open the font file you wish to add to Groff. You will typically have to know where your system keeps fonts in order to do this. This of course varies from system to system.
3. Clean up the ligature substitution tables. Modern font files can have complex ligature substitution rules, which tend to confuse Groff. The only thing Groff can support is a single liga table. Select Element > Font Info > Lookups and examine the GSUB tab. If there’s any more than one liga entry, you will have to delete the all but one. If there’s any clig, alig, or dlig entries, they will have to be deleted. Then edit the single remaining liga table and make sure it does what you want. Note that since Groff only supports the fi, ff, fl, ffi, and ffl ligatures, these should be the only ones listed in your table.
4. Correct the names of your ligature glyphs. Some fonts use ligature names like “f_i,” “f_l,” “f_f_i,” etc. These will confuse Groff. Only names that exactly mirror the character sequence to be replaced by the ligatures (e.g “fi,” “fl,” “ffi,” etc.) are supported. To do this you must locate the ligatures in the glyphs list (they start at Unicode codepoint FB00), click on the glyph of the appropriate ligature, then use the dialog in Element > Glyph Info to set the name of the glyph.
5. Save the font (using File > Save) as a .sfd file. This step is optional, but can be useful if you forget or botch one of the editing steps listed above.
6. Generate a type 42 font using File > Generate Fonts. Click on the “Options” button and make sure “TrueType Hints,” “PS Glyph Names,” “OpenType,” “Dummy DSIG,” and “Lookup Names” are checked. No other boxes should be checked. Fontforge may complain about some things being slightly amiss when you try to generate the font. In my experience it has usually been safe to ignore the warnings and just generate the font file.

Steps to create the download file:

1. Start by copying the download file from the existing fonts storage area to the Groff font directory you have created (it will typically be in a file like /usr/share/groff/version/font/devps/download).
2. For each font file you added, you will have to add a line to the download file. Each line in the file contains the “internalname” value from the Groff font metrics file and the name of the type 42 font file, separated by one or more tab characters.

And that’s “all” you need to do. If you set the GROFF_FONT_PATH environment variable to point to the font directory you created, you should now be able to use those fonts in Groff. The font names you use in Groff will match the names of the Groff font metrics files.

(Updated 16 May 2016 with corrected instructions for running afmtodit.)

Published at 01:27 on 14 April 2018

Groff is an old-school text formatter that’s shipped with every Mac. Why? Because Macs are Unix systems under the hood, and the documentation for all the command-line tools is in Groff, because the Unix manuals have always been in Groff (or some very similar predecessor).

Being sort of a diehard, until fairly recently I’ve used Groff for typing letters, a résumé, and such. Why not? I know it, and it still works fine. Why spend time learning something else?

Well, it worked fine until a year or so ago, then I noticed (after upgrading MacOS) that most of the fonts seemed to have vanished. If you’d use a font other than Times Roman, it would tend to just use Times Roman anyhow, but with the spacing of the other font. Total ugly mess.

After ages of wondering what’s up (and doing web search after web search to research the issue), I finally found what Apple broke. Not Groff; it still works fine. It’s the Mac’s built-in PostScript tools that are broken.

Historically, PostScript devices have all supported a set of basic core fonts. Groff as shipped just uses those fonts. It knows their metrics but it has no other data about them. It assumes the device will know how to render them. For some reason, Apple’s pstopdf tool has ceased to support most of those fonts.

The fix is to use install and use Ghostscript, which still knows about the core PostScript fonts. Or, in my case, simply to use Ghostcript, which I had installed some time ago, having used it before I became aware of Apple’s pstopdf tool.

That said, it’s a fairly limited suite of fonts that Groff knows about by default, and it’s a pain to install other ones. Groff doesn’t understand normal TTF or OTF files (in the normal system locations for such installed files) like most other programs do. The tools to generate the files that Groff can understand are both (a) poorly documented, and (b) prone to getting tripped up by anything a font does that’s the least bit unusual (albeit legal and allowed).

Add that to Groff’s extremely limited support for mixing text and illustrations and lack of Unicode support, and it’s time to use something more modern for most purposes. Still, it’s nice to know the trick for getting the system documentation (and my old documents) printing normally again.

Published at 18:47 on 21 March 2018

There is a shortage of decency in the high-tech industry.

I base both these assertions on my experiences at the symposium today, where I met not one but two other individuals in basically the same situation as I am. As long as the high-tech industry considers the following non-qualifications to be job requirements:,

• Male,
• Between the ages of twenty-five and fifty,
• Thinks coding is the most fun thing in the universe,
• Thinks coding is about the only truly fun thing in the universe, really, and
• Outside of role-playing games, martial arts, and science fiction and fantasy fandom, thinks there’s basically little else of interest besides computers.

Then, yes, that industry will continue to suffer a “shortage” of “qualified” people.

Published at 13:32 on 18 March 2018

The trick to using Fontforge is to realize: (a) that its Apple Mac support is broken, and (b) Apple Mac support really isn’t critical; in fact, it’s missing from most non-Apple-supplied fonts anyhow, yet Macs manage to work just fine with them. A further wrinkle is that Fontforge tends to want to gratuitously foist its broken Apple font features onto you, and having done so, to then conceal this fact from you when you examine the broken font files it has generated.

Naturally, you must leave “Apple” unchecked in the File > Generate Fonts > Options window. But that’s not enough! Unless you go into File > Preferences > Mac, delete everything from the Features tab, then verify the Mapping tab is also equally empty, you’ll still get a broken font that will fail to work properly on a Mac.

Having done all that, though, I’m finally able to edit out the stupid kerning pairs that have been vexing me and no longer have to cope with them after-the-fact. Hurray!

So I’m now not only taking offense at the way stock fonts I find work but also editing them to suit my preferences. I guess this officially makes me a font geek.

Published at 16:03 on 15 March 2018

Trying to edit free fonts with Fontforge is something of a challenge. That’s because Fontforge is open-source software and falls victim to the bane of open-source software: documentation. Writing code tends to be more fun than documenting it, so open source projects that depend on unpaid volunteers tend to lag way behind in documenting. Fontforge is no exception to this general rule.

I could probably address the issue by purchasing a commercial font editor, but that would cost more money than just purchasing some commercial fonts that don’t have the sort of issues my free downloaded ones do. So I’m stuck living with the issues (related to broken kerning definitions) as best I can.

Published at 11:49 on 6 March 2018

I’m not exactly in the market for ordering fonts (strictly limited budget), but I’ve been playing around on the web sites of various foundries looking for a font that gets the late-19th century look for text that I want. I think I’ve found one: Monotype Modern.

It was the first font cut by the new Monotype corporation for their new typesetting machine, in the 1890s, so it reflected the design sentiments of the time. Plus it comes in various widths and variants, which is important if you want to do things like set headings in a condensed, expanded-spaced version of the body text (as was the fashion in the era).

But, the fonts come in a confusing number of varieties: a plain version, a “Std” version, and a “Pro” version. Some quick testing revealed that the plain versions of fonts typically lack all ligatures, the “Std” version has “fi” and “fl” only, and the “Pro” version has the full set of ligatures.

So, basically, if you’re not ordering the “Pro” version, you’re ordering some dumbed-down garbage being marketed to computer geeks who know virtually nothing about proper typography. Note that the original Monotype Modern font came with a full set of ligatures, so it’s totally honest to paint non-Pro fonts as subpar. Because they are.

And that explains why Times Roman is such a mess. The “Times New Roman” that Apple distributes via Microsoft is the plain version of the font. The “Times” they distribute is the “Std” version. The only “Pro” grade serif fonts distributed with Mac OSX are Baskerville and Hoefler Text.

It’s a pity that Apple chose to distribute what amounts to a subpar variant of Times Roman. It’s not a surprise Microsoft would choose the lowest of the low quality grades, but one tends to expect better of Apple.

The consolation is that the Hoefler Text and Baskerville fonts they ship are top-quality serif fonts well-suited to body texts. I highly doubt if Microsoft ship anything remotely comparable with Windows as a standard item.

Published at 11:43 on 4 March 2018

Some thoughts, after experimenting with the system fonts in Mac OSX 10.13, trying to achieve an effect as close as possible to the typography of the late 19th century as I can with just the stock system fonts:

• Most of the fonts are not really suited for (or even designed for) body text at all. I find a lot to like about the Didot font, but I struggled to get it to look right when formatting paragraphs with it. Turns out the Didot shipped with the Mac is a variant which was never intended for use as a text body font at all.
• Fonts that support ligatures (a basic element of well-set text) are the exception rather than the rule.
• Both Times New Roman and Times are big disappointments. The former comes to the Mac via Windows (and originally Monotype) and does not support ligatures at all. The latter is derived from the Linotype Times Roman font but is missing the “ffi” and “ffl” ligatures (which are present in the version of the font sold by Linotype). So the former looks tacky and unprofessional and the latter possibly even more so; the rendering of an “f” followed by an intra-letter space and an “fl” or “fi” ligature looks quite awful indeed.
• The only quality serif fonts I’ve found that seem really appropriate for body text are Baskerville and Hoefler Text.
• I find so-called “old style” numbers the best for text. Those are the numerals that vary in height and spacing, instead of all being the size of capital letters and monospaced like they are in most computer fonts.
• Of the two fonts I just mentioned, only Hoefler Text has old style numerals.
• One of the things I like about old books is how sharp and crisp their characters tend to appear. Until fairly recently, modern offset printing just couldn’t approach the look that only actual physical raised type pressing into paper could achieve.
• Unfortunately Hoefler Text has a very modern-press un-sharp look to it, despite having old style numbers and elegant ligatures.
• That said, Hoefler Text is still one of the better system fonts to use for body text, particularly given that it’s apparently the only system font that supports both ligatures and old style numerals.
• Baskerville has more of the classic crisp sharp look I like. I wish the version on the Mac had old style numbers.
• Another useful system font is Optima. It’s a sans-serif font that’s more readable when used as a text body font than Helvetica. It’s sometimes useful in a document to have some alternate, contrasting font to set off certain text passages from the main document body. (Just using italics is awkward, because what if you want to italicize something in the passage?)

Ultimately, I’ve sort of given up on getting that “19th century look” for now. For one thing, money is tight and I don’t want to blow it on third-party fonts (and I’m sure it would be plural; as I’d need to evaluate a bunch before choosing a few winners). For another, I don’t create printed documents all that much.

Published at 17:52 on 3 December 2017

If you go to the Open Street Map Wiki, you can find pages like this one giving helpful information about how map tiles work, and how tiles map to latitude and longitude.

But you don’t see any mention of a technique I call world pixels, an idea that woke me from a dream last night and which implementing put an end to countless headaches in getting map bounds just right.

Consider the following facts:

• Zoom levels run from 0 through 18.
• Each zoom level, Z, has 2^Z tiles in each direction.
• Each tile has 256 (2⁸) pixels in each direction.
• 18 + 8 = 26.
• 26 ≤ 32.

Therefore, at all zoom levels, it is possible to code the (x, y) coordinates of all pixels in all tiles with two globally unique 32-bit integers. Put the tile pixel dimensions in the 8 least significant bits and the tile numbers in the next 18 most significant bits. Translate your lat/long coordinates to world pixels as early as possible in the process, and all your math then becomes integer math, which runs faster and is free from rounding errors.

Better yet, it makes zooming a breeze. Want to zoom in? Shift left; the most significant bit of the tile pixel number will become the least significant bit of the tile number. Likewise, want to zoom out? Shift right.

Simplicity itself; both easier to understand and it offers faster execution times and it produces more accurate results.

Published at 06:13 on 24 November 2017

Developing a web site to report information in graphical, map form has given me a new appreciation for how much client-side Javascript (a technology I have never much liked to start with) sucks.

In fact, Javascript was never really the first choice for this site. If there was a simpler, purely declarative way to draw a map that used tool tips to display the details of each observation, I’d have used it in a heartbeat. But there doesn’t seem to be, and moreover, the best package I could find for presenting maps used Javascript. So Javascript it was.

The problem is the execution environment for mobile devices. It simply varies too much. For desktop browsers it was fairly easy to come up with a page that worked well with every browser I thought to try. Mobile sites have so far frustrated that desire. What I have works on my iPad, but no friend’s smart phone has made it work likewise. Some don’t let one zoom in at all. Some zoom in but always draw the dots ridiculously small (despite their being specified as 4 pixels in diameter). Some don’t register touches that call the touch callback. And so on.

It shouldn’t have been a surprise, really. It’s not as if most web developers are totally incompetent, yet attempting to use Javascript-heavy web sites on a mobile device is always asking for trouble. Those developers weren’t lazy or incompetent, they were just fighting against a platform that does its best to frustrate portable coding.

The rub is, tool tips are really needed to present as much information as I want to in a single graphic. As such, it’s probably time to realibrate my wants and make Javascript avoidance first and paramount. If presenting that much information requires Javascript, then presenting that much information in one graphic is the wrong goal. Time to come up with a version of the site that is basic, static HTML and point mobile users there.

Published at 10:44 on 21 November 2017

Circa 2011 I dumped Safari for Firefox. Safari had come out with what I term a “turkey upgrade” that made it painfully slow. Plus, Safari’s Javascript engine has always tended to suck. Add to that the recent slowness factor and it was worth putting up with how Firefox’s UI sometimes annoying departs from normal Macintosh standards.

Now Firefox has come out with a turkey upgrade of its own: Firefox Quantum. It’s almost hideously ugly and un-Mac-like. There’s so much clutter up top that the box that you enter the URL to browse to in can almost never display the whole URL at once any more.

Worse, the designers made the atrocious decision to devote the entire top part of the window to the browser tabs; there’s not much place to click on if you just want to move the browser window. You must fight your way to one of the far top corners in order to do that (and “fight” is the correct word, given that it makes it needlessly difficult to move the browser window).

What happens, of course, is that I’m used to Firefox acting how it used to (and, for that matter, how every other Mac program works), where the entire top most part of the window can be used to grab and move it. So I end up grabbing a tab and moving it. Which of course causes the tab to become a window of its own. This is something I almost never want to do. Congratulations, Firefox, you’ve made it easy for me to do something I almost never want and needlessly difficult to do something I often want.

Back to Safari for now.