Re: Doubts about a typo fix

[Paul Eggert <eggert@xxxxxxxxxxx>]

[taking tz@xxxxxxxx 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.

Attachment: Screenshot from 2022-11-26 12-18-53.png
Description: PNG image