[tz] Doubts about a typo fix

[G. Branden Robinson]

Hi Paul,

At 2022-11-25T18:18:46-0800, Paul Eggert wrote:
> Thanks for the info about groff. You're right, tzdb man pages are
> supposed to be portable to both groff and traditional troff. 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_?

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

> "\f(CW-\fP" is used instead of plain "-" because when the output is
> PDF, it is more clearly visible to humans as a hyphen-minus instead of
> as a hyphen (U+2010 HYPHEN).

Okay.  It's a shame that's necessary.

> > Most people won't see a difference because groff 1.22.4 (and earlier
> > releases going back to, I think, 2009) the man(7) macro package remaps
> > the hyphen to the minus sign on the 'utf8' output device.
> 
> I noticed the abovementioned problem with PDF output, and I still see
> it with groff 1.22.4.

Some distributors do violence to the man.local file.  But I am not a PDF
expert; for this I'll have to turn as I often do to Deri James, who also
wrote the gropdf output driver.  Deri, what's a good way to root-cause
the issue Paul describes?

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, I get this:

$ echo foo-bar-baz. | od -c
0000000   f   o   o   -   b   a   r   -   b   a   z   .  \n
0000015

> I see a different issue with groff 1.22.4 on Ubuntu 22.10: I cannot
> easily see the difference between "\f(CR-\fP" and "\f(CR\-\fP" on
> output to PDF. If I cut from the output PDF and paste into Emacs or
> the terminal, the former is indeed U+002D and the latter U+2202 and
> the difference is readily visible in Emacs or the terminal;

That's odd.  This definitely is not consistent with the groff 1.22.4
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.

> but it's not readily visible in the PDF. However, this glitch is not a
> serious issue for man pages since examples always contain
> hyphen-minuses not minus signs, so I didn't worry about it. I assume
> that it's yet another font thing, since the problem doesn't occur in
> the default Roman font.

Possibly; when fonts aren't embedded in the PDF, we're at the mercy of
whatever the renderer supplies.  groff 1.23 will be shipping a 380-page
compilation of all its man pages in PDF, and it embeds the fonts; I am
hopeful that this will provide a reliable basis for comparisons so that
we can better track down issues like the ones above.

Regards,
Branden

[1] Commit: https://git.savannah.gnu.org/cgit/groff.git/commit/?id=4536678ce5713907304ad1695e907f6888c44aa3
[2] One explanation: https://lists.gnu.org/archive/html/groff/2018-05/msg00076.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minus-and-hyphen-courier-roman.png
Type: image/png
Size: 7851 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/tz/attachments/20221125/db4fa61d/minus-and-hyphen-courier-roman-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/tz/attachments/20221125/db4fa61d/signature-0001.asc>