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

[Deri James]

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

> 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

>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?
> 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!
> 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.
> 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
> 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.

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?)
> 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, 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 sure my wife will find alternative ways to foster follicle depillation, so
you can stand down.


    _______________________________________________________

Reply to this item at:

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

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