commit 7e5d433ba5ddc2389986a5c02f91eb57fc1de47d
Author: Deri James <deri@chuzzlewit.myzen.co.uk>
Date:   Tue Nov 8 21:03:49 2022 +0000

    [gropdf]: Cater for invalid entries in download file.

    * src/devices/gropdf/gropdf.pl: Test if path in the download
    file points to a readable file. Also change order so that the
    first valid entry is used as the font to embed. This replaces
    previous order where last found entry is used.

    This change is discussed in <https://savannah.gnu.org/bugs/?62950>.

comment #7:

> I have finished testing and found an issue, not really related to this issue but found during testing. Since the groff_man_pages.pdf uses the freeeuro font the download file in build/font/devpdf correctly has the entry "../devps/freeeuro.pfa" which is correct once installed in the system directory, but while building it is in font rather than build/font which is not searched, so an error is given.
>
> Fixes can either be:-
>
> "build" freeeuro.pfa/afm by copying to the build directory, the same as is currently done for zapfdr and symbolsl, or
>
> Change the GROFF_FONT_PATH used during the build to include the src_directory/font as well.
>
> I will soon release my changes, but I thought I should document this problem.

Thanks!  If you want to reassign the ticket to me after you push, or simply resolve it as fixed, I'll deal with the issue you raise.  Thanks for the heads up.

Making this is a 1.23 release goal since people keep tripping over it.  gropdf didn't get any worse since 1.22.4 (quite the contrary).

What I think has happened is that my introduction of the groff-man-pages.pdf artifact (with all fonts embedded) has exposed the sensitivity of the previous approach to file system layout issues.

Between:

1. Increased determinism in URW font directory location;
2. Improved documentation of the gropdf Foundry and download files;
3. Improved diagnostic messages in gropdf itself; and
4. What Deri has in the works for to resolve this ticket,

I think we'll have a substantially improved gropdf font handling story for groff 1.23.

Hmm, since grops should one day follow gropdf's lead on this (bug #62938), a consideration besides "how hard is this to do in perl?" might be "how hard is it to replicate this algorithm in C++?"  Or it might not: from the user's viewpoint, the behavior of Deri's plan and Ralph's should look the same, so the implementation details could be left up to the coder.

I think this is a bit more than a wish. The current gropdf behaviour (choose last) causes build to fail if site or system download file contains "stale" entries for the groff system fonts. Staleness can occur if ghostscript is updated without making amendments to the download files (or re-running BuildFoundries).

If the priority order is simply changed to "choose first" you run into the problem that if a user downloads groff as a package, and the site-font contains stale entries for the standard groff fonts, jobs which previously completed successfully would now fail because the first matching entry is the stale entry in site-font. Whereas with the current "choose last" the (possibly) valid system entry would be used, i.e. a code change which would result in groff no longer working on a previously functioning system. Ralph's suggestion (an array of hashes, one for each download file) would certainly work, but I think there is a slightly easier method.

The goal is to find the first valid entry, i.e. the font file entry points to a file which exists and is readable, plus inform user if they have tried to use a font which points to a file which does not exist. Since this is a binary issue, whether the file pointed to is readable or not, I create two hashes from the various download files, valid entries and invalid entries. When gropdf is required to embed a font, and it is not found in the valid entries, one of two messages are output. If it is present in the invalid hash a message identifying the font and particular download file is issued, otherwise the existing message concerning possible corrupt download file.

I have documented the method I have adopted for gropdf in case someone wishes to do something similar to grops.

Deri wrote in https://lists.gnu.org/archive/html/groff/2022-08/msg00202.html :

> 1.  As noted above, the "last one wins"; this is even more different
>     from other groff path-searching behavior than continuing to search
>     if an initially matching resource is found to be invalid.

Having multiple entries for the same font would be unexpected. There is no way
of knowing which the user determines is the correct one, and one way round is
a little less typing. :-)

However, at the moment it favours the system directory which is checked last,
and we should favour font directories provided by the user. So I am happy to
change to first wins.

> 2.  There _is_ no validity check; the `download` hash is populated
>     without checking to see if the font file exists or is readable.

This is the wrong place for a validity check of this type. It is quite valid
to have download entries for files that don't exist. The error should come if
you try to embed a font which is unreadable, which it does.

Imagine you do some house keeping and remove some fonts and their .pfas but
don't edit the download file, possibly because you are unaware of it, because
install-fonts.sh did it all for you, why should gropdf nag every time it is
run for something which does not affect its output?

This all makes sense to me.

There are further comments but they relate to grops so I'll file a separate ticket for those.