Re: How groff should locate AFM files for gropdf (was: build system: devpdf/download regression)

[Deri]

On Sunday, 17 July 2022 05:34:27 BST G. Branden Robinson wrote:
> Hi Deri,



> At 2022-07-16T15:56:28+0100, Deri wrote:
> > My understanding is that the selection of paths to search is appended
> > to the value of the --with-urw-fonts-dir config variable (if any).
> 
> Yes.  To make it clear for mailing list readers, that's determined by
> font/devpdf/Foundry.in, which currently looks like this.
> 
> $ grep ^foundry font/devpdf/Foundry.in
> foundry||@urwfontsdir@:(gs):/usr/share/fonts/type1/gsfonts:/usr/share/fonts/
> default/Type1:/usr/share/fonts/default/Type1/adobestd35:/usr/share/fonts/typ
> e1/urw-base35:/opt/local/share/fonts/urw-fonts:/usr/local/share/fonts/ghosts
> cript
> foundry|U|@urwfontsdir@:/usr/share/fonts/type1/gsfonts:/usr/share/fonts/def
> ault/Type1:/usr/share/fonts/default/Type1/adobestd35:/usr/share/fonts/type1/
> urw-base35:/opt/local/share/fonts/urw-fonts:/usr/local/share/fonts/ghostscri
> pt:(gs)
> > Then the sed in the configure script parses the string of paths as it
> > does now.
> 
> This logic is in an Autoconf macro we define called
> `GROFF_URW_FONTS_CHECK`.  I'll append its present definition from Git
> HEAD to the end of this mail.
> 
> In detail, right now, _if_ both awk and ghostscript are available, the
> search path scraped from the output of "gs -h".  Even if it is not
> available, this search path is suffixed with a static list of
> directories and finally with the ./configure'd --with-urw-fonts-dir
> argument, if any.
> 
> This search path is used to look for a single representative URW font
> which has gone by a variety of names (URW Gothic Book, a free clone of
> Adobe Arial roman).  At present, we assume that this is a valid and
> reliable indicator of the presence of all base 35 URW fonts.
> 
> The are currently a few problems: (1) this Autoconf macro (a.k.a.
> configure check) is not run if either of the 'awk' or 'gs' commands is
> not available.  This is a change I made, but it is too strict.  We only
> use awk to parse the output of 'gs -h' if 'gs' is available, but we
> would still have the static paths and, if used, the ./configure'd
> --with-urw-fonts-dir argument, if any.

Hi Branden,

Let's define the different paths which may be present:-

UserPath(s) : given by --with-urw-fonts-dir
StaticPaths : a string of paths commonly used to store URW fonts (maintained by 
us).
GSPaths     : scraped from gs -h

There are two variables: gotgs and goturw, both of which start as false. If gs 
is available scrape the paths and look for the common font names, if found set 
gotgs. Now repeat search using UserPaths and StaticPaths concatenated together. 
If found set goturw.

After this the resultant message is:-

If (goturw)
   "Both the standard glyphs and the extended glyphs in the URW foundry can be 
built"
else
   if (gotgs)
      "Only standard glyphs are available, no extended glyphs available. If you 
have the URW fonts installed please rerun configure including the path by 
specifying --with-urw-fonts-dir"
   else
      "Only the base fonts will be available. If you have the URW fonts 
installed please rerun configure including the path by specifying 
--with-urw-fonts-dir"

The only failure is missing awk, but I suspect this is a more serious failure 
affecting more of the build than just looking for fonts!

After the test set @urwfontsdir@ to the value of your concatenated UserPaths 
and StaticPaths, do not include GSPaths in this.

> 
> Problem (2) is that the search order used by the Autoconf macro is
> inconsistent with Foundry.in above.  We can see that Foundry.in's
> ordering is
> 
> (user-configured-urw-fonts-dir):(gs -h search path):(static list),
> 
> but GROFF_URW_FONTS_CHECK's is
> 
> (gs -h search path):(static list):(user-configured-urw-fonts-dir).
> 
> The order being inconsistent _might_ not matter, since the only thing
> it's used for at configuration time is to decide the issue of whether
> _any_ font metrics are avilable.  But I'm starting to have doubts,
> because Arial roman (groff: 'AR') is _not_ one of the base 14 Type 1
> fonts, an important factor you note below.  What do you think?

