Not sure where this goes, and probably nobody cares anyway, but after all these years I surprised to find that the Andale Mono font used with ZTERM shrinks the width of underlined columns. The Lucinda Console font does not have this problem.

Hmmm...

I'm not quite sure where you're seeing this, because I'm not. Here's a sample showing normal, underlined, and reverse text in both fonts, all lining up:



And it looks roughly the same in A-Shell/Windows/ATE:



Note that the characters in the A-Shell/Windows/ATE version appear to be more "squat" even though the character grid size seems to be about the same. This is because I had my leading value set to 7, effectively stealing 7 pixels of height from each character to use for the spacing between rows. (ZTERM uses the equivalent of 0.)

And they seem to match when used in GDI printing:



The above print (APEX) sample does show that the default Andale Mono width (for a given height) is considerably less (i.e. it's narrower) than Lucida Console, but that's not unusual, and wouldn't affect character mode screen layouts, in which it would seem normal to expect each character to be positioned individually in the grid.

Perhaps you've stumbled onto some scenario where ZTERM outputs a string of text in one operation, expecting the natural widths to match the grid. Does the problem remain if you minimize and redisplay the window? Is it sensitive to the window size?

(This is somewhat off topic, but the only way to get predictable font widths in GDI printing is to use the width parameter in the //SETFONT directive .)

This is truly screwy. (A customer brought this to my attention (in 132 column mode, although 132-column mode doesn't seem to be a factor.) This morning I can't duplicate the problem on my system, so I logged in to my customer's system with a different instance of ZTERM, and the problem still exists.

Then I changed font to Lucinda Console (from Andale Mono), problem goes away. Then I switch back to Andale Mono, problem stays away. It has to be something about the way ZTERM handles fonts.

Then I switch to my laptop which as a ZTERM profile all configured for my in-house server, and I get the problem. It's like every ZTERM profile on either of my WINDOWs system has the problem, but once I change the font the problem goes away.

Baffling. I'll "play" with this some more when I have some time.

Well, it doesn't completely surprise me, as I've spent hours over the years struggling with such anomalies in A-Shell myself (although mostly in the context of printing). My guess is that ZTERM is probably relying more (than A-Shell/Win/ATE does) on the font's natural "tracking" to be as advertised. But how it would be affected by prior font changes is a complete mystery.