Re: the Courier font family and nroff history

[G. Branden Robinson]

At 2024-03-22T21:37:51-0700, Russ Allbery wrote:
> "G. Branden Robinson" <g.branden.robinson@gmail.com> writes:
> 
> > Okay...by this time groff had for about 10 years been producing
> > device-independent _terminal_ output from troff(1).  On the other,
> > that is its own peculiar little language.  Maybe the author just
> > didn't want to deal with *roff, or didn't want to count on GNU troff
> > being available.
> 
> Oh, yeah, to be clear, the context of this was viewing Perl
> documentation without nroff, so it's fairly off-topic for this list
> other than the specific example of someone who found overstrike output
> useful in a related context.

Understood.  It still has to do with text formatting, so I wouldn't say
it's _far_ off-topic.  Alternatives to *roff come up with some
regularity, often when people wonder about greener grass...

> There has been a lot of back and forth in the Perl world about whether
> to use a formatting pipeline that involves nroff by default.  perldoc
> defaulted to Pod::Man plus nroff for a long time, but it's defaulted
> to Pod::Text for a while.  I think the main reason was better UTF-8
> support (which is partly my fault for being very conservative about
> not wanting to produce UTF-8 roff for a long time until I could do
> some comprehensive testing that took me embarrassingly long to do, and
> people understandably got sick of their names showing up as sequences
> of X characters), but portability to Windows and some other platforms
> was I think part of the reasoning.
> 
> I have to be honest that I've not kept track of that debate because I
> didn't want to own the problem and I wasn't seeing the user feedback.
> It's all the same to me; both Pod::Man and Pod::Text are supported and
> will continue to be.  But now Pod::Man supports UTF-8 by default
> because I managed to convince myself that this worked on every
> significant platform that wasn't a museum piece.

It sounds like the way is clear to change perldoc's default back to
Pod::Man plus nroff.  ;-)

> I think my brain works a little oddly in that I sort of randomly use
> perldoc or man to read Perl documentation so sometimes it's formatted
> with nroff and sometimes it's not and I don't really notice the
> difference.  I also write all my code in Emacs but use vi to write all
> my commit messages and randomly switch between them for editing text
> files.  I am probably not the average user.  :)

I fancy myself bi-endian on the vi/emacs spectrum as well.  To the point
that I've been maintaining my own fork of "mg" (unofficially "Micro GNU
Emacs") for the fun of it.  Occasionally neomutt throws me into emacs
instead of vi for reasons I don't understand, but I'm not bothered.  I
keep on truckin'.  Those years of stubbornly sticking with Bash's
default readline bindings finally paid off.

(I've been slowly accumulating evidence that, for basic editing
operations, vi _really is_ more keystroke-efficient than Emacs, not for
any reason to do with modifier keys but because vi commands are
composable in two orthogonal vectors (motion and count) instead of one
(the "universal argument", which sometimes has a limited non-numeric
meaning derived from algebraic sign).  Leaving scripting language aside,
I'm sure I'll be able to make the definitive case for vi over emacs once
everyone who would care is safely dead.

> > I think that's a little unfair.  We can trace the history of these
> > escape sequences back to ANSI X3.64, which was later succeeded by
> > ECMA-48 and (equivalently, as far as I know) ISO 6429 and JIS X
> > 0211.  These standards have been around approximately as long as
> > Unix has been something you were likely to run into at your
> > university or workplace.
> 
> I'm sorry, I really hope that didn't sound critical of anyone here.
> It was meant to be wryly funny, but I probably shouldn't be attempting
> that on a mailing list I'm fairly new to.

I think you're fine.  You were sassing tongue-in-cheek, and I pouted
tongue-in-cheek.  3:)

Be yourself and carry on!  That's what they say in the U.K., right?  ;-)

> I know that you of all people wouldn't blindly do anything.  :)

Aww, shucks.

> I just see a ton of code out there these days that assumes everything
> is ECMA-48 compatible, which to be fair really is a reasonable
> assumption in most places these days.

Yes.  I just wish people would _document_ their assumptions.  Doing so
can save much frustration later, in addition to clarifying one's own
thinking.

> We still have all of the infrastructure to support terminals that
> behave very differently, like VT-52s, and a lot of code still calls
> into it, but I think the details of terminal portability are a bit of
> a lost art and I bet a lot of things would not actually work on a real
> VT-52.

Possibly.  But we _can_ check, even without venturing into the dark
alleyways of vintage computer auctions.

https://github.com/larsbrinkhoff/terminal-simulator

Behold, a DEC VT52 and VT100 emulator _running the original ROMs_.

> I remember the days when you could enter your username in ALL CAPS at
> the Linux console login prompt and it would automatically switch to
> the mode that supported compatibility with terminals that didn't have
> lowercase letters.  But there is no compelling reason to support this
> type of portability any more unless one is running a museum.

I agree.  I think we should draw a line before ISO 646-1991:IRV.
Anything using a character set that doesn't match that is a
retrocomputing device.

> > But that's not the fault of ECMA-48, which has even had the virtue
> > of being freely available on the Web for many years.  We cannot say
> > as much for many ANSI or ISO/IEC standards.
> 
> Yes, indeed, although as I've learned from maintaining
> Term::ANSIColor, there's all sorts of new-fangled stuff now, such as
> "true color" support which Wikipedia thinks comes from ITU T.416.  I
> never bothered to track it down.

Thomas Dickey has a huge section in the ncurses FAQ about this.

https://invisible-island.net/ncurses/ncurses.faq.html

Scroll down to:
        Why not make “xterm” equated to "xterm-256color"?

> > I'm no MS-DOS/Windows expert, but my understanding is that you
> > couldn't count on support for ECMA-48 at the DOS prompt (or
> > equivalently in CMD.EXE on NT-descended Windows) because the console
> > driver didn't recognize them.
> 
> Correct, although I believe this may have changed with newer versions of
> Windows.

That's what I hear.

> > I have gathered, by reading bug fora and similar while trawling the
> > Internet for accounts of trouble with groff that people are too lazy
> > to actually report to us, that Windows 10 or 11 has a console
> > driver/terminal emulator that does "better" with ECMA-48 support.  I
> > haven't heard even a rumor of anything usefully quantitative, like a
> > table of its support for standardized escape sequences in comparison
> > with, say, xterm, or even the Linux kernel's somewhat wobbly virtual
> > console device.  But, supposedly, things are "better".

(than they were on earlier Windows, not than terminal emulators
available on *BSDs and GNU/Linux)

> You may find the NOTES section of the Term::ANSIColor man page
> interesting, although it's probably out of date since I rely on other
> people to send me updates.  Term::ANSIColor also comes with test files
> and a test file generator that one can cat on a display to see what
> works.

My copy may be even more out of date than yours, but let's see if we can
get at least this claim fixed.

       Support for code 3 (italic) is rare and therefore not mentioned
       in that table.  It is not believed to be fully supported by any
       of the terminals listed, although it’s displayed as green in the
       Linux console, but it is reportedly supported by urxvt.

grotty(1):
       -i     Render oblique‐styled fonts (I and BI) with the SGR
              attribute for italic text rather than underlined text.
              Many terminals don’t support this attribute; however,
              xterm(1), since patch #314 (2014‐12‐28), does.  Ignored if
              -c is also specified.

Regards,
Branden

signature.asc
Description: PGP signature