[bug #62921] want another monospaced font in the default set

[G. Branden Robinson]

Update of bug #62921 (project groff):

                  Status:                    None => Need Info              

    _______________________________________________________

Follow-up Comment #1:

[comment #0 original submission:]
> By default groff comes with 6 proportional fonts (Avant Garde, Bookman,
Helvetica, New Century Schoolbook, Palatino, Times New Roman), but only 1
monospaced font: Courier. I like Courier but it would be nice to have another
option. Especially for typesetting code listings, a monospaced font with a
slashed or dotted zero, along with a clearer difference between 1 and l, would
come in handy.
> 
> I know there is a mechanism for users to manually add such a font to groff
themselves, but when sharing code it seems like a needless burden to put on
other people.

As I understand it, the reason the font repertoire looks the way it does is
because those are (some of) the base 35 typefaces mandated by the PostScript
Level 2 and PDF standards.

Font repertoire is _not_ standardized across _groff_ output devices.  I admit
that this historically hasn't been very clear in _groff_ documentation, though
the issue was painfully obvious to _troff_ users of the 1980s when common
practice was even less standardized.

> Possible choices would be DejaVu Sans Mono, Liberation Mono, or Adobe Source
Code Pro, though there are many others.

The main practical problem here is that while we could certainly generate
_groff_ font descriptions file for some or all of those, and ship them, users
_still_ won't get those fonts in the output they generate unless they have the
font files installed where the output driver programs, like _grops_ and
_gropdf_, can find them.

This is a matter of populating the "download" files that these programs
respectively read.

But if that problem is addressed, generating the fonts' descriptions in
_troff_/_groff_ format isn't the long pole anymore.

Do you agree?

>  Only the Regular style would be truly needed; Bold and Italic would be a
nice bonus but not really necessary.

The rest of this reply is going to dump a lot of information on you and it's
not strictly necessary to advance discussion of this ticket.

They're more useful than it may at first appear because if a typeface has the
four styles "roman", "bold", "italic", and "bold-italic" all available, then
_groff_ can treat them as a "family".  This is convenient because most macro
packages don't have (and, frankly, don't need) particularized support for a
variety of fonts.  You can pick a family (the default is "Times") and then
switch between styles at will.  This also makes it easier to change your mind
about the families you use.  _groff_'s implementation of the _ms_ package has
pretty solid support for this.

I guess I should note that the bold-italic face is kind of a red-headed
stepchild and support for it is not consistently exposed by historical macro
packages.  This is for the frustratingly dumb reason that the cheap Graphic
Systems C/A/T phototypesetter that the Bell Labs CSRC acquired in ~1973
support roman, bold, and italic, but not bold-italic.  It was nearly 1980
before the Labs got a more featureful typesetter, but dealing productively
with the manufacturers of those devices proved challenging (see the
Kernighan/Condon/Thompson paper).  On top of that, it seems AT&T largely took
_troff_ development away from the CSRC because they wanted to commercialize
it.  But they didn't pay people to do much if any development on _troff_
itself, the formatter--just on, as far as I know, macro packages (mostly _mm_)
and output drivers.  I don't know how else to explain how PostScript came
along, with its four standard styles applied orthogonally to three faces, and
this had zero impact on the formatter's architecture.  After a few years I
guess AT&T decided _troff_ wasn't making much money (just like their computers
weren't), and they sold a source license to SoftQuad in Canada, which then
proceeded, shockingly, to undertake software development.  (That would never
fly today.  It is now understood in the software industry that you acquire a
property like this for only 2 reasons: (1) to kill it, or (2) to milk it for
rents it has already proven itself capable of extracting.  There is always a
pitch by the exponents of the acquisition on the receiving end that (3) some
kind of integration or "synergy" with another product already owned will
increase the revenue flow from factor 2, but this almost never eventuates.[1] 
It doesn't matter, because big bonuses get paid to those principals for having
wangled the acquisition in the first place, and, having pocketed the proceeds
with much glad-handling in the C suite, change jobs before the evidence of
failure is obvious.)

Come to think of it, groff's _ms_ and _me_ have support for bold-italic
already (and have for decades), and it wouldn't be hard to add it to our _mm_
either; the extension furrow there has already been deeply plowed.  (What our
_me_ and _mm_ lack is any concept of font family.)  I'm sure Peter Schaffter's
_mom_ has this area covered, too.

That leaves the man page packages, _man_ and _mdoc_.  I am confident that Ingo
Schwarze would try to melt my face off if I proposed adding bold-italic
styling macros to those.  To be fair, there isn't much need.  In groff 1.23
(forthcoming), the _man_(7) package will render bold-italics anyway in certain
cases, like if you use italics in a section heading (which is set in bold by
default), because I like section headings to have a consistent weight and am
nefarious enough to make it happen.

[1] You really level up as a "strategist" when you have multiple acquisition
efforts going at once, with the "synergies" dependent on all of them coming
off.  The more the better, really, because it lengthens the time before the
people who actually do software engineering can climb out of the all the pits
of undocumented proprietary shitware your company bought and report back to
leadership regarding the huge costs of overcoming interfacing and
impedance-matching problems between the components to get the "leverage" that
was promised.  The obvious thing to do then is kill or unload the asset, the
latter making you selling counterparty in the great fecal ouroborus of M&A.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62921>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/