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

[G. Branden Robinson]

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


[comment #19 comment #19:]
> > > 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.

Ah, right.  Somehow I keep forgetting about "gs -h" despite that fact that you
regularly ask people reporting font bugs to supply its output.

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

Understood and agreed.

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

I had utterly forgotten about this commit.

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

Ehrm, yes.  I'd like to get something like BuildFoundries into 1.24.  Just
needs documentation and (automated) testing and all that jazz... 
 
> > 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.

Cool--I'll retain that, then.

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

Yes.  "Font description files" is the term I try to consistently use in our
documentation.

> "PDF font files" could be confused with the fonts gropdf embeds.

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

Right; this error of mine was a consequence of forgetting about commit
d55157d39ab4d01bccea276122a2f3a5b1e30452 (above).

> It is the groff font files AR and U-AR which will be substantially
different.

Because the former are copied over from font/devps and the latter are
generated at build time from the URW foundry font files?

But if the URW fonts _are_ available, and the URW fonts are also used for the
default foundry if they are present (commit d5515), shouldn't they bear the
same groff font description files?

Even if that's true, they are supposed to be metrically compatible anyway so I
have no reason to suspect this is urgent to change before 1.23.0 final.

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

Great!


    _______________________________________________________

Reply to this item at:

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

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