Follow-up Comment #23, bug #67207 (group groff): At 2025-06-19T13:49:05-0400, Deri James wrote: > Follow-up Comment #22, bug #67207 (group groff): > > [comment #20 comment #20:] >> (This side quest is threatening to overrun this ticket's actual purpose, >> which suggests opening a new one, but substantial history for both issues is >> already here, so they're hard to disentangle now.) > > Even more, this started in bug #65098 in response to Branden's > problems with devpdf.am. (The fix for the named problem of this bug > was the patch in comment #2, and is also part of the SS patch set in > comment #8, which also would close bug #65098 as well). > > Branden's mega patch in comment #4 (91Kb) unfortunately broke the download > file error checking. And I could not believe so many changes were needed just > to integrate SS and StandardSymSL.pfb into devpdf.am,
Well, I have to admit, part of that was misery I brought on myself by
trying to make "font/devpdf/devpdf.am" less clever and more
idiomatically Automakey.
Here's that change, which doesn't exist in Savannah Git, just my
checkout.
commit 47f8ea1ad422730111e773bbe5deb957e9c898a9
Author: G. Branden Robinson <g.branden.robin...@gmail.com>
Date: Sun Jun 8 12:42:57 2025 -0500
font/devpdf/devpdf.am: Refactor.
This change also ships font description file names for the "pdf" output
device corresponding to the 8 new font description files for CJK script
support recently added for the "{x,}html", "ps", and "utf8" devices.
These are intended as abstractions of faces to permit consistent naming
while permitting customization, just as with the 12 text typefaces
supported across output devices for Latin scripts in groff (three
families of four styles each). These CJK font descriptions are not
organized into groff font families, but are similar. They are not
mounted by default.
CSH: Simplified Chinese, Hei style
CSS: Simplified Chinese, Song style
CTH: Traditional Chinese, Hei style
CTS: Traditional Chinese, Song style
JPG: Japanese, Gothic style
JPM: Japanese, Mincho style
KOG: Korean, Gothic style
KOM: Korean, Mincho style
* font/devpdf/devpdf.am: Make this script more Automake-idiomatic (I
think) and resemble other groff Automake scripts more closely.
(devpdf_builddir): Define macro.
(GROFF_FONT_FILES, ENC_FILES, MAP_FILES): Drop macros populated by
shell command substitution in favor of static file lists...
(DEVPDFFONTFILES_FROM_DEVPS): ...like this...
(DEVPDFFONTFILES_FOR_URW) [HAVE_URW_FONTS]: ...and this.
(DEVPDFFONTFILES): New macro contains only
`DEVPDFFONTFILES_FROM_DEVPS` plus the "download" and "DESC" files.
(devpdffontdata, devpdffontencdata): Rationalize contents, aligning
files and macro contents with installation requirements so Automake
takes care of installing and uninstalling them.
(MOSTLYCLEANFILES): Add `devpdffontdata`, `devpdffontencdir`,
`devpdffontmapdir`, so that Automake takes care of cleaning them.
($(DEVPDFFONTFILES_FROM_DEVPS)): New target copies "ps" device's font
descriptions to build's "pdf" device data directory.
($(devpdffontencdata)): Now that the "text.enc" encoding file name is
stored in a macro, use it and compute its basename instead of using
literals.
($(DEVPDFFONTFILES_FOR_URW)): Make the "pdf" device's "download" file
depend on this macro's contents, which may be empty if
`HAVE_URW_FONTS` is not defined by the "configure" script.
(font/devpdf/stamp): Respell dependencies using above macros.
(mostlyclean-local, mostlyclean_devpdf_extra)
(install-data-local, install_devpdf)
(uninstall_groffdirs, uninstall_devpdf): Drop targets made redundant
by better population of `devpdf*data` macros above.
> so I had a go, and the patch is only 5Kb and I can't detect any
> problems with it's operation.
Some of them might resurrect when I re-apply the foregoing. I'll find
out.
> I was hoping Branden would be able to give it a once over to confirm
> it does not cause a problem to the build system, but I know he's busy
> so it would probably help him if I commit the patch and close both
> bugs.
I'm working on this today. I haven't tested your new patch yet but I
notice that it introduces a new "download.in" file which I'll bet _will_
solve one of the problems I ran into, which was "BuildFoundries.pl"
getting mad, finding the input "download" file unacceptable, and
producing a nearly empty one for devpdf, containing only an entry for
the "FreeEuro" font--and without throwing much if anything in the way of
diagnostic messages, which drove me bonkers.
I'm starting to think we can make life easier for everyone if we get
BuildFoundries.pl out of the business of being involved in the build.
While we normally want to dogfood things (and I enjoyed the opportunity
to exercise groff's otherwise little-used _pfbtops_ program as part of
the build), you and I have repeatedly pulled "BuildFoundries.pl" in
different directions with respect to error reporting handling.
And I think I know why: when I run it from the build, I want it to be
super-paranoid and bring the build to a crashing halt as soon as it
encounters anything even slightly unexpected, whereas end users who just
want their damn third-party fonts to be seen by groff so they can use
them, want the tool to bullishly move forward until it can't, or it gets
the job done.
So I'm getting the notion that "devpdf.am" should run afmtodit and
sed(1) or whatever else it needs to create build artifacts (including
"download", which your patch may now be taking care of already,
relieving "BuildFoundries.pl" of that responsibility.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67207>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
