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

[G. Branden Robinson]

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

[comment #37 comment #37:]
> > Here's what I need to know.
> 
> > A) Is it even valid to try to test gropdf with 'gs' available but "no URW
fonts"?  You explained in comment #7 that URW fonts were donated to
Ghostscript.  That they might be forked or separately maintained in variant
forms is not strongly relevant, except for the file name and directory changes
that have proven otherwise frustrating.
> 
> Definitely. Although in debian the fonts associated with ghostscript are the
same files as you would get if you installed the URW fonts as a separate
package without ghostscript, in other linux distros such as the one I use,
they are different versions. You can just install ghostscript and the fonts
are available, without the relevent afm files, no symlinks. So anyone using a
distro like mine who installs ghostscript (common) will be able to have
standard gropdf. On your system (debian) if ghostscript is installed you will
always get extended gropdf, so I understand your question, but we have to
cater for distros which don't follow the debian way.

I agree.  That leads to the question I didn't ask quite clearly...
 
> Version could be relevant if glyph coverage is different.

(Quite so.)
 
> > B) If it is, what does that test scenario look like?
> 
> As in comment #3, but I will update it to current nomenclature.
> 
> if gs or urw
>     run check-default-foundry.sh
>     if urw
>         run check-urw-foundry.sh
>     end
> end
> 
> In both cases you are looking for the 35 groff fonts, and additionally EURO
in the default foundry. If any are not found then the test fails.

Then you are saying "urw absent, gs present" is _not_ a supported groff
configuration scenario.

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?"

It sounds now like I actually did manage to do so with my brutal "let the
symlinks dangle" technique.

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.

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.

Somehow that criterion didn't percolate into my brain through the ~38 previous
comments to the bug.

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.

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?  ;-)


    _______________________________________________________

Reply to this item at:

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

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