Re: build system: devpdf/download regression

[Deri]

On Wednesday, 22 June 2022 22:29:29 BST G. Branden Robinson wrote:
> Hi Deri,
> 
> At 2022-06-22T21:30:25+0100, Deri wrote:
> > I think I have sussed what might be happening. In the port build the
> > standard fonts get built because of the addition of
> > /usr/local/share/fonts/ghostscript to the Foundry file yesterday. None
> > of the U fonts get built because this make rule deletes half the
> > foundry file before BuildFoundries is run:-
> > 
> > font/devpdf/Foundry: $(devpdf_srcdir)/Foundry.in
> > 
> >     $(AM_V_at)$(MKDIR_P) $(top_builddir)/font/devpdf/
> > 
> > if HAVE_URW_FONTS
> > 
> >     $(AM_V_GEN)sed "s|[@]urwfontsdir[@]|$(urwfontsdir)|" \
> >     
> >       $(devpdf_srcdir)/Foundry.in >$@
> > 
> > else
> > 
> >     $(AM_V_GEN)sed "/BEGIN URW/,/END URW/d" \
> >     
> >       $(devpdf_srcdir)/Foundry.in >$@
> > 
> > endif
> 
> Whoops.  This sed-foolery was me, not very long ago.[1]

There are two separate reasons why gropdf needs either the URW fonts supplied 
(or not - %rom%) with ghostscript, or as a separate package of fonts. First it 
needs the fonts which are part of the postscript base fonts but not part of 
the pdf base fonts, this is for the default fonts. It also needs the fonts 
(and afm files) to run afmtodit and create the U- fonts. On a system which has 
neither the ghostscript nor the packaged version of the fonts, you would end 
up with 19 default fonts and no U- fonts, plus a lot of "noise" in the build 
about missing font files, but gropdf would still be "useable" but only with 
the 19 base fonts, and not able to give gropdf the -e flag to embed the fonts.

So this piece of sed-omy is useful in reducing some of the build noise if 
there are really no URW fonts. In this case it was confusing because configure 
decided it could not find the fonts but BuildFoundries did (you can tell 
because all the default fonts were created Ok including the ones not part of 
the base set). So the problem is not this sed but the fact that configure does 
not perform the check if ghostscript is set to missing. I can even see why 
this happened, originally only the ghostscript versions were looked for, but I 
pointed out that BuildFoundries also looked in places for the stand alone URW 
fonts, so these paths were added, unfortunately after the condition of finding 
ghostscript.

> > So if HAVE_URW_FONTS is not set when configure is run the U- fonts
> > will not be created. When configure is run the part which is meant to
> > check for the presence of the URW fonts, starts with:-
> > 
> >   groff_have_urw_fonts=no
> >   if test "$AWK" != missing && test "$GHOSTSCRIPT" != missing
> >   then
> 
> This logic is much older, and went out with groff 1.22.4.

I think this logic is still there, I was quoting from the actual configure 
script but Ingo identified the real culprit - groff.m4. His patch is to add 
more static paths to be searched to bring it into line with the paths in 
Foundry.in. This is the code in groff.m4:-

AC_DEFUN([GROFF_URW_FONTS_CHECK], [
  AC_REQUIRE([GROFF_AWK_PATH])
  AC_REQUIRE([GROFF_GHOSTSCRIPT_PATH])
  groff_have_urw_fonts=no
  if test "$AWK" != missing && test "$GHOSTSCRIPT" != missing
  then
    AC_MSG_CHECKING([for URW fonts in Type 1/PFB format])
    _list_paths=`$GHOSTSCRIPT -h | $AWK 'BEGIN { found = 0 } /Search path:/ { 
found = 1 } /^[ ]*\// { print $'0' }'| tr : ' '`
    _list_paths="$_list_paths /usr/share/fonts/type1/gsfonts/ \
      /opt/local/share/fonts/urw-fonts/"
    if test -n "$urwfontsdir"
    then
      _list_paths="$ _list_paths $urwfontsdir"
    fi

You can see the logic to skip this configure test completely if ghostscript or 
awk are missing.

> > So it does not even do the tests if ghostscript is set to missing,
> > which I believe is the case with the port version. So even if you
> > supply the URW fonts directory to configure this directory is not
> > tested and HAVE_URW_FONTS remains false. If ghostscript is missing it
> > should just not run gs -h as part of collecting paths to search, but
> > still do the search on the remaining paths.
> 
> "it" meaning the BuildFoundries script?

No, sorry, I was trying to point out it was the configure script (groff.m4) 
which requires a bit of work. Unfortunately, I have only ever been driven on 
the M4, never used it

> > > Those files below http://schwarze.bsd.lv/tmp/urw/
> > > of which i did not upload new versions did not change.
> > > 
> > > > So you shouldn't need the --with-urw-fonts-dir flag any more.
> > > 
> > > To make things work without --with-urw-fonts-dir, i need the
> > > additional patch shown below.  Otherwise, ./configure won't
> > > find them, and BuildFoundries comes too late to fix that.
> > > Do you think i should commit and push that additional patch?
> > 
> > I think the tests for awk and ghostscript need to just apply to the
> > line which uses those programs, not the whole section, but the patch
> > is good.
> 
> I'm happy to change GROFF_URW_FONTS_CHECK in this manner, but I'll hold
> off until you or Ingo pushes his patch.
> 
> Can you confirm that the "sed-foolery" should stay, if we improve our
> search for the URW fonts in the first place?

Yes, it's  fine, reduces some noise if the fonts are not found.

> > > It's hardly ideal to have this path written out verbatim at two
> > > independent places: we just experienced how it *will* get out of
> > > sync.  But let's improve one thing at a time.
> > 
> > I did add a --check flag to the BuildFoundries program, which checked
> > for all the required fonts and returned an exit status, but I hadn't
> > really thought it through, a bit of chicken and egg situation! I
> > suspect a new file containing possible paths which BuildFoundries
> > accesses, or the configure test pulls the paths from Foundry.in rather
> > than having them hard coded.
> 
> This seems like an easy improvement as well--another piece of oddball
> data we can keep in font/devpdf.

I would suggest I add a new parameter to Foundry.in:-

static_paths|/usr/share/fonts/type1/gsfonts /usr/share/fonts/default/Type1 /
usr/share/fonts/default/Type1/adobestd35 /usr/share/fonts/type1/urw-base35 /
opt/local/share/fonts/urw-fonts /usr/local/share/fonts/ghostscript

Then the groff.m4 check can pull the paths from the file.

> > Since the fonts don't appear in any of the directories yielded by "gs
> > -h" means that the person porting ghostscript for your system decided
> > to use the option to have the fonts embedded in the gs executable
> > (%rom%) rather than as separate font files. I'm not sure if there is
> > much advantage with modern hardware. Here's a chap asking where the
> > font files have gone:-
> > 
> > https://stackoverflow.com/questions/38331893/ghostscript-fonts-folder-remo
> > ved-from-later-versions
> I wonder if we should detect this and warn about it.  I've gotten pretty
> familiar with our Autoconf macros.

I don't think so. If the URW fonts are not found the just suggesting to 
install the URW fonts is sufficient. They can't do much if their packaged 
ghostscript has the fonts baked into the executable, but they can install a 
URW fonts package or tar-ball.

Cheers

Deri

> Regards,
> Branden
> 
> [1]
> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=bf25f7ebf35c9ab38445
> 5edb1612494b4af46817