Hi Paul!
At 2022-11-26T13:01:58-0800, Paul Eggert wrote:
> [taking tz@xxxxxxxx off the cc as this isn't particularly time zone
> relevant any more]
Fair point.
> With the same input (that is, with the last line being "Copy and paste
> me: \f(CRfoo\-bar-baz\fP." and the same commands on Ubuntu 22.10, I
> get the attached, where the symbols are unfortunately
> indistinguishable visually.
I see what you mean and, yes, that is awful. If I had to bet, I'd wager
that they really are rendering as the same glyph, possibly because
someone is remapping - to \- in man pages. Many bad decisions like this
have been taken by people who have to deal with enraged man page readers
at terminals who never, ever use groff for real typesetting. Both
audiences can be served but some care is required.
If someone has an Ubuntu 22.10 shell account they could offer me for a
brief period, I'd be happy to look around to see if I can root-cause it.
> If I instead use -P-e as Deri suggested, then I see this:
>
> $ groff -Tpdf -P-e -man minus-and-hyphen.man >t-e.pdf
> Failed to open
> '/usr/share/ghostscript/9.55.0/Resource/Font/NimbusRoman-Regular'
>
> so I'm in font-installation purgatory. I have Ubuntu's gsfonts package
> installed, but there is no file
> /usr/share/ghostscript/9.55.0/Resource/Font/NimbusRoman-Regular; instead
> there's a file
> /usr/share/ghostscript/9.56.1/Resource/Font/NimbusRoman-Regular. Presumably
> this is a configuration screwup on the Ubuntu side, as
> /usr/share/groff/1.22.4/font/devpdf/download is full of references to
> /usr/share/ghostscript/9.55.0/ but has no references to 9.56.1 which is what
> is installed.
>
> I assume this is an Ubuntu bug? Should someone file a bug report? At
> any rate it's not a good situation.
No indeed it is not. This is a recurring, painful gap with
groff-as-packaged-by-distributors.[1] Basically, something like a
"package trigger" is required to regenerate the "download" file that
gropdf uses to tell it where to find font files for embedding, not when
groff is upgraded, but when _gsfont_ (or whatever is providing the Type
1 PostScript fonts from the URW foundry) is upgraded. groff doesn't
install a tool to help with this, though there is one called
BuildFoundries in our source tree, and even if we did, distributors
would need to add the requisite trigger(s) to packages that _aren't_
groff.
Deri has been leaning on me to make BuildFoundries a real tool that we
ship but I think there's more work to do than I can squeeze in before
Debian bookworm freezes, and that's my calendar target. Among other
issues that need to be dealt with is the _disappearance_ of the URW
fonts. That is, if someone has both groff and gsfonts installed, then
removes gsfonts, the the gropdf command should react
intelligently/helpfully the next time it is run (perhaps warning that
fonts can't be embedded). There's no reason to force groff to depend on
gsfonts, not for gropdf's sake, and certainly not otherwise. Some
distributors segregate gropdf into a "groff-perl" package because that
program is written in Perl.
A lot of the pieces are in place to make this work (Deri and I have
wrangled over gropdf's diagnostic messages in this very area, but I
think we reached consensus :D ), but it needs integration testing under
multiple scenarios.
> Ah, I guess my problem is that I was using ps2pdf, i.e.:
>
> groff samp.1 >samp.ps
> ps2pdf samp.ps samp.pdf
Ah, whoops.
> So I suppose I should use 'groff -Tpdf' (which I had forgotten about)
> rather than groff + ps2pdf. Presumably others make the same mistake I
> do, though....
Yes. I'm not sure where the best place for this cautionary note is.
Not in gropdf(1), because the people who most need to know this won't
ever think to look there. grops(1) seems appropriate but since most
people don't run that command directly that also seems insufficient. A
brief warning in groff(1) similar to the one we have regarding
grotty(1), SGR escape sequences, and pagers as well might do the trick.
Deri, can you help me come up with a list of things that will break when
running ps2pdf over a PostScript document? PDFs produced that way will
have no CMap. What will happen to PS documents that use the SS or ZDR
fonts? Will anything to do with paper format or orientation be
affected?
> Anyway, when I run "groff -Tpdf samp.1 >samp-better.pdf", cut and
> paste now works as expected, which is good.
Excellent!
> > I'm curious to know what that support looks like. Is there evidence
> > of any _development_?
>
> At this point it's just Solaris bug fixes, mostly security. The latest
> patches installed on our department's Solaris 10 server are dated four
> weeks ago (patches to libz). None of this affects traditional troff;
> /usr/bin/troff is dated 2005.
I believe Solaris troff to be fossilized, and given the barriers present
to contribution to Illumos, on top the unsexiness of *roff compared to,
say, ZFS, I don't expect much more motion from theirs.
Ah well. We can't solve everything.
Regards,
Branden
[1] I could do the trendy thing here and bash on distributors as evil,
useless wastes of space, then show the world what a genius I am by
inventing npm and having a left-pad problem. No thanks.
Attachment:
signature.asc
Description: PGP signature
