[bug #62950] [gropdf] revise 'download' resolution process

[G. Branden Robinson]

URL:
  <https://savannah.gnu.org/bugs/?62950>

                 Summary: [gropdf] revise 'download' resolution process
                 Project: GNU troff
               Submitter: gbranden
               Submitted: Wed 24 Aug 2022 10:12:36 AM UTC
                Category: Device gropdf
                Severity: 1 - Wish
              Item Group: Feature change
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Wed 24 Aug 2022 10:12:36 AM UTC By: G. Branden Robinson <gbranden>
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.







    _______________________________________________________

Reply to this item at:

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

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