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

[G. Branden Robinson]

Update of bug #63808 (project groff):

                  Status:               Need Info => In Progress            

    _______________________________________________________

Follow-up Comment #18:

Hi Deri,

Thank you very much--I think I may want to put much of this into a text file
in the gropdf source directory.

[comment #17 comment #17:]
> To be clear the major problem occurs when configure is run and it finds the
URW fonts but not ghostscript, a minor problem is the check tests.

Acknowledged.
 
> First some definitions:-
> 
> Standard gropdf
> 
> This is when only the default foundry is populated with the 35 postscript
fonts. This will occur if only ghostscript is available. PDF documentation
will be complete. The font test should look for all the 35 fonts, error if any
are missing.

Okay.  But also, the "-e" option will be nonfunctional because gropdf won't
know where the Ghostscript fonts are located.  (Even if located, they may not
be in a format embeddable in PDF; I assume this is the reason gropdf does not
need the configure script to look for them.)  If I am correct then I will want
to notify about this at configuration time.  Probably by updating the message
that is already thrown when the URW fonts are unavailable.

Okay.  I think of this as "scenario 01" (binary).  urw absent, gs present.

> Enhanced gropdf
> 
> Both the default and the U- foundry are populated. This will occur if the
URW fonts are available. PDF documentation will be complete. In addition to
the font test for standard gropdf also check for the same 35 but starting with
U-.

Acknowledged.  I think of this as "scenario 11".  urw present, gs present.  No
configuration notice should occur here.

> Restricted gropdf
> 
> Only the base-14 fonts are available in the default foundry, there is no U-
foundry. This will occur if neither ghostscript nor URW fonts are found. PDF
documentation (if run will be "restricted", see below.

Acknowledged.  I think of this as "scenario 00".  urw absent, gs absent.  I
already (as of recently) have a configuration notice for this.

Embedding will be impossible and the typeface lists in the grops(1) and
gropdf(1) man pages in groff-man-pages.pdf should degrade.

> It is not worth doing any font checks, the base-14 fonts are always
populated by BuildFoundries.

Quite reasonable.
 
Before we move on to restricted PDF documentation, you will notice that one
case is not discussed above, the one which was of interest to you earlier.  I
would call it "scenario 10": urw present, gs absent.  

Is this a variant of scenario "11"?  Should I in fact collapse scenarios 10
and 11 into scenario "1x"?  Equivalently, if the URW fonts are available, is
the value of the gs bit "don't care"?

This would mean that the presence of URW fonts is a sufficient condition to
configure gropdf in "Enhanced" mode.

I suspect that there need be no configuration notice thrown for either
scenario, but that they have slightly different consequences for testing; see
below.  (This may be the point you have been trying to get me to understand
since comment #0.)

> Restricted PDF documentation
> 
> This is documentation produced if only the base-14 fonts are available. You
will notice warnings from throff about not finding particular fonts,

Yes, I saw these in "scenario 00".
 
> and warning from gropdf about not being able to embed fonts (if gropdf has
been called with -P-e). A "valid" pdf will be produced (i.e. it can be opened
with a viewer), but the fonts used in the pdf will be sub-optimal! When fonts
can't be selected by troff it continues with the previous valid font. I'm not
sure if this is "good enough" for the pdf documentation - your call.

I don't know of any problems in the generated documentation apart from the
typeface "degradation" (maybe "fallback" would be a better word) I have spoken
of in this and my previous (somewhat muddled) comments.

So I am inclined to let the build throw warnings if a user builds groff in
this very stripped-down host environment.
  
> Confusion over basic-fonts-present.sh
> 
> This used to check all the fonts in the default foundry were present - good.
It could be used for the Standard Gropdf test. Then in comment #9 you received
a number of missing fonts for a ghostscript only run and the check failed.
This is absolutely correct, for a ghostscript only run all the default foundry
fonts should be present, good the check worked. Why did you then change the
code to make it pass the test, rather than investigate why you ended up with a
restricted gropdf when a standard gropdf should be expected. The check, as it
currently stands,  is meaningless, the result of running BuildFoundries will
always produce at least the base-14 fonts, which is what you are now checking,
it can never fail, so is a bit pointless. If you can reproduce this results -
a restricted gropdf after a run with ghostscript available - please post the
configure and run logs. If you can't please can basic-fonts-present.sh be
returned to its former glory.

Given your presentation, I agree that the test should be restored to looking
for all 35 names (I'll even "generously" retain the change to a a static list
per comment #10).  Another important criterion will be to _not_ run the test
at all in "scenario 00" (your "restricted gropdf").  Restricted gropdf can't
fail to find PDF font files, but also can't embed them.

I think I also want to rename the "basic" fonts test to
"check-default-foundry".  My reasoning to date has been to run it only if gs
is present.  But I begin to see that it is worth running this test even when
urw is also present, because the Foundry file is constructed differently. 
That is, as far as I know, the only difference between the two "Enhanced
gropdf" configuration scenarios.

In fact, given my confusion in comment #2, I think I want to rename _both_
tests.

check-default-foundry.sh
check-u-foundry.sh

I will proceed as described above but please follow-up as you are able.


    _______________________________________________________

Reply to this item at:

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

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