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. > 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. 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). > 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 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. > 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. > 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. > > (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). > > > 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. > 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 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. 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. $ (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
signature.asc
Description: PGP signature
