bugGNU roff - Bugs: bug #62921, want another monospaced font in...

 
 

bug #62921: want another monospaced font in the default set

Submitter:  None
Submitted:  Fri 19 Aug 2022 04:02:39 PM UTC
   
 
Category:  Font - others/general Severity:  1 - Wish
Item Group:  Feature change Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 03 Feb 2024 01:38:04 AM UTC, comment #9: 

comment #8:

> Thanks (to whoever that anonymous submitter was ;-) )!


You've probably deduced this, but the reason I sometimes file groff bugs "anonymously" is not to evade credit/blame, but so that I'm not forever tied to a bug I have no stake in.  Savannah seems to support a submitter removing themself from the cc list (in that there's a button for it, though I've never tried it), but the Submitter field is immutable.

> That's not exactly true as I understand it.


I'm glad to be wrong about that.

> (Probably the former; continuing AT&T's abbreviation-happy tradition is
> likely to lead to collisions.)


...and less meaningful to human eyes, of course.

Dave <barx>
Group Member
Sat 03 Feb 2024 12:29:13 AM UTC, comment #8: 

comment #7:

> comment #1:
> > 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;
>
> This has been filed as bug #65241.


Thanks (to whoever that anonymous submitter was ;-) )!

> comment #5:
> > Ideally, distributors like Fedora and Debian would have "package
> > triggers", scripts that hook up the plumbing between TrueType
> > fonts installed on the system, and the grops and gropdf
> > output drivers.  But even after almost 30 years this has never
> > happened.  The reason may be that the specialized knowledge
> > required is fairly scarce,
>
> Other possible reasons:
> * Supporting groff for anything other than displaying man pages on
> terminals has never been a high priority / something that distro
> managers are even aware it can do.


Fair point.  Maybe in the 1.24.0 release announcement we can get a few
more people to wake up and smell the PDF.

> * To be useful, the triggers would have to be bidirectional, running
> whenever a new groff or a new font is installed.  While the target
> code could be largely the same, the triggers themselves would be two
> mostly non-overlapping development efforts.


That's not exactly true as I understand it.  While RPM had a thing
called "triggers" first, Debian's had them as well for...15 years or
something.  And the way they work is that package A can lay a trigger
that any packages B, C, or D will step on it and cause action.  (To this
day I'm not sure exactly how triggers work--they came in right after my
heyday of intense involvement with complex package development.)  Any
time I install or remove a package that supplies a man page, dpkg
dutifully runs the "man-db" package's trigger afterward.

The scenario I think you're describing is not a trigger--it's just what
in Debian is called a "postinst" script, and those have been around
since practically the first Debian pre-release ever, in 1993 or so.
Before even my time...

