Re: build, BuildFoundries, and gropdf changes coming

[G. Branden Robinson]

Just the person I was hoping to hear from! :D

At 2022-11-11T17:04:32+0000, Deri wrote:
> This might be one of your "thinkos". :-)

Oh, it's worse than that if I'm having to do design work under pressure.
:-O

Fortunately I've just now gotten groff-man-pages.pdf building again with
the FreeEuro font happily embedded.

> It is not a very good idea. The URW fonts, packaged or (sometimes)
> delivered with ghostscript, have various nom-de-plumes all of which
> require checking - this is what BuildFoundries does. There is no way
> of knowing whether the directory pointed to by -D contains identical
> metrics to when the groff fonts were created by afmtodit. In addition,
> sometimes the required .afm files are in a separate directory, which
> BuildFoundries also searches. I don't see the point of duplicating
> BuildFoundries code within gropdf, but without it you would only do
> half the job.

I broadly agree with this; a `-D` option was not the hammer I needed.

> Please can you elaborate on what you mean by "this download business".

It sounds vague because it was vague; I mean the entire extra mechanism
of font embedding in output documents that AT&T troff never (as far as I
know) dreamed of doing.

> As far as I know there have been two separate reasons for missing
> fonts:-
> 
> A) During groff builds gropdf could pick up an "old" download file.
> This happened because gropdf would favour the last matching entry and
> the build font directory would be passed as the first location, so if
> either the site- fonts or the system fonts directories contain stale
> entries, these were favoured. This is no longer a problem because
> gropdf now favours the first valid entry, so the entries in the shiny
> new build font directory (just created by BuildFoundries) are used.

I haven't seen first-hand this problem occur and then be overcome by
your changes, but the code looks right.  I have confidence in it.

> B) After groff installation the entries in the the system font
> directory can go stale if a new version of ghostscript or urw-fonts
> package is installed, with different directory structure or filenames.
> The simple solution to this is to re-run BuildFoundries which would
> correct stale download file. At least, this used to be the method, but
> BuildFoundries was removed from the list of executables installed in
> the bin directory.

I guess that decision was taken several years ago at least.

> So, perhaps the kindest thing for users, is to reinstate
> BuildFoundries as a tool and perhaps reference it when gropdf finds
> the file is missing.

Well, maybe.  I keep running into my own problems with BuildFoundries.
It seems to do several different, albeit related things.  I keep feeling
the urge to break its operations into smaller tools.  As it is I'm
getting it out of the business of dealing with the EURO font at all.
But I have no ambition to further alter it at this date.

> Is there something I am missing regarding "download business"? What is
> the solution to (B), it certainly is not passing a -D flag.

It turns out part of the problem--people probably won't be surprised to
learn--was the new diagnostic message being emitted when an embeddable
font had an entry in the "download" file but none of the file specs
listed there could be successfully opened.

Everybody who reads groff-commit knows I am annoying and demanding
regarding diagnostic messages, and this occurrence was no different.  So
the message I was reading led my up the garden path for a while until I
revised it.  Actually, my first revision of it (shared in the mail to
which you replied) wasn't good enough; on the second try I got it.

Long story short, here's what we get from a build from Savannah.  (I've
replaced a long boring path to my build directory with "...".)

.../groff/build/gropdf:man/groff_char.7: warning: The download file in 
'.../groff/build/font/devpdf'  has erroneous entry for 'FreeEuro (EURO)'

Now I have this (with some fake "download" entries contrived to force
failure).

.../groff/build/gropdf:man/groff_char.7: warning: unable to embed font file for 
'FreeEuro' (EURO); check "download" file (tried: 
"/home/bogus/nonsense/freeeuro.pfa:/usr/share/humbug/notgonnafindit.pfa")

Telling me where the download file was didn't help me much (it's gotta
be one of the ones in the groff device/font description file search
path).  Telling me which font filespecs were actually attempted for open
helped me a lot more.

