[bug #61423] allow paths in "name" directive of font description file, restoring historical groff behavior

[Dave]

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/