Re: build system: devpdf/download regression

[Ingo Schwarze]

Hi Deri and Branden,

Deri wrote on Thu, Jun 23, 2022 at 12:56:16AM +0100:
> On Wednesday, 22 June 2022 22:29:29 BST G. Branden Robinson wrote:
>> At 2022-06-22T21:30:25+0100, Deri wrote:

[...]
>>> I think the tests for awk and ghostscript need to just apply to the
>>> line which uses those programs, not the whole section, but the patch
>>> is good.

>> I'm happy to change GROFF_URW_FONTS_CHECK in this manner, but I'll hold
>> off until you or Ingo pushes his patch.

Done.  So, Branden, go wild!

I deliberately didn't add a ChangeLog entry because you two are about
to change this same code in a more fondamental way, and when you commit
the future patch that will ensure the font paths automatically stay
in sync, any ChangeLog entry i might have added would become obsolete
right away.

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

Then again, if you see strong technical reasons to do things
backwards in this particular case, that is, have the autoconfiguration
system read defaults from source files that are intended for
being processed much later (in this case, the Foundry), so be it.

>>> Since the fonts don't appear in any of the directories yielded by "gs
>>> -h" means that the person porting ghostscript for your system decided
>>> to use the option to have the fonts embedded in the gs executable
>>> (%rom%) rather than as separate font files. I'm not sure if there is
>>> much advantage with modern hardware. Here's a chap asking where the
>>> font files have gone:-
>>> 
>>> https://stackoverflow.com/questions/38331893/ghostscript-fonts-folder-remo
>>> ved-from-later-versions

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

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.

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

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?

>> I wonder if we should detect this and warn about it.  I've gotten
>> pretty familiar with our Autoconf macros.

> I don't think so. If the URW fonts are not found the just suggesting to 
> install the URW fonts is sufficient. They can't do much if their packaged 
> ghostscript has the fonts baked into the executable, but they can install a 
> URW fonts package or tar-ball.

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?

Yours,
  Ingo