> > commit caff5c9e92fbecbd2ccff413a1cb0456a879f8c9
> > Author: G. Branden Robinson <g.branden.robinson@gmail.com>
> > Date:   Wed Nov 9 08:24:52 2022 -0600
> > 
> >     [devpdf]: Tweak generation of "download" file.
> > 
> >     * font/devpdf/devpdf.am (font/devpdf/download): Improve
> >       comprehensibility of comments in generated "download" file.  Stop
> >       bracketing path element separator with spaces.
> > 
> We have been here before,

I remember.  Every time I see those gappy colons, my brain throws an
exception that is only handled way down the call stack.  I think it is
an un-Unixy Ghostscript parochialism that we need not emulate.

> it used to matter, look at the output of gs -h, you will see space
> bracketed delimiters. I think I made a change to accept with/ without,
> can't remember.

You did, and as far as I can tell, it does.  Good show!

> > commit b8b75b176365695ca380362a725a721081828a2e (HEAD -> master)
> > Author: G. Branden Robinson <g.branden.robinson@gmail.com>
> > Date:   Wed Nov 9 10:28:32 2022 -0600
> > 
> >     [devpdf]: Do more explicit work and less magic.
> > 
> >     * font/devpdf/devpdf.am (devpdffont_DATA): Add all of the PostScript
> >       Level 2 base 35 font descriptions (from the default foundry).  Also
> >       add the "EURO" font description file and the "FreeEuro" PFA and AFM
> >       files, making these explicit targets and dependencies.
> > 
> >       (devpdffont_DATA) [HAVE_URW_FONTS]: Also add the URW foundry's version
> > of the base 35 fonts.
> > 
> >       (font/devpdf/freeeuro.afm): Add new target, a simple file copy from
> >       the devps font directory.
> > 
> >       (font/devpdf/EURO): Generate font description file from the devps font
> > directory.
> > 
> >       (font/devpdf/freeeuro.pfa): Add new target, a simple file copy from
> >       the devps font directory.
> > 
> >       (MOSTLYCLEANFILES): Clean freeeuro.{afm,pfa}.
> 
> Why duplicate freeeuro.{afm,pfa} from devps?

Initially it was because I couldn't tell whence it was trying to be
opened.  Recall the diagnostic:

.../groff/build/gropdf:man/groff_char.7: warning: The download file in 
'.../groff/build/font/devpdf'  has erroneous entry for 'FreeEuro (EURO)'

"Okay," the user thinks.  "The entry was erroneous.  So what was it?"

Now I know.  But now I am also inclined to keep the copies in place
because (1) they don't eat much disk (22.5 kiB total) and (2) doing so
will make it easier for distributors to segregate PDF support, which is
familiar and relevant to users born since 1990, from PostScript support.

Such distributors would probably also change the default output device
from "ps" to "pdf", of course.

In no other place in groff do we have one output driver sticking its
nose into the font directory of another output driver to locate
resources.

This change also encapsulates the targets and dependencies expressed in
the devpdf.am Automake file more cleanly, but that's admittedly a minor
benefit appreciable only by developers.

> > [2] The FreeEuro font file is cheekily located at
> >     "../devps/freeeuro.pfa", which is nicely robust for a groff
> >     _build_ but pretty dubious for installation.
> 
> I don't understand this. Why is it cheeky, looks like a normal
> relative path to me?

Well, because _every_ other filespec in the download file was absolute.
And our files in the Savannah repository obviously can't know the
absolute path used for any given user's groff build.  It looked like a
hack to me.

> Why is it dubious for installation? You may have missed that gropdf
> converts all relative paths to an absolute path while reading download
> files.

I did in fact miss that :-O (though doesn't the OS do that anyway,
effectively?).

Anyway, since the tree is conceptually red right now because the Euro
glyphs are missing from groff-man-pages.pdf, I'll get this stuff tidied
up (I noticed easy 4 different wordos in my commit messages) and try to
push it soon.

Thanks for jumping onto this!

Regards,
Branden

signature.asc
Description: PGP signature