Re: Font path issue

[G. Branden Robinson]

Hi Ralph,

At 2022-08-21T17:43:03+0100, Ralph Corderoy wrote:
> How about making %download be a hash of lists and appending to the end
> of the relevant list without checking anything.  Then run along the
> relevant list when the file is actually needed to find the first, if
> any, which opens.  If the open fails with ENOENT then try the next,
> otherwise it's an error; if the file exists but, say, the permissions
> stop me reading it, then I'd like to know.

Hmm, yes, I like this.  Saves unnecessary work.

> I'm assuming quite a few of the files behind the ‘"$foundry $name"’
> keys won't be needed so this tests them lazily rather than up front.

This is a good idea too.  Indeed, in most cases you're right.  Our
grops(1) and gropdf(1) man pages are bizarre outliers in that they
really do try to employ all of the (text) fonts.  Few documents will.

> Apologies if that's not useful, I've just dipped into the thread.

No, those are 2 good points, I think.

> Is ‘"$foundry $name"’ a safe key given these foundry,name pairs give
> the same result?
>     Foo     │ Bar Xyzzy │ Foo Bar Xyzzy
>     Foo Bar │ Xyzzy     │ Foo Bar Xyzzy

The "foundry" is a concept unique to gropdf.  There has been discussion
of extending it to grops as well, since so much else is similar.  I
think we can proclaim that white space characters are not valid in
foundry names, and that would resolve any ambiguity.

A remaining question, albeit a somewhat academic one, is whether
white space is valid in font identifiers.

CSTR #54 did not, I think, specify what subset of ASCII was valid for
font names in troff--and troff had a penchant for accepting truly wild
things in identifiers, like ASCII control characters and
non-parameterized escape sequences--however the available examples and
existing practice clearly expect them to be well-behaved (to a shouty
capital fault, even).

I've documented some further restrictions on font identifiers in
Git's groff_font(5).  "DESC" is not a valid font name[1]; "0" can't be
automatically mounted by the DESC file; positive integers are valid but
difficult to work with because the formatter preferentially interprets
them as mounting positions.

In light of those, ruling out white space characters in font names would
probably not discomfit many users.  But it's not an urgent issue, IMO.

Regards,
Branden

[1] However it's not explicitly rejected.  libgroff goes ahead and tries
    to parse it.  I admit I'm surprised by how far it gets.

$ ./build/test-groff
.ft DESC
troff: .../font/devps/DESC:15: error: unrecognized font description directive 
'lpr' (missing 'kernpairs' or 'charset'?)
troff:<standard input>:1: warning: cannot select font 'DESC'

(A) Possibly I should have a function lower down the call stack reject
    "DESC" as a font name before even attempting to open it.
(B) I see a deviation from the GNU Coding Standards for diagnostic
    messages; we don't need a space after "troff:" when it's followed by
    a file name.

signature.asc
Description: PGP signature