[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Font path issue

From: G. Branden Robinson
Subject: Re: Font path issue
Date: Sun, 21 Aug 2022 11:26:55 -0500

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)
        next if !defined($f);

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

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


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


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

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]