URL: <https://savannah.gnu.org/bugs/?61423>
Summary: allow paths in "name" directive of font description file, restoring historical groff behavior Project: GNU troff Submitted by: barx Submitted on: Wed 03 Nov 2021 11:48:31 PM CDT Category: Font devps Severity: 1 - Wish Item Group: New feature Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Planned Release: None _______________________________________________________ Details: My system has a /usr/share/groff/site-font/devps with a hodgepodge of font description files collected over the years through means I don't always remember. Most of these files contain a simple "name" directive that merely repeats the filename. A few files contain a full pathname in this field. These files have worked fine for the past couple of groff releases, all the way up through 1.23.0.rc1. A recent change -- I'm gonna go out on a limb and accuse September's commit c0d1bb28 <http://git.savannah.gnu.org/cgit/groff.git/commit/?id=c0d1bb28>, though I've not done before/after testing to confirm this -- now prevents these files from loading, troff giving up with the error "font description file name 'JR' does not match 'name' argument '/full/path/to/JR'". (In my case, the /full/path/to/JR as specified in the font description file did not match the actual full path of its final resting place; apparently I used some tool to generate the file in a working directory, and this tool encoded the full path of its working directory onto this line. But even when I updated the path to match the file's current location, it still failed with the same error.) The current Texinfo document says this directive contains "the name of the font," which does suggest that /a/list/of/directories before it might be unexpected. However, that did work historically. Editing the font description file to contain what troff wants here is fairly simple. However, is there any benefit to the user of now disallowing a full path in this field that was previously allowed? If so, that's fine, and this change request can be happily closed as "Wont Fix". But if not, it might be better to not gratuitously break font description files that have historically worked. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?61423> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/