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

[Deri James]

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

[comment #18 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.

I think this is the only bit where you have swerved off course! The files
found via gs -h are perfectly valid pfb files, so can be embedded by gropdf. A
download file produced with ghostscript only (your scenario 01) will contain
lines such as:-

        Bookman-Light  
/usr/share/ghostscript/9.53.3/Resource/Font/URWBookman-Light
        Bookman-LightItalic    
/usr/share/ghostscript/9.53.3/Resource/Font/URWBookman-LightItalic
        Courier
*/usr/share/ghostscript/9.53.3/Resource/Font/NimbusMonoPS-Regular
        Courier-Bold   
*/usr/share/ghostscript/9.53.3/Resource/Font/NimbusMonoPS-Bold

These are default foundry and point to valid pfb files, although not named as
such, i.e.:-

[derij@pip build (master)]$ file
/usr/share/ghostscript/9.53.3/Resource/Font/URWBookman-Light
/usr/share/ghostscript/9.53.3/Resource/Font/URWBookman-Light: PostScript Type
1 font text (URWBookman-Light 1.00)

So they can be embedded and no particular message is required for this
scenario, although the missing URW message will have been output, because they
have not been found by configure.

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

Correct.

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

You are right, it is scenario 1x. Given the current contents of the file
"Foundry.in" both foundries are populated with fonts from URW, ghostscript
fonts are ignored, so it is exactly the same as scenario 10. Prior to commit
d55157d39ab4d01bccea276122a2f3a5b1e30452 only ghostscript fonts were chosen
for the default foundry, but now the URW fonts are used in preference if
available. One reason is because the naming convention of the URW fonts is
much more stable than the ghostscript fonts, the path usually includes the
ghostscript version number. We have had several instances where a previously
working gropdf fails when a new version of ghostscript is installed (and you
won't let me install BuildFoundries as a tool to run, like afmtodit, so this
was the next best thing!).

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

Yes.

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

Fine, it does not affect the usefulness of having the documents.

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

Bit muddled here. It is groff font files in the devpdf directory the checks
look for. "PDF font files" could be confused with the fonts gropdf embeds.

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

There is actually no difference in the two foundries in the download file AR
and U-AR will both point to the identical pfb file. It is the groff font files
AR and U-AR which will be substantially different.

> 
> In fact, given my confusion in comment #2, I think I want to rename _both_
tests.
> 
> check-default-foundry.sh
> check-u-foundry.sh

A good choice.

> 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/