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

[G. Branden Robinson]

Follow-up Comment #2, bug #61423 (project groff):

The thing I love about making half-informed speculations is how quickly
someone thunders to my door to correct me.  Sometimes, I even manage to do it
to myself.

[comment #1 comment #1:]

> As tempting as it would be to say that this is why we don't validate the
value of the `name` directive in the first place, I don't believe that's true.
 It was simply _never_ implemented, going all the way back to 1991.  The `if
(strcmp(p, "name") == 0))` test was followed by a pair of empty braces.  And
in 1991 a port of groff to MS operating systems may well have been regarded as
unthinkable: not only was the 8.3 file name convention the only one available
on the platform back then, but I can't imagine that the C++ compiler situation
was a happy one.  (Back then, the way forward was going to be OS/2, anyway.)

And then there's this from our ChangeLog.115, which goes back to the dawn of
recorded groff history.


Sun Sep 29 08:40:57 1991  James Clark  (jjc at jclark)

        * pic/pic.y (YYDEBUG): Don't define for Borland C++.
[...]                                                                      
        * pic/main.c: On MSDOS munge argv[0].

        * lib/ptable.h: Define name2 as _Paste2 for Borland C++.


So, yes, early groff _did_ support MS-DOS, and as Borland C++ was only ever a
product for MS-DOS/Windows <https://en.wikipedia.org/wiki/Borland_C%2B%2B>,
that speaks to the compiler situation.

I still want (partial) validation anyway, because copying one font file to
serve as a template for another is the kind of thing a groff device/font
hacker is going to do, and it's extremely confusing to have a text file lie to
your face about what it is.

Essentially the stuff in the directive argument before the last slash will
become a comment field, just as the entire argument has been an (undocumented)
comment field since 1991.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61423>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/