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