[bug #63808] configure gives incorrect information regarding pdf generation

[G. Branden Robinson]

Follow-up Comment #42, bug #63808 (project groff):

[comment #40 comment #40:]
> > Then you are saying "urw absent, gs present" is not a supported groff
configuration scenario.
> 
> No I am certainly not! Maybe representing the logic as a truth table may
help you:-
> 
> *Detab gropdf-font-checks
> C Is Ghostscript available      Y  -
>   Are URW fonts available       -  Y
> A Run check-default-foundry.sh  X  X
>   Run check-urw-foundry.sh      -  X
> 

It does not, for reasons I'll get to below.

> From this you can see the default foundry is expected and should be checked
if ghostscript is present and if URW fonts are found. If URW fonts are found
the U- foundry should be checked as well. How do you get from this logic to gs
only not being supported?

I was thinking that because URW donated some fonts to Ghostscript, they should
always be available on a Ghostscript installation, though the user may have an
alternative/forked/more-up-to-date URW font collection that they would prefer
to use.  This makes for two separate dependencies, so 2^2 configuration
combinations.

> > The question I was trying to ask was, "how do I simulate the scenario of
URW fonts being absent and Ghostscript being present on the Debian system I'm
using for testing?"
> Now, this a good question. So you have hidden your urw-fonts and you now
have dangly bits in ghostscript Font directory. cd
/usr/share/ghostscript/9.53.3/Resource and rename Font to oFont.Unpack the
file gs-fonts.tgz, which I have attached. This will recreate the Font
directory with the correct ghostscript supplied fonts (see
https://git.ghostscript.com/?p=ghostpdl.git;a=tree;f=Resource/Font;h=6e8be73a12fad07729f5e4a3f7c069d159ad6bfd;hb=HEAD)
which are the official ghostscript supplied versions, which debian ignores to
save about 5mb of disk space!

Let me postpone this for a moment because I found another scenario that
exercises the case in question, with NO CONTRIVANCE from me.

That would be the Solaris 11 installation at gcc211.fsffrance.org.

https://cfarm.tetaneutral.net/machines/list/

Ghostscript is present, but no fonts are found, and "gs -h" reports a bunch of
directories in which the font files we seek plainly are not present.

> > It sounds now like I actually did manage to do so with my brutal "let the
symlinks dangle" technique.
> I'm afraid not, you managed to have a restricted base-14 gropdf, because
although you had ghostscript its fonts had been hidden by you.

Well, maybe.  My contrived Debian-based simulation might have been faulty,
though I am not yet convinced, but the Solaris 11 case is certainly valid,
barring some rogue act of maladministration by whoever has superuser rights on
the machine.  I consider the latter unlikely.

> > And moreover the tree as of commit
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=206dcc0806b4da9d9d197540f4fa3aa86274d28b
did in fact produce the outcome from this scenario (and the other 3 states of
urw, gs bits) that you anticipated.
> See above

Again, I think this conclusion must be held in abeyance due to Solaris 11.

> > What was not clear to me at all was that you did not intend for "urw
absent, gs present" to be a supported scenario.  (If grubbing through "gs -h"
output discovers URW fonts, or finding them in any other way succeeds, it
doesn't fall within this configuration.)  Meaning that we expect the automated
test suite to fail in that case, and succeed in the other three.
> This is your incorrect assumption (that I don't expect scenario 01 to be
supported). It always has been and always works, apart from if you do
something which would stop ghostscript from working, by replacing the fonts
ghostscript needs with dangles! Even that is supported, but the check will
fail and you have a restricted gropdf, but that is still support.

I am prepared to build an older version of groff on Solaris 11 if necessary to
explore this claim.
 
> The two tests should never fail in scenarios 01 10 11, and we agreed no test
necessary for 00.
> > Somehow that criterion didn't percolate into my brain through the ~38
previous comments to the bug.
> I would change whatever brand of coffee you are drinking since there is a
lot of bad steam in your percolating. (It's not a herbal blend, is it?)

It's a brand called "deadline pressure".  I prefer to work without it.

> > I guess I did not say outright that I am only trying to explore the space
of supported groff configurations, which is plenty large enough.  The space of
unsupported configurations is not interesting to me except insofar as points
in it arise in practice often enough to require documentation for our users.
> The space of supported configurations is everything,

Certainly not.  grep the m4/groff.m4 file for AC_MSG_ERROR.  We fail hard in
every one of those cases and refuse to even attempt to build groff.

> if you run make you will have a working -T pdf, gropdf will be in one of
three modes.
> > I will therefore revert the commit currently at HEAD.  Can I then regard
this issue as resolved?  Will you join me in leaving what hairs remain on our
scalps intact?  ;-)
> Thank you, I have run a ghostscript only test and the
check-default-foundry.sh test ran and passed, all fonts correctly embedded in
the groff_man_pages book. Beautiful. Please can you attempt a ghostscript only
run with my instructions above, using the official ghostscript font versions,
undoing debian's fudge, and report back.

I'm glad you're happy.  I will return momentarily with a typescript of a
Solaris 11 build, a test failure report, and some shell commands exploring the
Ghostscript installation.

> I'm sure my wife will find alternative ways to foster follicle depillation,
so you can stand down.

A romantic partner is like a slug of good whiskey!


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63808>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/