Re: [groff] 14/15: [font/devpdf]: Revise path component separation.

[G. Branden Robinson]

Hi Deri!

At 2022-06-05T00:14:38+0100, Deri wrote:
> On Friday, 3 June 2022 10:04:52 BST G. Branden Robinson wrote:
> > commit afa7128d7b939ca5c8cd082f2547f42e4e563674
> > Author: G. Branden Robinson <g.branden.robinson@gmail.com>
> > AuthorDate: Fri Jun 3 03:02:52 2022 -0500
> > 
> >     [font/devpdf]: Revise path component separation.
> > 
> >     * font/devpdf/devpdf.am (font/devpdf/util/BuildFoundries): Generate
> >       script using the `PATH_SEPARATOR` Automake macro.
> > 
> >     * font/devpdf/util/BuildFoundries.pl: Add `pathsep` scalar to house the
> >       build-time path separator.
> > 
> >       (LocateFile): Use it.
> > 
> >       (LoadFoundry, CheckFoundry): Stop using spaces as part of the path
> >       separation delimiter.  It is not idiomatic.
> > 
> >     Also add editor aid comment and correct inconsistent indentation.
> 
> This may cause a problem. If you do a gs -h you will notice that the
> search paths use the space- colon to delimit paths.

Oh, bother.  I didn't notice that.  But I see it now.

Ghostscript really is a universe unto itself isn't it?[1] :-/

> So by changing the separator to just colon some paths include a
> leading or trailing space.

Here, let me double-check this.  It didn't seem to break on my system.

For me, "gs -h" says this.

Search path:
   /usr/share/ghostscript/9.53.3/Resource/Init :
   /usr/share/ghostscript/9.53.3/lib :
   /usr/share/ghostscript/9.53.3/Resource/Font :
   /usr/share/ghostscript/fonts : /var/lib/ghostscript/fonts :
   /usr/share/cups/fonts : /usr/share/ghostscript/fonts :
   /usr/local/lib/ghostscript/fonts : /usr/share/fonts

...and a font/devpdf/download file generated by groff Git HEAD produces
a file like this:

# foundry       ps-name psfile

        AvantGarde-Book 
/usr/share/ghostscript/9.53.3/Resource/Font/URWGothic-Book
        AvantGarde-BookOblique  
/usr/share/ghostscript/9.53.3/Resource/Font/URWGothic-BookOblique
[snip]
U       URWPalladioL-Ital       
/usr/share/ghostscript/9.53.3/Resource/Font/P052-Italic
U       URWPalladioL-Roma       
/usr/share/ghostscript/9.53.3/Resource/Font/P052-Roman

The file names seem legit.

$ file /usr/share/ghostscript/9.53.3/Resource/Font/URWGothic-Book
/usr/share/ghostscript/9.53.3/Resource/Font/URWGothic-Book: symbolic link to 
../../../../fonts/type1/urw-base35/URWGothic-Book.t1
$ file /usr/share/ghostscript/9.53.3/Resource/Font/P052-Roman
/usr/share/ghostscript/9.53.3/Resource/Font/P052-Roman: symbolic link to 
../../../../fonts/type1/urw-base35/P052-Roman.t1

Checking the generated doc/groff-man-pages.pdf file, pdffonts[2] says
the fonts are actually embedded.

$ pdffonts ./build/doc/groff-man-pages.pdf
name                                 type              encoding         emb sub 
uni object ID
------------------------------------ ----------------- ---------------- --- --- 
--- ---------
AvantGarde-Demi                      Type 1            Custom           yes no  
yes    165  0
Symbol                               Type 1            Custom           yes no  
no      43  0
ZapfDingbats                         Type 1            Custom           yes no  
no     545  0
AvantGarde-DemiOblique               Type 1            Custom           yes no  
yes    169  0
[yadda yadda yadda]

Do you have any further suggestions for how I can sanity-check the
generated "download" file?

> The space-colon is also used in the foundry.in file for additional
> paths, so perhaps changes are required here as well.

If "(gs)" is supposed to get replaced with the "gs -h" search path, I
have bad news.

These lines in Foundry.in:
foundry||(gs)
foundry|U|(gs):@urwfontsdir@:/usr/share/fonts/type1/gsfonts:/opt/local/share/fonts/urw-fonts

end up looking like this in font/devpdf/Foundry.

foundry||(gs)
foundry|U|(gs): :/usr/share/fonts/type1/gsfonts 
:/opt/local/share/fonts/urw-fonts # the URW fonts delivered with ghostscript 
(may be different)

