On Friday, 6 February 2026 11:10:31 GMT G. Branden Robinson wrote:
> Hi Deri,
>
> [This message took a while to compose. Edits are marked.]
Hi Branden,
[This took a while to answer, I took two days rest watching Rugby (6 nations)]
> 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
Since you have now added the 3 levels of font support to configure:-
Required
Basic (14 fonts) no gs & no urw
Intermediate (35 fonts) gs or urw
Full (35 + 35 U- fonts) [1] urw
Logically, when this is extended to the devpdf make file (devpdf.am), there
are 3 configurations (lists of fonts) to install. Start with 14 (all levels
support them), add the remaining 21 postscript fonts if either ghostscript or
the urw fonts are present, add further 35 U- fonts if URW font available.
> 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 don't think this is true. If the 35 fonts were in the "%rom%" search path
the size of the gs binary would be close to 5mb, which is a large startup
overhead when possibly only one of the fonts is used in the postscript
documents to be distilled into a pdf. It is more likely it is the .afm files
which are compressed and stored in the %rom% resource. You will probably find
the type 1 fonts are actually in one of the "Search paths" provided by the
command "gs -h".
Is it possible for me to access the server you are seeing this %rom% resource
to investigate?
> 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?
The presence of %rom% in Solaris 11 is likely for afm files only (see above),
it is likely the actual font files are available in some other Ghostscript
Resource directory which is accessible to gropdf.
> Given that context, I'll now try to tackle your messages.
>
> At 2026-02-04T16:12:24+0000, Deri wrote:
> > I believe readers look for the urw fonts on your system and may supply
> > them if they are not embedded, they definitely do not come with their
> > own private copies. So in the case where gropdf is in basic mode and
> > has not found the urw fonts, it follows that any pdf reader is also
> > unlikely to find the font requested. The attached pdf is produced with
> > current master with the unwanted extra fonts that do not have real
> > fonts to embed. Also a png showing how it looks on my system in
> > okular, (xpdf refused to show anything at all).
>
> Right. Looks like Okular fell back to Helvetica italic.
>
> > Looking at the pdf on your system, it may look different, if you have
> > urw fonts installed, but we are talking about the user who is using a
> > basic mode groff without any urw fonts installed.
>
> For me, xpdf found Zapf Chancery medium italic...or something that looks
> a lot more like it than Helvetica italic, at any rate.
As expected, you have the URW fonts installed on your system when you ran xpdf
so it found the correct font. If the URW fonts are removed from your system
you would see this:-
[derij@pip build (master)]$ xpdf zcmi.pdf
Config Error: No display font for 'Courier'
Config Error: No display font for 'Courier-Bold'
Config Error: No display font for 'Courier-BoldOblique'
Config Error: No display font for 'Courier-Oblique'
Config Error: No display font for 'Helvetica'
Config Error: No display font for 'Helvetica-Bold'
Config Error: No display font for 'Helvetica-BoldOblique'
Config Error: No display font for 'Helvetica-Oblique'
Config Error: No display font for 'Symbol'
Config Error: No display font for 'Times-Bold'
Config Error: No display font for 'Times-BoldItalic'
Config Error: No display font for 'Times-Italic'
Config Error: No display font for 'Times-Roman'
Config Error: No display font for 'ZapfDingbats'
And a blank display.
> > 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").
Not if it means that using any fonts except the base-14 will produce a rubbish
experience! On groff 1.23.0 in basic mode with just 14 fonts available, if the
user tried to use one of the other postscript fonts (such as ZCMI) they were
told the font is not available, and possibly google and find out how to
corrrect it. Now if they try to use ZCMI without any URW fonts available to
their system the result will make them think "Well groff is garbage!!".
> 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".
This is my feeling too. Basic - install 14, Intermediate - install 35, Full -
install 35 + U-35.
I've attached a patch which achieves the above (its the same as I sent you
privately but rebased to current git). The advantage with this is that we are
not breaking the pdf standard, and go back to the 1.23.0 position of always
producing pdfs which conform to the standard.
> 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.
>
> > This behaviour has only been changed in the last few weeks, it was not
> > done in rc1.
>
> That might due to fallout from my reorganization of the Automake
> variables used, and also from (not completely consciously, perhaps)
> flipping my perspective between each of the two above. Or it might be
> because you managed to get your build tree into a bad state--more on
> that below.
> > So this change (munging the build devpdf directory during install)
>
> I don't think that's what's going on. Consider the scenario of running
> "make" followed separately by "make install". I don't perceive the
> build directory being altered in any way by "make install". If it is,
> that's a bug utterly independent of the topic at issue.
>
> Can you reproduce this misbehavior? If so, please advise of a host
> configuration that does so. Sharing the "configuration summary" as
> reported by the master branch in Git (that is, post-rc2) _should_ be
> enough for me to suss it out.
>
> [EDIT: I see you did that in the subsequent message quoted below.]
>
> > is very recent, typographically it is hit and miss for the user, and
> > the pdf produced does not conform to pdf standards. I hope these are
> > reasons enough to restore the behaviour seen in 1.23.0 for basic
> > users.
>
> I don't think there's an obvious superior choice here. I ask you to
> express your preference between "configuration A" and "configuration B".
>
> At 2026-02-04T16:12:49+0000, Deri wrote:
> > > > These extra (non base-14) fonts have appeared in the build
> > > > directory and been installed. Is this normal make install
> > > > behaviour.
> > >
> > > Not if you "make distclean" and re-"configure" after uninstalling
> > > whatever packages supply the URW Base 35 fonts on your system. :)
> >
> > Ok, thanks I'll try exactly that, let me know if I am doing something
> > wrong.
> >
> > URW fonts gone. Check
> > Ghostscript gone. Check
> > git checkout master. Check
> >
> > Now go. (cwd 'build' directory)
> >
> > make uninstall
> > make distclean
> >
> > # A bit of belt'n'braces
> > cd ..
> > rm -rf build
> > mkdir build
> > cd build
> > rm -rf /usr/local/share/groff/1.24.0
>
> "make uninstall" _should_ work just as well here (better, even, since it
> will also clean out groff's executables and man pages).
>
> If it doesn't, I urgently want to know about it!
Belt and Braces, just so I am sure my system is not in a "bad state".
> > ###
> >
> > ../configure --without-urw-fonts
> > # see missing ghostscript message and no urw fonts
> > make -j
> >
> > make check
> >
> > ==========================================================================
> > == # TOTAL: 310
> > # PASS: 299
> > # SKIP: 6
> > # XFAIL: 5
> > # FAIL: 0
> > # XPASS: 0
> > # ERROR: 0
> > ==========================================================================
> > ==
> Everything seems reasonable so far.
>
> > $ ls font/devpdf
> > CB CI DESC enc/ Foundry HBI HR S symbolsl.afm TB TI
> > util/ CBI CR download EURO HB HI map/ SS symbolsl.pfb TBI
> > TR ZD
> >
> > sudo make install
> >
> > $ ls font/devpdf
> > AB BMB CB DESC Foundry HNB HR NI PI symbolsl.afm TI
> > ZD ABI BMBI CBI download HB HNBI map/ NR PR symbolsl.pfb
> > TR AI BMI CI enc/ HBI HNI NB PB S TB
> > util/ AR BMR CR EURO HI HNR NBI PBI SS TBI
> > ZCMI
> >
> > Those extra files added to font/devpdf again by 'make install' (i.e.
> > after 'make check' so we are installing files which were not present
> > when the check was done), what have I done wrong - if you are saying
> > it should not happen.
>
> Yes, that should not happen. That's weird.
I agree, the attached patch also corrects this behaviour, please test it out.
Cheers
Deri
> I'll go see if I can reproduce this misbehavior by attempting a groff
> build targeting gropdf's basic service level. However, I reiterate that
> this issue is irrelevant to the selection of "configuration A" versus
> "configuration B". That decision is (should be) made by the build
> system long before the "install" target does its work.
>
> A difficulty I encountered recently is that weird/stupid things,
> including multiple spurious rebuilds of groff documentation, can occur
> if a directory is used for an out-of-tree build after having been once
> used for an in-tree build (and not savagely cleaned afterward). I think
> this has to do with the way out-of-tree build support ("VPATH") got
> bolted onto the Make program well after its initial implementation.
> (This precise semantics are, therefore, one of the areas where GNU Make
> and BSD Make diverge.) The distinctions that Automake recognizes
> between clean targets--they come in regular/unnamed, "distclean", and
> "maintainer-clean" varieties--while necessary as far as I can see,
> entangle with "the VPATH problem" in unpleasant ways.
>
> So I must urge you (and anyone attempting to develop groff!) that if you
> switch between in-tree and out-of-tree builds, to apply stern discipline
> to keeping their respective source trees separate.
>
> If you ever get frustrated with an ill-behaved build that seems to shift
> underneath you like a serpent in the sand, I strongly recommend making a
> fresh new directory and doing a build from a distribution archive, or
> making a new Git working copy, from there. Evaluate _that_ for defects
> in the build process. For the latter, I can't recommend highly enough
> using one local checkout as the source for another. It's way faster to
> update because you don't have to hit the network (except for an initial
> fetch of gnulib, which is time-consuming and which aggrieves me because
> the up-to-date submodule checkout IS SITTING RIGHT THERE, but for which
> I hold no hope of resolution, ever[2]). This approach does of course
> cost more in disk space.
>
> > > We rely on a stamp file, font/devpdf/stamp. Unfortunately, the
> > > stamp file is not made out of date by NOT removing files that it _no
> > > longer_ depends on. So a possibility exists for running the tests
> > > against a configuration that no longer reflects the state of the
> > > system.
> >
> > Note the entire 'build' directory was removed prior to configure.
>
> That sounds like a safe and advisable procedure (my "make-*-groff*"
> scripts do the same, except when my `IN_TREE` shell variable is set
> appropriately). However as noted above, a source directory can become
> "tainted" by an in-tree build in ways that are difficult to detect. You
> may need to run "git status --ignored" and watch out for entries marked
> '!!'. Some of the commits I pushed yesterday were to remedy problems in
> precisely this area.
>
> Regards,
> Branden
>
> [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.
>
> [2] However, there is this ticket, which I still need to explore.
>
> https://savannah.gnu.org/bugs/index.php?66804
diff --git a/configure.ac b/configure.ac
index f52cd906e..1cfd4d533 100644
--- a/configure.ac
+++ b/configure.ac
@@ -192,6 +192,9 @@ AM_CONDITIONAL([HAVE_URW_FONTS], [test "$groff_have_urw_fonts" = yes ])
AM_CONDITIONAL([HAVE_MAKEINFO], [test "$groff_have_makeinfo" = yes ])
AM_CONDITIONAL([HAVE_TEXI2DVI], [test "$groff_have_texi2dvi" = yes ])
AM_CONDITIONAL([USE_TEX], [test "$groff_use_tex" = yes ])
+AM_CONDITIONAL([GROPDF_INTER], [test "$gropdf_service_level" = intermediate \
+ || test "$gropdf_service_level" = full])
+AM_CONDITIONAL([GROPDF_FULL], [test "$gropdf_service_level" = full])
AC_CONFIG_FILES([Makefile])
AC_CONFIG_FILES([test-groff], [chmod +x test-groff])
diff --git a/font/devpdf/devpdf.am b/font/devpdf/devpdf.am
index f59ca22c5..80fdaab0e 100644
--- a/font/devpdf/devpdf.am
+++ b/font/devpdf/devpdf.am
@@ -20,19 +20,11 @@
# along with this program. If not, see <http://www.gnu.org/licenses/>.
devpdf_srcdir = $(top_srcdir)/font/devpdf
-devpdf_builddir = font/devpdf
-devpdffont_descriptions_from_devps = \
+devpdf_builddir = $(top_builddir)/font/devpdf
+
+devpdffont_descriptions = \
font/devpdf/S \
font/devpdf/ZD \
- font/devpdf/ZCMI \
- font/devpdf/AB \
- font/devpdf/ABI \
- font/devpdf/AI \
- font/devpdf/AR \
- font/devpdf/BMB \
- font/devpdf/BMBI \
- font/devpdf/BMI \
- font/devpdf/BMR \
font/devpdf/CB \
font/devpdf/CBI \
font/devpdf/CI \
@@ -41,6 +33,22 @@ devpdffont_descriptions_from_devps = \
font/devpdf/HBI \
font/devpdf/HI \
font/devpdf/HR \
+ font/devpdf/TB \
+ font/devpdf/TBI \
+ font/devpdf/TI \
+ font/devpdf/TR \
+ font/devpdf/EURO
+
+if GROPDF_INTER
+devpdffont_descriptions += \
+ font/devpdf/AB \
+ font/devpdf/ABI \
+ font/devpdf/AI \
+ font/devpdf/AR \
+ font/devpdf/BMB \
+ font/devpdf/BMBI \
+ font/devpdf/BMI \
+ font/devpdf/BMR \
font/devpdf/HNB \
font/devpdf/HNBI \
font/devpdf/HNI \
@@ -52,14 +60,10 @@ devpdffont_descriptions_from_devps = \
font/devpdf/PB \
font/devpdf/PBI \
font/devpdf/PI \
- font/devpdf/PR \
- font/devpdf/TB \
- font/devpdf/TBI \
- font/devpdf/TI \
- font/devpdf/TR \
- font/devpdf/EURO
+ font/devpdf/PR
+endif
-if HAVE_URW_FONTS
+if GROPDF_FULL
devpdffont_descriptions_for_urw = \
font/devpdf/U-S \
font/devpdf/U-ZD \
@@ -98,7 +102,7 @@ devpdffont_descriptions_for_urw = \
font/devpdf/U-TR
endif
-devpdffontdescriptions = $(devpdffont_descriptions_from_devps) \
+devpdffontdescriptions = $(devpdffont_descriptions) \
$(devpdffont_descriptions_for_urw) \
font/devpdf/DESC \
font/devpdf/SS
@@ -136,7 +140,7 @@ EXTRA_DIST += \
font/devpdf/generate/symbolsl.sfd \
font/devpdf/util/BuildFoundries.pl
-$(devpdffont_descriptions_from_devps):
+$(devpdffont_descriptions):
$(AM_V_at)$(MKDIR_P) $(top_builddir)/font/devpdf
$(AM_V_at)for f in $@; do \
cp -fp $(top_srcdir)/font/devps/`basename $$f` \
@@ -222,7 +226,7 @@ buildfoundries_extra_arg=
endif
font/devpdf/download: $(devpdffontencdata) $(devpdffontmapdata) \
- $(devpdffont_descriptions_from_devps) \
+ $(devpdffont_descriptions) \
font/devpdf/DESC font/devpdf/Foundry font/devpdf/util/BuildFoundries
$(AM_V_GEN)$(MKDIR_P) $(top_builddir)/font/devpdf \
&& PATH="$(abs_top_builddir)$(GROFF_PATH_SEPARATOR)$(abs_top_builddir)/build-aux$(GROFF_PATH_SEPARATOR)$(PATH)" \
@@ -230,7 +234,7 @@ font/devpdf/download: $(devpdffontencdata) $(devpdffontmapdata) \
$(buildfoundries_extra_arg) \
--download $(abs_top_srcdir)/font/devpdf/download.in \
$(abs_top_builddir)/font/devpdf \
- '$(abs_top_srcdir)/font/devpdf:$(abs_top_builddir)/font/devpdf' \
+ '$(abs_top_srcdir)/font/devps:$(abs_top_builddir)/font/devps' \
>>[email protected] \
&& mv [email protected] $@
diff --git a/m4/groff.m4 b/m4/groff.m4
index 1fb124eef..58c04b44d 100644
--- a/m4/groff.m4
+++ b/m4/groff.m4
@@ -271,16 +271,16 @@ AC_DEFUN([GROFF_GROPDF_DEPENDENCIES_CHECK], [
AC_REQUIRE([GROFF_GHOSTSCRIPT_PATH])
AC_REQUIRE([GROFF_URW_FONTS_CHECK])
- gropdf_service_level=full
+ gropdf_service_level=basic
- if test "$groff_have_urw_fonts" != yes
+ if test "$GHOSTSCRIPT" != missing
then
gropdf_service_level=intermediate
fi
- if test "$GHOSTSCRIPT" = missing
+ if test "$groff_have_urw_fonts" = yes
then
- gropdf_service_level=basic
+ gropdf_service_level=full
fi
])