I think you are correct, it is not a problem. The URW fonts and the ghostscript 
fonts are always delivered as a bundle of 35 fonts so you only need to find one 
of the bundle to be fairly sure you have found all. If for some reason they are 
not all present, BuildFoundries will squawk appropriately at any which are 
missing.

The search order in BuildFoundries is different for the default foundry and the 
U-foundry. For the default foundry I prefer to the ghostscript fonts, since it 
is more likely to match the output produced by grops->ghostscript, although if 
the ghostscript fonts are not found the URW fonts are close enough. For the U- 
foundry I want to use the URW fonts if possible since afmtodit will be run to 
produce perfect fit troff fonts, it is very unlikely the ghostscript fonts will 
be any use for the U-foundry due to the lack of afm files.

> I suggest that a third problem, which Ingo raised if I recall correctly,
> is (3) that we're hard-coding these "static paths" in two places,
> violating the Don't Repeat Yourself principle.  We're already
> inconsistent enough between these two files!  I propose instead to move
> this list of hard-coded directory names to a standalone file in the
> source tree.  This list can then be interpolated into a temporary shell
> variable in GROFF_URW_FONTS_CHECK to conduct the search, and also
> interpolated into the Foundry file generated during the build from
> `Foundry.in`.  I'd replace the static list in the latter file with
> the string "(static_list)" or similar, and have `BuildFoundries.pl`
> perform the same substitution when generating `Foundry`.

Is this a problem? I don't think a separate file is needed to satisfy Ingo's no 
duplication rule. Currently the config variable which holds the URW fonts 
directory is passed to Foundry.in, and the StaticPaths are embedded in the 
configure script. If the StaticPaths are concatenated onto the UserPaths then 
when it is passed to Foundry.in those StaticPaths only exist in one place, the 
configure script, and the duplication can be removed from Foundry.in file.

> > When Foundry file is built the @urwfontsdir@ is replaced by the string
> > formed in the configure script. You can use ":" as the path separator
> > since both sed and BuildFoundries currently use that character as a
> > separator, it is only when parsing the ghostscript supplied paths that
> > the O/S dependent @PATH_SEPARATOR@is used.
> 
> That makes sense.
> 
> > If this is done, all the static paths in the Foundry file can be
> > removed leaving just the @urwfontsdir@ and (gs) entries.
> 
> Okay--I question this, though.  If we do that, then people without
> Ghostscript installed will _have_ to ./configure --with-urw-fonts-dir to
> have any chance of locating the URW fonts for gropdf operation.

No, because the StaticPaths have been concatenated to the UserPaths, so when 
Foundry file is built from Foundry.in the @urwfontsdir@ will be replaced by 
both types of path.

> But maybe that's okay?
> 
> > I don't think ghostscript releases the afm files any more, just the
> > fonts, which is sufficient to provide the default foundry but cannot
> > be used to generate the extended glyphs for the "U" foundry. If the
> > ghostscript fonts are not found, or has the fonts in %rom%, (and no
> > URW fonts either) you end up with build warnings and a degraded devpdf
> > capable of using the base 14 fonts but not embedding anything. These
> > are the three possible outcomes when BuildFoundries is run with an
> > empty download file:-
> > 
> > ┌──────────┬─────────────────────────────┬───────────────────┬───────────┐
> > │          │ Ghostscript missing (%rom%) │ Ghostscript found │ URW found │
> > ├──────────┼─────────────────────────────┼───────────────────┼───────────┤
> > │Base 14   │              ✓              │                   │           │
> > ├──────────┼─────────────────────────────┼───────────────────┼───────────┤
> > │Base 35   │                             │         ✓         │     ✓     │
> > ├──────────┼─────────────────────────────┼───────────────────┼───────────┤
> > │U Foundry │                             │                   │     ✓     │
> > └──────────┴─────────────────────────────┴───────────────────┴───────────┘
> 
> Understood.
> 
> > So, BuildFoundries never fails,
> 
> The wrinkle here is that I have changed it so it _can_ fail, if it is
> run with the `--strict` option, which I also do when it is run as part
> of the groff build.  Right now, the only circumstance under which I make
> the script fail is when the AFM file for a devps font description can't
> be found.  Though I had planned to make _all_ warnings fatal!  Having
> second thoughts.
> 
> It now sounds like that change was incorrect, because it prevents
> support for the scenario in the upper-left hand corner of your table.
> As you say, even there are no AFM files present, gropdf can still
> produce valid PDF output if the document limits itself to the base 14
> fonts and the user doesn't request embedding of all fonts (the `-e`
> flag).  This will be common enough, for instance to render any groff man
> page except those for grops(1) and gropdf(1), and probably countless
> other man pages that don't perform stunt font selections.
> 
> Further, the automated test I just added
> 
> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=ca0c6eb84bdcf08b518f4
> c70318f84fb91b863c8
> 
> requires all 35 PostScript fonts to have their description files copied
> over to gropdf's device/font description directory (plus 'EURO', a font
> we supply).  But if I understand you, in the no-Ghostscript or
> Ghostscript-only-reports-%rom% scenario, this test will spuriously fail.
> gropdf will be limited but it would still work for the base 14 fonts as
> discussed above.