The news gets worse.  The generated Foundry file I'm quoting is from my
system's groff 1.22.4 installation.  (The Git HEAD version differs only
in placing the comment differently, and lacking the spaces before the
colons, both changes I made deliberately.)

In other words, if my assuption about "(gs)" handling is correct, this
substitution has been broken for years.

Can you shed some light on whether my assumption is right?

I can only guess we haven't heard more complaints because this approach
only supports Type 1 fonts and we already support most of the Type 1
fonts people are interested in.

> I'm also not sure if using PATH_SEPARATOR is proper here, did you
> check whether gs -h uses alternative separators on other operating
> systems? Also, shouldn't foundry.in have some fiddling as well?

This is another sticky wicket.

We need to generate "Foundry" and "download" files for the build system
so that we can run gropdf at build time to produce artifacts like
groff-man-pages.pdf (a pretty new thing), automake.pdf, and several
examples for mom(7).

However, when cross-compiling, the _host_ system is not the _build_
system by definition.  So if someone is trying to cross-compile groff
for a Windows host on a GNU/Linux build machine (an eminently reasonable
thing to do since, yuck, who would want to develop software on
Windows?), _if we were to ship_ the BuildFoundries script, it would use
the wrong path separator character.

I assume this is why our Makefile.am has this.[3]

[[
#`RT_SEP' is the operating system's native PATH SEPARATOR CHAR, which
#is to be used in runtime PATHs compiled into groff executables.
RT_SEP=@GROFF_PATH_SEPARATOR@

#`SH_SEP' is a alternative PATH SEPARATOR CHAR, to be used in shell
#scripts and makefile rules; it may be the same as `RT_SEP', but,
#particularly in some Microsoft environments, it may differ.
SH_SEP=@PATH_SEPARATOR@
]]

If we want to use BuildFoundries both at build time and also to ship it,
the script is going to need to be parameterized in the path separator;
i.e., we're going to need to add a command-line option to select it.
(Well, we could trick the script out to query the runtime environment
but I think an option is simpler to implement and for everyone to
understand.)

On the gripping hand maybe this issue is void, because it seems everyone
who has ever had anything to do with groff on Windows has lost interest;
they quit replying to emails in early 2019.  My guess is that "Windows
Subsystem for Linux 2: Ubuntu Boogaloo" is responsible for this;
possibly everyone who cares to run groff on Windows just does it in this
ersatz virtual machine.

Regards,
Branden

[1] 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=75c04d5918d2e90a504736adc1623354e3bc645f

[2] ...from poppler-utils and HOLY COW is that command slow.

    $ time pdffonts ./build/doc/groff-man-pages.pdf
[...]
    real    0m18.498s
    user    0m16.797s
    sys     0m1.689s

    An entire groff Git build from bootstrap to test suite, including
    the rousing of the dread beast TeX to build groff.dvi and groff.pdf,
    takes 62 seconds on the same machine.

    _Generating_ the groff-man-pages.pdf file takes 5.7 seconds, using
    only one core.  (I assume pdffonts doesn't opportunistically
    parallelize--if it does, that's _worse_.)  I get the feeling there
    is either highly asymmetric compression or a large crack pipe
    involved.[5]

[3] I want to register yet another complaint down while I'm looking at
    this.  "RT_SEP" and "SH_SEP" are _terrible_ names for Make macros.
    No doubt someone thought that since they'd expand to something
    short, they should have short names.  That is a horrible false
    economy.  The problem is that these have a pretty fundamental
    significance to the operating environment and yet their names are
    nearly inscrutable.  Autoconf's 'PATH_SEPARATOR' is great!  It
    should be been Make-ified under the same name.
    'GROFF_PATH_SEPARATOR' is bad for a different reason.  It's
    certainly not too short but it doesn't do _anything_ to suggest why
    it exists.  The "GROFF_" prefix only tells us it's trying to stay in
    an informal name space.  The name communicates _nothing_ about why
    you'd use it instead of "PATH_SEPARATOR", which is already
    available.  "RT", presumably an abbreviation of "runtime" is a step
    in the right direction, but its Thompson-channeling militant brevity
    discards the advantage it could have claimed.  Often, "RT" in Unix
    parlance means "real time", not just in the Wagnerian story of
    replacement schedulers for the Linux kernel, but way, way back.[4]

[4] https://en.wikipedia.org/wiki/Multi-Environment_Real-Time
[5] https://savannah.gnu.org/bugs/?58206

signature.asc
Description: PGP signature