Re: Font path issue

[Deri]

On Sunday, 21 August 2022 17:26:55 BST G. Branden Robinson wrote:
> Hi Deri,
> 
> At 2022-08-21T01:12:07+0100, Deri wrote:
> > Gropdf is different, it takes into account all download files found,
> > so there is no need to duplicate entries into the site-font download
> > file. You could organise your fonts into separate families, each with
> > its own separate download file just for that family, and then list the
> > directories separated by a ":" in GROFF_FONT_PATH.
> 
> It looks to me that the way gropdf does this is by loading _all_
> download files it can find, and the last one to declare a font file for
> the corresponding foundry and font name "wins".
> 

[...]

Hi Branden,

> I have two possible concerns about this.

Let me soothe that furrowed brow.

> 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?

> I think it _might_ be better to (a) perform that check (with the `-r`
> operator, I reckon), only adding $file to the hash if that succeeds and
> (b) skipping the validity check and hash update if the key ("$foundry
> $name") is already present.  Algorithmically, this would be faster, if
> that helps anyone.[1]
> 
> What do you think?
> 
> Whatever we settle on, we should make grops work similarly.  As I
> recall, string-keyed associative arrays were an early example in the
> very _first_ edition of Stroustrup's C++ book, so porting the code over
> might be an amusing exercise.  :)  (groff _almost_ does not use the STL
> at all.)

There is no need to use these arrays. Download files are tiny the processing 
time to crunch through each download file would not be a large burden. 
Particularly if the internal font names for the base-35 fonts are stored in 
the program, so that it knows it does not even need to search in the download 
files for them, as the default we provide grops never embeds those. 
Technically, you can make grops embed a base-35 font by adding an entry to the 
download file, although, whenever there is a question about embedding fonts in 
a pdf distilled from grops, the usual answer involves passing parameters to 
ghostscript.

If the base-35 fonts are added as a skip list for searching download, so the 
fonts are not embedded, as is the current default behaviour, then grops would 
need an -e parameter (like gropdf) which will tell it to ignore the skip list 
and search the download files, for people who want grops to embed those fonts.

Cheers

Deri

> Regards,
> Branden
> 
> [1] On the other hand, we'd be guaranteed disk I/O for every entry that
>     can't be prediscarded.  You win some and you lose some.