Groff Mystery Solved

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.

There Is No Shortage of High-Tech Workers

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.

The Trick to Using Fontforge

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.

Font Frustrations

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.

How to Buy Fonts, or, Beware of non-Pro Fonts

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.

Fonts on the Mac

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.

World Pixels: The Best Map Tiles Technique

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 2Z tiles in each direction.
  • Each tile has 256 (28) 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.

A New Appreciation for How Much Javascript Sucks

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.

Back to Safari… for Now

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.

So Much for Eclipse

I’ve been using the Eclipse IDE off and on for several years now, mainly because it’s something of a de-facto standard in the Java world, and I want to be something in sync with that world. Well, forget it. I’ve come to the conclusion that the annoyances outweigh the advantages:

  1. The editor is nowhere near as powerful as a stand-alone editor. That should not be a surprise; it’s competing for the attention of the Eclipse dev team with so many other priorities. By contrast, the dev teams working on text editor projects are totally focused on making those editors better.
  2. The editor is sluggish. It doesn’t respond as promptly to my keystrokes as any dedicated text editor I’ve used. This frequently trips me up.
  3. It’s almost as if it has an artificial intelligence engine working away to decide whether or not I’d like auto-completion to be offered for an identifier… and then does precisely the opposite of what I want. The feature pops up unbidden and gets in the way when I’m rapidly typing, yet never appears when I’m paused, trying to remember the precise name of something. Typing Control-Space remedies the latter situation, but still.
  4. Also, the auto-complete for things like parenthesis and quotes is thoroughly evil. It’s always introducing syntax errors into my code, because it comes up slightly too late; by the time it’s gratuitously inserting something, I’ve already gotten a keystroke or two in edgewise.
  5. The default is to indent with hard tabs, and you have to change many settings to defeat this misfeature.
  6. There is no simple, easy way (at least none I’ve found, and I’ve tried) to stop it from making files with lines that have trailing white space.
  7. When upgrading to a new version of Eclipse, nothing is done to import settings settings from any previous version you were using.
  8. When upgrading to a new version, the new version will create a new directory for its workspaces, instead of seeing if there is any existing such area in a default location used by a previous version. The default workspace path changes from version to version. There is no overriding pattern to the defaults.
  9. There’s no way to do something as simple and basic as renaming a project in Eclipse Oxygen. If there is; it’s very well-hidden; the action is not listed in the same menu that creating, deleting, and copying projects are listed.

The straw that broke the camel’s back for me was the mess with the workspace directories. I don’t need three separate, inconsistently-named, locations. Yet that is now what I have. And when I attempted to convert and old workspace into a new one, the conversion failed and left some projects inaccessible. I’m sure there’s a solution that would enable me to fix the problem, but it’s simply not worth continually expending effort at making an overly-complex tool behave itself.

So I’m in the process of reverting to a text editor and using that old reliable standby Ant to do the building of my Java projects. A pity, as some of what Eclipse offers (detection of errors as one types, being able to request auto-completion) really is helpful.