Friday, September 16, 2022

Stupid O'Clock is the Font of Stupidity. Who'd Thunk?

Man, I slept at 0230hrs this morning and woke up at 0825hrs.

The reason is quite banal---I was creating my own 6×11 bitmap font for use in my terminal emulator when I realised that the one I was using had a bad render of the `>' glyph. What ate much of the time was trying to figure out why the blazes my terminal emulator (mintty for the curious---it's from Cygwin) was still rendering that font as 6×13 instead.

Spoiler alert: semi-hidden option of AutoLeading was screwing up the vertical pixel count. 🤦‍♂️ But more on that later.

I need to begin the story where it will make more sense. I had thought long and hard, and have decided to move away from my default maximum character width of 76 characters for source files to that of 80 characters instead, especially for Python.

The reasons were as follows:
  1. That missing 4 characters was enough to cause an unnecessary break for a line that would fit exactly within 80 characters;
  2. By Zipf's Law, most of the code lines aren't ever going to be that long anyway, which means that it was usually safe to keep it at 80 characters as opposed to 76;
  3. My old comment on needing the extra columns to allow the additional decoration for TUI editors hasn't been applicable for more than two decades now.
By ``additional decoration'', I mean the following (text editor is Multi-Edit Lite running in DOSBox-X, originally shareware from Multi-Edit Software, but the company seems dead as at time of writing):
Notice how line-drawing characters are used to define the borders of the text window, together with the old school representation of scroll bars and the like? Those take up character cells, and with a starting point of 80, the left and right window edges immediately take it down to 78 characters being the maximum amount of visible text without scrolling. The 76 was derived from the observation that if one reaches the end of the line through any regular cursor movement, it will often end up one character beyond the last character, which can trigger a horizontal scroll.

In short, it is annoying to use the full complement of 80 characters, and it was better to use something like 76.

But I'm using Vim now---I've been using Vim for a long time now. That shouldn't matter any more.

The only thing that can matter is the idea of vertical split screens, either from looking at differences between two files, or three in the event of a three-way merge.

For those, I can bring the terminal screen to use the full extent of the 1920 horizontal pixels. Easy. And without going that far, Vim has no text decoration that eats up cells, which gives us the full 80 characters (I refuse to use line numbers on the side of the simple reason that the ruler in my status already shows the line number of the cursor). Zipf's Law suggests that very long lines are rare, and thus as long as I can find a font for my terminal emulator to handle about 161 characters for half the screen (math says that each character needs to have about 1920/2/161=5.962 pixels), I'm gold.

Vaguely, this means a font that has about 6 pixels of width. My go-to of Proggyfonts (or more specifically, Opti Small is already 6 pixels wide, but thanks to some fuckery from mintty, it looked off to me. That, and I wanted something that yielded more than 161 characters at the half-screen mark to have more room for other niceties.

I then started looking into using CG Mono instead. It was fine, but still looked a bit off because the `>' glyph was bogus---it lacked the crispness that came from bitmap fonts, and looked like some other font was chosen to render it instead.

Why? I don't know. Looking at it through FontForge showed nothing out of the ordinary. The time was about 2300hrs or so. And that's when I went to Simon Tatham's Fonts Page to grab his scripts and samples to build my own 6×11 font to fix this issue.

I completed the font, but when I tested it, it was... very off. The vertical extent as compared through the gridded version of MSPaint showed that it was consistently 2 pixels larger than what was stated. I read through Simon's code to see if he was doing anything strange, and found nothing.

It was then that I decided to go read the fine manual of mintty, to see if there was something I was missing.

Oh yeah, I was missing something all right---the completely inaccessible via configuration screen option of AutoLeading. It defaulted to 2 for some damn reason, and there was no way to change it in the pop-up configuration menu. Mangling the associated .minttyrc file allowed me to set it to 0, and everything worked well once more.

At that point, I switched away from CG Mono and back to my usual font, and it looks peachy.

🤦‍♂️

So what's the moral of the story then?

Don't do weird shit at stupid o'clock---one really ends up doing stupid things at stupid o'clock. I mean, redesigning an entire bitmap font when all that was needed was a tiny configuration change in some semi-obscure file? What an ``excellent'' use of 3 hours.

Till the next update.

No comments: