[taking t...@iana.org off the cc as this isn't particularly time zone
relevant any more]
On 2022-11-25 19:52, G. Branden Robinson wrote:
If I prepare the following document:
$ cat EXPERIMENTS/minus-and-hyphen.man
.TH foo 1 2022-11-25 "groff test suite"
.SH Name
foo \- frobnicate a bar
.SH Description
Copy and paste me: foo\-bar-baz.
and render it with "groff -Tpdf -man" using either groff 1.22.4 or groff
Git, then when I copy-and-paste "foo-bar." from the document to a shell
prompt,...
behavior I'm familiar with. I find the minus sign and hyphen glyphs
fairly distinguishable. I modified my example file above to switch to
the CR font. Attaching (cropped, 7.7KiB) screenshot.
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. 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.
>> If we did that, Groff would set a source string like "\*-\*-help" as
>> "−−help", with two instances of U+2212 MINUS SIGN instead of U+002D
>> HYPHEN-MINUS. Therefore people couldn't cut and paste code examples
>> out of HTML or PDF, and into the shell.
>
> This hasn't been true for PDFs produced by groff for about 10
> years.[1][2] You can copy a U+2212 minus sign and it will paste as a
> U+002D.
Ah, I guess my problem is that I was using ps2pdf, i.e.:
groff samp.1 >samp.ps
ps2pdf samp.ps samp.pdf
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....
Anyway, when I run "groff -Tpdf samp.1 >samp-better.pdf", cut and paste
now works as expected, which is good.
>> For the
>> latter I test with /usr/bin/nroff and /usr/bin/troff on Solaris 10,
>> which is the oldest troff I know that is still supported.
>
> 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.
