On Monday, 2 February 2026 01:22:04 GMT G. Branden Robinson wrote: > At 2026-02-01T23:30:07+0000, Deri wrote: > > > Yes, I observe the same contents, plus descriptions of the > > > PostScript level 2 fonts. I see them in my build's font/devpdf > > > directory, too. I don't understand why you don't. BuildFoundries > > > is supposed to copy them over from font/devps, and does--for me. > > > > > > $ (cd ~/groff-HEAD/share/groff/1.24.0/font/devpdf && echo * | fold -sw > > > 72) > > > AB ABI AI AR BMB BMBI BMI BMR CB CBI CI CR CSH CSS CTH CTS DESC EURO > > > Foundry HB HBI HI HNB HNBI HNI HNR HR JPG JPM KOG KOM NB NBI NI NR > > > PB PBI PI PR S SS TB TBI TI TR ZCMI ZD download enc map symbolsl.afm > > > symbolsl.pfb > > > > Problem. As this is "basic" only the base-14 (as above) should be > > observed. > > Then we'd need to change font/devpdf/devpdf.am and/or BuildFoundries. > But see below.
Before you change anything please repeat your "basic", you did not actually follow the instructions (particularly make distclean). > > Since there are no U foundry files, > > These font descriptions aren't for "U" (URW) foundry files. They're for > Adobe foundry files. These file names lack "U-" prefixes. There is no need to repeat what I said:- >>> Since there are no U foundry files, this is "intermediate" not "basic". > They're present because they ship _as part of the distribution archive_ > in font/devps, and BuildFoundries (I think) copies them to font/devpdf > (in the build directory, whence they're installed). They are present because you did not successfully create the conditions for a basic mode. > > this is "intermediate" not "basic". > > No, it's basic. But the PFA/PFB files for the base 35 fonts that aren't > in the base 14 set are _not_ present and therefore not includable > PostScript resources for the grops output driver, nor embeddable in PDF > by gropdf. I showed you what fonts should be available for basic you have the fonts which are available for intermediate. > I don't think this is a problem. Nothing in groff documentation says > that we install font description files only for fonts you can embed. > "Embeddable fonts" is not a concept that applies to most of our output > drivers. But I think you know the pdf only allows the base-14 fonts not to be embedded, every other font must be - to ensure a successful pdf is produced. As far as I know only grops and gropdf employ a download file which controls the fonts to be embedded. > > A further check is required, the contents of download will tell you > > where the ghostscript fonts were discovered. > > I disagree. Having font metrics available to a device-independent troff > is not the same matter as having an embeddable resource. They were > separate matters in Kernighan troff and they're separate for groff. > > > For "basic" the download file has virtually nothing in it. > > Right. Pretty much just groff's EURO/freeeuro.pfa, and some day, if I > get my wish, GROFFCHARS or something for the six rogue PostScript > glyphs. <https://savannah.gnu.org/bugs/?62932> > > > Thankyou. I just could not get them to work at all and you did not > > test them before committing. > > No indeed. I thought gropdf was more like grops than it is. Can I respectfully ask that if you commit changes to pdf production and are not going to test those changes yourself you ask me to test them for you. > > This was not a true "basic" test (see above), so rest of this is will > > be different to mine. > > It shouldn't be. All of the following docs should be built and > installed even if no fonts are available for embedding. (True of > "typesetting.pdf" only in groff Git's master branch.) Some, like > "typesetting.pdf" and "groff-man-pages.pdf", will look cosmetically > different if they can't embed the fonts they want. > > [...] > > > Great this is an "intermediate" as expected. > > > > > No warnings except regarding our usual 6 missing friends in > > > groff_char(7). (I didn't get those warnings in the "basic service" > > > build, because the build _wrongly_ omitted generation of > > > "groff-man-pages.pdf". See the stuff about `USE_GROPDF` above.) > > > > > > $ (cd ~/groff-HEAD/share/groff/1.24.0/font/devpdf && echo * | fold > > > -sw 72) > > > AB ABI AI AR BMB BMBI BMI BMR CB CBI CI CR CSH CSS CTH CTS DESC EURO > > > Foundry HB HBI HI HNB HNBI HNI HNR HR JPG JPM KOG KOM NB NBI NI NR > > > PB PBI PI PR S SS TB TBI TI TR ZCMI ZD download enc map symbolsl.afm > > > symbolsl.pfb > > > > > > This is the same set of files as at the basic service level...for > > > me. > > > > This is correct, your "basic" found ghostscript fonts!! > > No--only "ditroff" font description files for them. Not the same thing. Which would not be there if no ghostscript files were found (or make distclean was run). > > > (You show a "util/" directory and I don't because you're listing > > > "font/devpdf" in your _build_ directory, and I'm listing > > > "font/devpdf" in my _installation_ directory. The latter is what > > > matters for groff functionality in user-, as opposed to developer-, > > > -facing scenarios.) > > > > You are correct, but if the developer directory is incorrect so will > > be install (but not vice-versa). > > That depends on the logic of how the Automake file is written. > Historically, for "devpdf.am" in particular, shell wild cards have been > expanded in installation target rules. That's unidiomatic use of > make(1) in my opinion, and I've reduced that. For the most part, the > identities of files desired for construction or installation are either > literally encoded or stored in make(1) macros whose contents are > computed (often by testing Automake variables). Not really relevant. If the source files for an install are incorrect then the files in the target directory cannot be correct, but correct source files does not imply they will be correctly installed in target directories. So the first step is to ensure the font/devpdf files are built correctly, once that is confirmed the next stage is to ensure the other make targets (install distcheck etc) work as expected. As you failed to generate a proper basic run, consideration of what happens next is moot. > > > > Interestingly if you don't use --without-urw-fonts the only > > > > difference is the suppression of a number of (now) non-fatal > > > > warnings when in basic mode. I wonder if this flag could be turned > > > > on automatically if BOTH the ghostscript and URW font warnings are > > > > output by configure, to save users having to inform configure a > > > > status it is already aware of. > > > > Given configure can output a message about ghostscript missing (the G > > message) and no urw fonts (the U message) this table describes the 3 > > gropdf modes:- > > > > Mode G U > > basic* y y > > inter n y > > full - n > > I find this difficult to comprehend, but my hope is that my action item > list will bring us to a configuration summary report that we both, and > our users, can make sense of. It's a truth table. (Reminds me of the FTL6 language, one of my favourites, amazing how little typing is required to achieve complex conditionals). > > Notes:- > > > > Perhaps counter-intuitively 'y' means you have not got (i.e. it means > > you've got the message about not having) the thing! > > > > *basic: in this situation you need the flags which --without-urw-fonts > > currently sets which stops warnings from BuildFoundries (-W ?) and > > stops requesting font embedding (-P-e). This should mean all modes > > will be warn free ("As free as the wind blows") apart from the famous > > six (we are one better than Enid Blyton)! This takes the onus of using > > --without-urw-fonts from the user. > > I agree that that's a possibility. "--without-urw-fonts" may end up > being "scaffolding"[2] that we can kick away with further improvements > to our Automake scripts, as planned in my "action items". > > > > A. Report a summary line for the Ghostscript implementation, since > > > > > > its name is variable (usually "gs", but can be something else). > > > > This may be why you did not get a clean "basic" run (or no distclean > > before hiding ghostscript and urw-fonts), BuildFoundries uses > > "@GHOSTSCRIPT@ -h", ie the name of the ghostscript provided by > > configure. > > I'm not sure. BuildFoundries seems to be coupling the availability of > groff font description files with the availability of corresponding > embeddable digital fonts files, which doesn't seem quite correct to me. > It's not the way device-independent troffs have traditionally worked. > > That's not the same issue as what the configuration summary reports, > however. It's possible to have a Ghostscript executable present on the > system, and located by our configure script, but with no embeddable > fonts (they're either totally absent or only in Ghostscript's "%rom%" > whence we can't extract them). > > To date I think the gropdf build ignores that scenario. > > Using Debian package names for convenience, consider that there are four > possibilities. > > Installed packages > ------------------ > ghostscript gsfonts/fonts-urw-base35 > Y Y > Y N > N Y <-- case not handled > N N The two conditions are: G=ghostcript executable found (evidenced by not receiving the ghostscript message at end of configure), and U=urw fonts found (evidenced by "use URW fonts for PDF output : yes" at the end of configure. Definitely nothing to do with gsfonts. if ghostscript binary not available (first condition) then gsfonts can't be accessed because "gs -h" which is used to locate gsfonts will fail. So the second condition is purely whether urw fonts have been found by the end of configure. Don't complicate by looking for "installed packages". Configure already knows if a ghostscript binary exists, and it has looked in all the usual places for urw fonts (plus --with-urw-fonts-dir if specified). So you have true/false answers to the G and U questions. Here's the truth table again, but this time using Y for gotit and N for not gotit: Mode G U basic n n inter y n full - y In a truth table the '-' means "don't care" so the case you claim is not handled is covered by this. If U is true gropdf provides the full service no matter what the ghostscript condition. It really is as simple as this, there is no need for extra frills. Only if the mode is basic do you need to behave as if --without-urw-fonts had been specified. > But--Debian makes the unhandled case tedious to test because its > "ghostscript" package _depends_ on "fonts-urw-base35". I didn't feel > up to perturbing the dpkg database status into an unhappy state for the > sake of testing this oddball scenario. Some things, I must leave for > intrepid users who walk the unbeaten tracks of configuration space. Do not get involved with packages, just use the existing code in configure to satisfy whether G and U are true and false. There is no unhandled case, see above. On debian if you have ghostscript the urw fonts are installed in /usr/share/ fonts/type1/urw-base35 which is searched by configure so U will be true and G will be true, which according to the truth table means gropdf is full service. > As I've noted elsewhere recently: > https://www.usenix.org/legacy/publications/library/proceedings/sa92/spencer. > pdf > > What Spencer had to say about the C preprocessor's `#ifdef` in 1992 > applies without fundamental change to use of Automake conditionals. > > LATER: Anyway, doing a "basic service" build anew from a freshly > unpacked RC2 distribution archive, I get the following results. > > GNU roff version 1.24.0.rc2 > ---------------------------------------------------------------------- > installation directory prefix : /home/branden/groff-HEAD > C++ compiler and options : g++ -g -O2 > use libgroff's memory allocator : no > C compiler and options : gcc -g -O2 > Perl interpreter version : 5.32.1 > X11 support : enabled > X11 app defaults directory : > /home/branden/groff-HEAD/share/X11/app-defaults default paper format > : letter > 'groff -l' uses print spooler : lpr > use URW fonts for PDF output : no > preconv can use uchardet library : yes > can build groff.{info,html,txt} : yes > can build groff.{dvi,pdf} : yes > ---------------------------------------------------------------------- > configure: No Ghostscript program was found in $PATH. > ... > configure: The programs 'gs' and 'ps2ps' were not found in $PATH. > ... > configure: 'gropdf' will have reduced function. > > ...later... > > Confirmed. At the basic service level, the gropdf device is seeing the > groff font description files for all 35 of Adobe's Postscript Level 2 > fonts installed. This is a big big problem, honestly, you say you did a basic make run and end up with a full service set of fonts when you do a make install - what is going on? Please help by attaching ~/groff-HEAD/share/groff/1.24.0/font/devpdf/ download. Cheers Deri > $ (cd ~/groff-HEAD/share/groff/1.24.0/font/devpdf && echo * | fold -sw 72) > AB ABI AI AR BMB BMBI BMI BMR CB CBI CI CR CSH CSS CTH CTS DESC EURO > Foundry HB HBI HI HNB HNBI HNI HNR HR JPG JPM KOG KOM NB NBI NI NR PB > PBI PI PR S SS TB TBI TI TR U-AB U-ABI U-AI U-AR U-BMB U-BMBI U-BMI > U-BMR U-CB U-CBI U-CI U-CR U-HB U-HBI U-HI U-HNB U-HNBI U-HNI U-HNR > U-HR U-NB U-NBI U-NI U-NR U-PB U-PBI U-PI U-PR U-S U-TB U-TBI U-TI U-TR > U-ZCMI U-ZD ZCMI ZD download enc map symbolsl.afm symbolsl.pfb > > Again, I don't see a problem here. For people migrating, perhaps > trepidatiously, from PostScript to PDF, this provision could be helpful > and/or reassuring. Moreover, we don't _require_ that users employ a > package system to obtain digital font files or even put them in a > standard place. They can edit (as the administrator) the "download" > file in font/devpdf after groff is installed to locate the resources > they desire. > > That's a big part of what makes third-party font support challenging. > > Regards, > Branden > > [1] We see wild cards (or "globs") in some (un)installation targets > related to (a) generation of "info" files from our Texinfo manual, > because we have no way of knowing at build time how many info files > makeinfo(1) will carve it up into; and (b) HTML and image files > produced by grohtml(1), because like makeinfo(1), it constructs many > files from a single source. > > [2] https://lists.gnu.org/archive/html/bug-groff/2026-02/msg00000.html
