groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Doubts about a typo fix


From: Paul Eggert
Subject: Re: Doubts about a typo fix
Date: Sat, 26 Nov 2022 13:01:58 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]