Re: how many font descriptions should be in font/devpdf?

"G. Branden Robinson" <[email protected]> Sat, 7 Feb 2026 11:51:25 -0600
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260207175125.lxy75nx5deqxvnvu@illithid>
Hi Deri,

I haven't heard back from you on the question summarized in the topic.

I have a further update to offer.

At 2026-02-06T05:10:31-0600, G. Branden Robinson wrote:
> It sounds like the remaining issue lacking clarity or requiring
> decision to finalize groff 1.24.0 (in this respect) is "how many font
> descriptions should install to font/devpdf when gropdf is available at
> a service level other than 'full'"?
> 
> For those just joining us, I'm including the new "URW font support"
> subsection of the gropdf(1) man page as a footnote.  It provides
> necessary background.[1]  (I'm beginning to think this section should
> be retitled "Service levels and URW font support".)
> 
> There are two "inferior" gropdf service levels ("basic" and
> "intermediate"), and two sets of font descriptions it makes sense to
> consider.  Both sets apply to the default (Adobe) foundry.  They are
> the PDF Base 14, and the PostScript level 2 Base 35.  Ignoring the
> font file format, the latter is a superset of the former.
> 
> So we could do this (Automake configuration "A"):
> 
> basic:        14 fonts
> intermediate: 35 fonts
> 
> or this (Automake configuration "B"):
> 
> basic:        35 fonts
> intermediate: 35 fonts

I'll add that "configuration B" is how groff's Autoconf macros are set
up to decide the matter at present.

Also, if anyone would like to explore and help out, I'll observe that
thanks to the new `--without-urw-fonts` configuration flag, it's now
possible to produce all three gropdf service levels _without_ messing
with the package installation payload of one's host environment, if you
already have it set up for "full" support.

basic:
./configure --without-gs --without-urw-fonts

intermediate:
./configure --without-urw-fonts

full:
./configure

In my opinion, `--without-urw-fonts` earns its keep by dint of this fact
alone.  If we make testing/QA easy, more testing/QA can happen.

> A point possibly in favor of configuration "B", and which I could not
> find any better place to document in this message, is that
> Ghostscript's "%rom%" search path feature, wherein the program has an
> unknowable set of built-in fonts available to it, means that documents
> can format correctly even when we have no reason to expect they might
> from inspecting the file system.  I remember a couple of years ago you
> were skeptical that this configuration of Ghostscript was something
> that is still done, but I keep running into it.  The Ghostscript in
> Solaris 11, at least the one installed on the relevant host in the FSF
> France's compiler farm, has this trait.  Does this information
> influence your thoughts?
[...]
> > You have said you wish to show off groff's typographical abilities
> > so allowing a user to produce pdfs like this may well put them off
> > using groff.
> 
> I suspect that you, too, want to show off the abilities of gropdf in
> particular.  :)  That might militate shipping as many different font
> descriptions as possible at all service levels ("configuration B").
> 
> However you also, I perceive, want gropdf to support a wide variety of
> host configurations (in terms of what non-groff resources or packages
> are available).  That means having graceful, documented degradation
> paths when gropdf cannot be employed to its fullest and most
> flattering extent.  A person using the "basic" service level might
> wonder why groff ships with font descriptions it can't fully use, or
> why they should want to use gropdf to produce a PDF that renders a
> blank page, as with xpdf and your example on your system.  If a
> device-independent formatter (troff) has no description for the font a
> document selects, it can't select that font--there are no metrics for
> its glyphs, so it doesn't know how to position them--and ignores the
> font selection attempt.  This scenario militates for restricting the
> set of descriptions available at the basic service level to the 14
> that any reader/device conforming to the PDF standard is expected to
> render satisfactorily (if in a "fallback" mode about which recent
> versions of the standard wags its finger): in other words,
> "configuration A".
> 
> Each of the foregoing approaches has pros and cons.  So the best kind
> of decision, a correct one per our (unspecified) system of
> mathematical logic, is foreclosed to us, and we must make a sweaty,
> grimy engineering decision that subjects us to trade-offs and
> compromises.
[...]
> I don't think there's an obvious superior choice here.  I ask you to
> express your preference between "configuration A" and "configuration
> B".
[...]
> [1] gropdf(1):
> 
>    URW font support
>      The traditional PostScript Type 1 fonts are limited in their
>      glyph repertoire, and the original versions from the Adobe
>      foundry are not free software.  Historically, because their
>      presence was mandated by the PostScript standard, one could
>      expect to find support for them in any conforming device or
>      software PostScript renderer.  PostScript (“Level 1”) initially
>      standardized 14 typefaces: Times, Helvetica, and Courier each in
>      four styles (which groff groups into “families”); a symbol font;
>      and a dingbats font.  PostScript Level 2 increased the number to
>      35, adding the families Avant Garde, Bookman, Helvetica Narrow,
>      New Century Schoolbook, and Palatino; and a text font in one
>      style, Zapf Chancery medium italic.  A document could be small
>      because it did not need to embed font resources unless it had
>      unusual (for the time) glyph or typeface requirements.  This
>      situation carried over into the early years of PostScript’s
>      successor page description language, PDF.  Nowadays, it is common
>      to embed fonts in PDFs, and authorities widely recommend this
>      practice, which increases the reliability of document rendering,
>      and many free software fonts are available with much greater
>      glyph coverage than Adobe’s Type 1 fonts for PostScript.
> 
>      gropdf attempts to work in variety of scenarios, and delivers
>      better results when configured with supporting digital font files
>      (for embedding) and font metrics files describing those fonts to
>      the formatter.
> 
>      •  Full service is available when gropdf can locate all 35 fonts
>         of the PostScript Level 2 standard on the file system along
>         with their corresponding font metrics (AFM) files.  The Adobe‐
>         compatible unnamed foundry supports up to 256 glyphs in each
>         typeface.  Fonts from the URW foundry (“U”) are compatible
>         extensions of the Adobe fonts with extended glyph coverage,
>         including support for Cyrillic script.
> 
>      •  Intermediate service is available when gropdf can locate all
>         35 fonts of the PostScript Level 2 standard but not their
>         corresponding font metrics (AFM) files.  Glyph coverage is
>         reduced to 256 glyphs maximum from each face, and the “U”
>         foundry is unavailable.
> 
>      •  Basic service results when gropdf cannot locate all 35 fonts
>         of the PostScript Level 2 standard.  Only the base 14 fonts of
>         the PDF standard are available, and only in the sense that the
>         formatter can use their metrics.  Use of the -e option to
>         embed fonts in the generated PDF results in an error.

Regards,
Branden
signature.asc (application/pgp-signature, 833 B)