Re: build system: devpdf/download regression

[Deri]

On Saturday, 16 July 2022 12:02:29 BST G. Branden Robinson wrote:
> Hi Ingo & Deri,
> 
> At 2022-06-26T17:16:44+0100, Deri wrote:
> > > In general, i would recommend differentiating configuration variables
> > > by functionality.  For example, if all you need is one font path,
> > > i would expect having one variable to configure it.  Two variables
> > > would make sense to me if you have two different purposes or tasks,
> > > for example, on the one hand a font path that gs(1) and groff *read*
> > > already installed fonts from, and on the other hand a directory
> > > that groff *writes* its own font-related files to.
> > > 
> > > But it would seem unusual to me to differentiate a configuration
> > > variable according to the *source* of the information.  For
> > > example, if components of the font path can come from three sources,
> > > 
> > >  1. a static list of directories that you collect over the years
> > >  
> > >     by talking to people using different operating systems;
> > >  
> > >  2. autoconfiguration results, for example from `gs -h`; and
> > >  3. user configuration, for example from a ./configure option
> > > 
> > > then i would still expect one single variable since the whole
> > > point of autoconfiguration is overriding or supplementing static
> > > defaults and the whole point of user configuration id overriding or
> > > supplementing both.
> > > 
> > > What would be the point of splitting the variable according
> > > to the source of information?  (There may well be a point
> > > that i'm still missing.)
> > 
> > I was considering priority, I wanted to ensure Users choice came
> > first.  However, this can be achieved in one variable so long as users
> > choice is first, followed by the static paths, so I agree it makes
> > sense as one variable.
> 
> Where do we stand on this right now?  Is this something I can help move
> along?
> 
> It occurs to me that could have a single text file in the source tree
> which stores, one per line, a list of directories known to be useful
> historically for locating PostScript fonts (Ingo's #1 above).
> 
> BuildFoundries and groff.m4 could each read that, turn it into a
> $SEP-arated search path, and prefix it successively with directories
> scraped out of `gs -h` output and the user's choice of
> `--with-urw-fonts-dir`, if any.  Too bad it would be a pain to drop
> duplicates from the search path without disordering it.
> 
> My apologies for being a bit confused and uncertain; this aspect of
> groff is in flux right now but I think we're making it better.
> 
> Regards,
> Branden

Hi Branden,

My understanding is that the selection of paths to search is appended to the 
value of the --with-urw-fonts-dir config variable (if any). Then the sed in 
the configure script parses the string of paths as it does now. When Foundry 
file is built the @urwfontsdir@ is replaced by the string formed in the 
configure script. You can use ":" as the path separator since both sed and 
BuildFoundries currently use that character as a separator, it is only when 
parsing the ghostscript supplied paths that the O/S dependent 
@PATH_SEPARATOR@is used.

If this is done, all the static paths in the Foundry file can be removed 
leaving just the @urwfontsdir@ and (gs) entries.

I don't think ghostscript releases the afm files any more, just the fonts, 
which is sufficient to provide the default foundry but cannot be used to 
generate the extended glyphs for the "U" foundry. If the ghostscript fonts are 
not found, or has the fonts in %rom%, (and no URW fonts either) you end up 
with build warnings and a degraded devpdf capable of using the base 14 fonts 
but not embedding anything. These are the three possible outcomes when 
BuildFoundries is run with an empty download file:-

┌──────────┬─────────────────────────────┬───────────────────┬───────────┐
│          │ Ghostscript missing (%rom%) │ Ghostscript found │ URW found │
├──────────┼─────────────────────────────┼───────────────────┼───────────┤
│Base 14   │              ✓              │                   │           │
├──────────┼─────────────────────────────┼───────────────────┼───────────┤
│Base 35   │                             │         ✓         │     ✓     │
├──────────┼─────────────────────────────┼───────────────────┼───────────┤
│U Foundry │                             │                   │     ✓     │
└──────────┴─────────────────────────────┴───────────────────┴───────────┘

So, BuildFoundries never fails, it generates whatever it can. If the configure 
script can detect the ghostscript fonts separately from the urw fonts then the 
appropriate message can be output.

Cheers 

Deri