Re: Font path issue

[G. Branden Robinson]

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".

sub LoadDownload
{
    my $f;
    my $found=0;

    my (@dirs)=split($cfg{RT_SEP},$fontdir);

    foreach my $dir (@dirs)
    {
        $f=undef;
        OpenFile(\$f,$dir,"download");
        next if !defined($f);
        $found++;

        while (<$f>)
        {
            chomp;
            s/#.*$//;
            next if $_ eq '';
            my ($foundry,$name,$file)=split(/\t+/);
            if (substr($file,0,1) eq '*')
            {
                next if !$embedall;
                $file=substr($file,1);
            }

            $download{"$foundry $name"}=$file;
        }

        close($f);
    }

    Die("failed to open 'download' file") if !$found;
}

I have two possible concerns about this.

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.

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

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.)

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.

signature.asc
Description: PGP signature