In the degraded case, where gropdf only has the base 14 fonts to work with, 
only the 14 troff fonts are copied from grops. This is valid.

> While I have your attention, I'd like to confirm for my own mental
> health that it's _not_ necessary to copy over the SS (slanted symbol)
> and ZDR (Zapf Dingbats Reversed) grops font descriptions.  groff has not
> been doing this, and I assume that it's not necessary--that PDF has
> primitives to mirror glyphs about the vertical axis and slant them if
> necessary.  Is that correct?

In the gropdf man page you will see:-

   \X'pdf: xrev'
       This  toggles a flag which reverses the direction of printing letter by
       letter, i.e., each separate letter is reversed, not  the  entire  word.
       This  is  useful  for reversing the direction of glyphs in the Dingbats
       font.  To return to normal printing repeat the command again.

And in pdf.tmac you would see:-

.char \[lh] \X'pdf: xrev'\[rh]\X'pdf: xrev'

In the pdf version of groff_char.7 you will see the left hand text marker shown.

I must admit I've never looked at SS. I don't think I could do it the same way 
as xrev, fiddling with the transform matrix, because slanting a glyph may 
increase its width and groff would have no way of knowing this change, so inter 
character spacing would be wrong. Simplest is to treat it the same as FreeEuro, 
i.e. grab the font and pfa from ../devps and add entry to download file.

> > it generates whatever it can. If the configure script can detect the
> > ghostscript fonts separately from the urw fonts then the appropriate
> > message can be output.
> 
> Okay.  I need to think about what we should communicate to the user in
> this case.  It sounds like we might need (urp) yet another `_NOTICE`
> Autoconf macro, this one warning the user of the above "only base 14
> fonts, no embedding" scenario.

See the three outcomes above.

> What should happen if Ghostscript is useless (is not installed or
> returns only "%rom%") but the user supplies --with-urw-fonts-dir?

See table above, all hunky dory.
 
> Thank you for your help in thinking through these issues.

Cheers 

Deri

> Regards,
> Branden
> 
> # Check availability of URW fonts in the search path given by 'gs -h'
> # supplemented with the paths where font/devpdf/Foundry.in expects them,
> # or in the custom directory passed to 'configure'.
> 
> 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/ \
>       /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/"
>     if test -n "$urwfontsdir"
>     then
>       _list_paths="$ _list_paths $urwfontsdir"
>     fi
>     for k in $_list_paths
>     do
>       for _font_file in \
>         URWGothic-Book.t1 \
>         URWGothic-Book.pfb \
>         URWGothicL-Book.pfb \
>         a010013l.pfb
>       do
>         if test -f $k/$_font_file
>         then
>           AC_MSG_RESULT([found in $k])
>           groff_have_urw_fonts=yes
>           break 2
>         fi
>       done
>     done
>     if test $groff_have_urw_fonts = no
>     then
>       AC_MSG_RESULT([none found])
>     fi
>   fi
>   AC_SUBST([groff_have_urw_fonts])
> ])