However, in working on Robin Haberkorn's recent problem with Russian
documents (bug #65323), I've noticed that some cooperation from
font-providing packages is likely necessary anyway, to solve the problem
of picking a groff font name for installed faces.  Should
"LiberationSerif-Regular" be named "LiberationSerifR" or "LSR"?

(Probably the former; continuing AT&T's abbreviation-happy tradition is
likely to lead to collisions.)

Regards,
Branden

G. Branden Robinson <gbranden>
Group administrator
Sat 03 Feb 2024 12:15:51 AM UTC, comment #7: 

comment #1:

> 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;


This has been filed as bug #65241.

comment #5:

> Ideally, distributors like Fedora and Debian would have "package
> triggers", scripts that hook up the plumbing between TrueType
> fonts installed on the system, and the grops and gropdf
> output drivers.  But even after almost 30 years this has never
> happened.  The reason may be that the specialized knowledge
> required is fairly scarce,


Other possible reasons:

  • Supporting groff for anything other than displaying man pages on terminals has never been a high priority / something that distro managers are even aware it can do.
  • To be useful, the triggers would have to be bidirectional, running whenever a new groff or a new font is installed.  While the target code could be largely the same, the triggers themselves would be two mostly non-overlapping development efforts.
Dave <barx>
Group Member
Fri 02 Feb 2024 11:37:42 PM UTC, comment #6: 

This bug was put into Need Info status with comment #1, which asked for feedback that the submitter supplied in comment #4.  I don't readily notice any other info this bug report is waiting on, so I'm resetting the status.  If it's "waiting on" anything, it's a resolution to this question that only groff developers can decide:

comment #5:

> It is a question of whether it is a good idea for the groff
> project, which is not drowning in developers, to expand its
> charter to get into the general purpose font distribution business.

Dave <barx>
Group Member
Sun 21 Aug 2022 04:46:24 AM UTC, comment #5: 

comment #4:

> Hi, original submitter here. Yes, your solution would be fine, but I'm a bit confused. For groff 1.22.4 in Fedora 36 I noticed there are 3 *.pfa_ files in /usr/share/groff/1.22.4/font/devps/: freeeuro.pfa_, symbolsl.pfa_, zapfdr.pfa_
> Those files seem to be included with the source code distribution at http://ftp.gnu.org/gnu/groff/groff-1.22.4.tar.gz .


Yes, that is all correct.  The reasons these exist were not well-documented until very recently (in groff Git).


       Special fonts include S, the PostScript Symbol font; ZD, Zapf
       Dingbats; SS (slanted symbol), which contains oblique forms of
       lowercase Greek letters derived from Symbol; EURO, which offers a
       Euro glyph for use with old devices lacking it; and ZDR, a
       reversed version of ZapfDingbats (with symbols flipped about the
       vertical axis).  Most glyphs in these fonts are unnamed and must
       be accessed using \N.  The last three are not standard PostScript
       fonts, but supplied by groff and therefore included in the
       default download file.


Although even that (from grops(1)) doesn't go into detail.

(1) The "EURO" font is needed because old PostScript printers' built-in fonts didn't have a glyph for the Euro.

(2) The "SS" font is needed because the lowercase Greek letters for which AT&T troff predefines special character escape sequences ( `\(*a` for alpha, and so forth) are canonically italic/oblique, but the PostScript Symbol font that supplies lowercase Greek letters uses upright renderings for them.

(3) "ZDR" is necessary because while AT&T troff predefined special character escape sequences for both "hand pointing left" and "hand pointing right" glyphs (`\(lh` and `\(rh`, respectively), the PostScript symbol font supplied only a "hand pointing right" glyph.

> So couldn't that same bundling be done for an additional monospaced font? The /usr/share/groff/1.22.4/font/devps/freeeuro.afm and /usr/share/groff/1.22.4/font/devps/freeeuro.pfa_ files are the only places where the FreeEuro font exists on my Fedora system, as far as I know.


That makes sense to me.  Nearly all fonts that are Free Software were produced after the establishment of the Euro zone in 1999, and the glyph for that currency simply could not be ignored.  In contrast, by 1999, I think Adobe had largely put PostScript into legacy or maintenance mode, and shifted its efforts into promulgating PDF instead.

> I'm just confused on why the corresponding afm/pfa files for a new monospaced font couldn't also be included, in addition to being mentioned in the /usr/share/groff/1.22.4/font/devps/download file like FreeEuro is. Unless I'm wrong and those were added by the groff package maintainers for Fedora.


They could be included, and the files you note are emplaced by the "install" rule of groff's Makefile.

It is a question of whether it is a good idea for the groff project, which is not drowning in developers, to expand its charter to get into the general purpose font distribution business.  We ship font files for those 3 special cases for PostScript (only of which, "EURO", is needed for PDF output, and that likely pretty seldom).  But those fonts are all of limited repertoire; they don't even contain the Latin alphabet.  They are provided to ensure that glyphs are available for practical troff documents; going without the Euro glyph or slanted lowercase Greek letters would be ruinous for many purposes.

A few gaps still remain thanks to the Adobe Symbol font introducing some glyphs that "old" AT&T troff (before Kernighan's addition of device independence) did not countenance; I raised this issue on the groff discussion list back in March.

Ideally, distributors like Fedora and Debian would have "package triggers", scripts that hook up the plumbing between TrueType fonts installed on the system, and the grops and gropdf output drivers.  But even after almost 30 years this has never happened.  The reason may be that the specialized knowledge required is fairly scarce, in part due to under-documentation of these things by groff, a situation I have been working to address.

The tedium of integrating fonts into groff's PostScript and PDF support is a known defect, filed as bug #58831.

G. Branden Robinson <gbranden>
Group administrator
Sat 20 Aug 2022 10:25:55 PM UTC, comment #4: 


comment #1:

> 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?


Hi, original submitter here. Yes, your solution would be fine, but I'm a bit confused. For groff 1.22.4 in Fedora 36 I noticed there are 3 *.pfa_ files in /usr/share/groff/1.22.4/font/devps/: freeeuro.pfa_, symbolsl.pfa_, zapfdr.pfa_
Those files seem to be included with the source code distribution at http://ftp.gnu.org/gnu/groff/groff-1.22.4.tar.gz . So couldn't that same bundling be done for an additional monospaced font? The /usr/share/groff/1.22.4/font/devps/freeeuro.afm and /usr/share/groff/1.22.4/font/devps/freeeuro.pfa_ files are the only places where the FreeEuro font exists on my Fedora system, as far as I know. I'm just confused on why the corresponding afm/pfa files for a new monospaced font couldn't also be included, in addition to being mentioned in the /usr/share/groff/1.22.4/font/devps/download file like FreeEuro is. Unless I'm wrong and those were added by the groff package maintainers for Fedora.

Thanks.

Anonymous
Sat 20 Aug 2022 08:28:40 PM UTC, comment #3: 

Hi Joerg,

comment #2:

> I concur that this (an nice monospaced font) would be desirable.
>
> begin-off-topic: PTMono is a very nice free monspaced font. extremely readable on screen. use it as my standard font in the terminal. PTSerif and PTsans are also very decent (and I use them with groff) end-off-topic


I use FreeMono as my terminal font and have been pleased with it for several years.

> currently the barrier to using any font outside the canonical base set is rather high for the average user I'd say. and the hurdle is not editing 'download' but generating the font description files. so if the latter where provided for a selection of good, free fonts users might appreciate that.


Granted.  Do you think the instructions as they currently exist in the gropdf(1) and grops(1) man pages in Git HEAD are an improvement over past efforts?  Do they make the impulse for duplicative shipment of fonts less acute?

https://git.savannah.gnu.org/cgit/groff.git/tree/src/devices/gropdf/gropdf.1.man

https://git.savannah.gnu.org/cgit/groff.git/tree/src/devices/grops/grops.1.man

G. Branden Robinson <gbranden>
Group administrator
Sat 20 Aug 2022 08:03:57 PM UTC, comment #2: 

I concur that this (an nice monospaced font) would be desirable.

begin-off-topic: PTMono is a very nice free monspaced font. extremely readable on screen. use it as my standard font in the terminal. PTSerif and PTsans are also very decent (and I use them with groff) end-off-topic

regarding

> 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.


well, while ugly and wasting disk space it would not be out of the question to include the font file (of the single, chosen monospaced font) as well... but a very clear description along the line "if you want to use font X, download it (or locate it's current location on your system) and put the following line in grops/download etc." would probably be sufficient.

currently the barrier to using any font outside the canonical base set is rather high for the average user I'd say. and the hurdle is not editing 'download' but generating the font description files. so if the latter where provided for a selection of good, free fonts users might appreciate that.

just my 2c

joerg

Anonymous
Sat 20 Aug 2022 01:54:38 PM UTC, comment #1: 

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.

G. Branden Robinson <gbranden>
Group administrator
Fri 19 Aug 2022 04:02:39 PM UTC, 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.

Possible choices would be DejaVu Sans Mono, Liberation Mono, or Adobe Source Code Pro, though there are many others. Only the Regular style would be truly needed; Bold and Italic would be a nice bonus but not really necessary.

Thanks.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by barx
  • -email is unavailable- added by gbranden (Updated the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-02-02 barx StatusNeed Info None
    2022-08-21 barx Carbon-Copy- Added barx
    2022-08-20 gbranden StatusNone Need Info
    2022-08-20 gbranden Severity3 - Normal 1 - Wish
        Summary[Request] Add another monospaced font to the default fonts want another monospaced font in the default set

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code