Re: build system: devpdf/download regression

[Deri]

On Thursday, 23 June 2022 14:05:29 BST Ingo Schwarze wrote:
> > I would suggest I add a new parameter to Foundry.in:-
> > 
> > static_paths|/usr/share/fonts/type1/gsfonts /usr/share/fonts/default/Type1
> > / usr/share/fonts/default/Type1/adobestd35
> > /usr/share/fonts/type1/urw-base35 / opt/local/share/fonts/urw-fonts
> > /usr/local/share/fonts/ghostscript
> > 
> > Then the groff.m4 check can pull the paths from the file.
> 
> I don't feel strongly about this, i just wonder.  Isn't the usual
> way of autoconfiguration as follows:
> 
>  1. Define a configuration variable.
>  2. Unconditionally set that variable to a sane default value,
>     in this case, the default font path currently duplicated
>     in groff.m4 and Foundry.in.
>  3. Run some autoconfiguration tests that change configuration
>     variables as appropriate for the system we are running on.
>     In this case, they would likely do something like
>     adding directories to the font path configuration variable
>     defined in steps 1 and 2.
>  4. Use the configuration variable from source files during the
>     build, in this case probably from the Foundry and maybe
>     from others, too.

Hi Ingo,

You are positively correct. You can tell I have never looked after a big 
project! In the same way that the choice of URW directory is passed into 
Foundry.in, although I would prefer separate variables, one for the users 
choice and one for the static paths.

> Let me paraphrase to see whether i understood this correctly.
> 
> The gs(1) program generally needs access to a specific set of fonts.
> Consequently, for the main ghostscript package to be useful, these
> fonts need to included in the main ghostscript package (as opposed
> to be provided by a separate fonts package).

Yes, since gs has an option to embed font, and if the postscript or
pdf file it is processing does not contain the font, it needs access to the 
fonts to embed.

> There are two alternative ways how these fonts can be included in
> the main ghostscript package: Either as separate font files; that's
> the old way.  Or embedded into the gs(1) executable itself; that's
> what upstream (the ghostscript project) now recommends.  But you
> say benefits from embedding these fonts are likely negligible.

The %rom% embedded method is newer and sometime past it was popular, but 
looking at current linux distributions they don't appear to be using it, 
although I believe they were in the past. On my system, rpm based, the 
ghostscript-common package contains the separate font files, and there is a 
separate urw-fonts packages with the fonts with their original ms-dos style 
names. So the ghostscript package is stand alone and does not depend on urw-
fonts rpm.

Debian bullseye also has two packages, libgs9-common and fonts-urw-base35. The 
fonts under /usr/share/ghostscript/9.53.3/Resource/Font/ in the libgs9-common 
package are in fact symbolic links to the equivalent fonts in the fonts-urw-
base35 package, which makes sense.

> In OpenBSD, we have these fonts *both* embedded in the main gs(1)
> executable (such that they can be used even if our ghostscript-fonts
> package is not installed) *and* packaged separately in the
> ghostscript-fonts package (such that groff ./configure can detect
> them and the groff PDF Foundry can generate font descriptions for
> them even when the main ghostscript package is not installed).
> 
> But theat means if somebody wants to do both a full groff build
> and run gropdf(1) on the same OpenBSD machine, they actually need
> to install *two* copies of these fonts: the ghostscript-fonts
> package for ./configure and Foundry and the main ghostscript
> package for run-time usage by gropdf(1).

To build and/or run gropdf you only need the urw-fonts, you don't need 
ghostscript itself. If your ghostscript-fonts can be installed without 
installing ghostscript itself you are good to go. The fonts embedded in the 
ghostscript executable are probably far more compressed the separate font 
files which was probably an advantage before SSDs and NVme disks.

The whole point of looking for the fonts within ghostscript is because the 
user is more likely to have ghostscript installed than a stand-alone package 
of the URW fonts. However, ghostscript dropped the .afm files from the 
Resource directory a long time ago, so if you only have ghostscript installed, 
and it contains font files (i.e. not embedded) all you would get is the 
default fonts, not the U- fonts with the extra glyphs, since I need to run 
afmtodit to generate the groff font files. For the default foundry I only need 
the font file because the groff font files are copied from the grops 
directory, rather than built anew.

> Do you think it would be an improvement to remove the fonts from
> the gs(1) executable (and consequently, from the main ghostscript
> package) and instead have the main ghostscript package depend on
> the ghostscript-fonts package?

This is what Debian have done with symlinks in the Resource/Font directory. If 
I get the chance, as I've got a version of ghostscript with separate font 
files, I'll do an strace on file openings to see if it actually loads the 
files if it has not been told to embed all fonts, my hunch is that it does not 
need to access the font unless it needs to embed a font which is not supplied 
by the postscript or pdf file it is distilling.

> Well, if i understand correctly, we *can* do something about that.
> If the fonts are "baked into the executable" in the main ghostscript
> package, *only* gs(1) can use them, but no other program (for example,
> groff ./configure and Foundry).  We could change our main ghostscript
> package to depend properly on installed fonts instead of "baking in",
> such that other programs can use these fonts, too, couldn't we?
> That would seeem less selfish to me on the part of the gs(1)
> program, wouldn't it?

If the results of gs -h include the text %rom% I believe this means some files 
have been baked in, but you should talk to the ghostscript packager. One 
wrinkle, if you go with just one copy of the fonts and use symlinks is that 
ghostscript uses different names for the fonts than the old ms-dos names.

Cheers 

Deri

> Yours,
> 
>   Ingo