Doubts about a typo fix

Doubts about a typo fix

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2375 bytes --]

Hi Paul,

I don't undertstand the commit shown below.  It breaks the '-' symbol, which now 
is a hyphen.  See the table mentioned yesterday:

          ┌──────────────────────────────────────────────────────────────────┐
          │Keycap   Appearance and meaning   Special character and meaning   │
          ├──────────────────────────────────────────────────────────────────┤
          │"        " neutral double quote   \[dq] neutral double quote      │
          │'        ’ closing single quote   \[aq] neutral apostrophe        │
          │-        ‐ hyphen                 \- or \[-] minus sign/Unix dash │
          │\        (escape character)       \e or \[rs] reverse solidus     │
          │^        ˆ modifier circumflex    \(ha circumflex/caret/“hat”     │
          │`        ‘ opening single quote   \(ga grave accent               │
          │~        ˜ modifier tilde         \(ti tilde                      │
          └──────────────────────────────────────────────────────────────────┘


So, at least, it should be (but I believe the initial code was correct):

.q "zic \*\-r @$(date +%s)"

However, I wonder what that \* is intending to do there (I can see no difference 
in my screen with or without it).

Cheers,

Alex

---

commit 918e10e8963b3c0d38d3b5fb8ec9cf08ecd03757
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Tue Jul 12 06:26:53 2022 -0700

     * zic.8: fix minus typo

diff --git a/zic.8 b/zic.8
index 0cd0781e..e8816e5b 100644
--- a/zic.8
+++ b/zic.8
@@ -145,7 +145,7 @@ .SH OPTIONS
  31-bit signed integers.
  On platforms with GNU
  .BR date ,
-.q "zic \-r @$(date +%s)"
+.q "zic \*-r @$(date +%s)"
  omits data intended for past timestamps.
  Although this option typically reduces the output file's size,
  the size can increase due to the need to represent the timestamp range



-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Doubts about a typo fix

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 3387 bytes --]

Hi Alex,

I'm not Paul but I think I can address this item anyway.

At 2022-11-23T20:31:22+0100, Alejandro Colomar wrote:
> I don't undertstand the commit shown below.

> @@ -145,7 +145,7 @@ .SH OPTIONS
>  31-bit signed integers.
>  On platforms with GNU
>  .BR date ,
> -.q "zic \-r @$(date +%s)"
> +.q "zic \*-r @$(date +%s)"
>  omits data intended for past timestamps.
>  Although this option typically reduces the output file's size,
>  the size can increase due to the need to represent the timestamp range

> It breaks the '-' symbol,
> which now is a hyphen.  See the table mentioned yesterday:
[...]
> So, at least, it should be (but I believe the initial code was correct):
> 
> .q "zic \*\-r @$(date +%s)"
> 
> However, I wonder what that \* is intending to do there (I can see no
> difference in my screen with or without it).

Your second point addresses your first, because the zic(8) man page does
something old-fashioned: it defines a string for the minus sign.

On my system, the page has this in a sort of prologue.

    27  .ie \n(.g \{\
    28  .  ds : \:
    29  .  ds - \f(CW-\fP
    30  .\}
    31  .el \{\
    32  .  ds :
    33  .  ds - \-
    34  .\}

You see no diagnostic--I expect you have warnings turned on--because the
page has defined a string named `-`, and the *roff input `\*-`
interpolates a string named `-`.

Strictly, this string definition should be updated to use the font's
minus sign even if the formatter is groff (the `.g` register
interpolates a true value).

  .ie \n(.g \{\
  .  ds : \:
  .  ds - \f(CW\-\fP
  .\}

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.  This will be
changing in groff 1.23 to improve consistency with man page rendering on
typesetters.[1]  Workarounds are documented.[2]

I also note that "CW" is an old, AT&T device-independent
troff-compatible font name.[3]  groff's preferred name for this face is
"CR", because for the past couple of decades a monospace font (often
Courier) has generally been available in all four styles (roman,
oblique, bold, and bold-oblique).

All of that said, I wouldn't switch to a monospace font just to render a
dash; not if groff is the formatter.

Paul is more of a battle-scarred veteran than I am, so there may be a
good reason to define this string on proprietary Unix systems--tzdata
has to be _really_ portable--but on any system using groff or Heirloom
Doctools troff, I can't think of one.[4]  mandoc maintainer Ingo
Schwarze and I both recommend against performing string definitions, or
interpolating strings, in man pages.

So I would see if it's feasible to get away with dropping the definition
and use of a `-` string altogether.  But if not, there's no _validity_
problem with what Paul has.

Regards,
Branden

[1] https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?id=23ffa46c8c951fec1d23dfe4b0dbbbe1299fa5d2#n193
[2] https://git.savannah.gnu.org/cgit/groff.git/tree/PROBLEMS?id=23ffa46c8c951fec1d23dfe4b0dbbbe1299fa5d2#n68
[3] https://github.com/n-t-roff/DWB3.3/tree/master/text/devnroff
[4] I don't know of anyone using neatroff to render man pages, but that
    may simply because I haven't seen them speak up about it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Doubts about a typo fix

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 2377 bytes --]

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.

On 2022-11-23 13:40, G. Branden Robinson wrote:

> Strictly, this string definition should be updated to use the font's
> minus sign even if the formatter is groff (the `.g` register
> interpolates a true value).
> 
>    .ie \n(.g \{\
>    .  ds : \:
>    .  ds - \f(CW\-\fP
>    .\}

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.

"\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).


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

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


> I also note that "CW" is an old, AT&T device-independent
> troff-compatible font name.[3]  groff's preferred name for this face is
> "CR", because for the past couple of decades a monospace font (often
> Courier) has generally been available in all four styles (roman,
> oblique, bold, and bold-oblique).

Thanks, I didn't know that was preferred. I installed the attached patch 
into the tzdb development repository

[-- Attachment #2: 0001-Use-CR-font-instead-of-CW.patch --]
[-- Type: text/x-patch, Size: 3381 bytes --]

From 220c21f6b4167378f463828e6921c281a85abe1f Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Fri, 25 Nov 2022 15:56:52 -0800
Subject: [PROPOSED] Use CR font instead of CW

Suggested by G Branden Robinson in:
https://mm.icann.org/pipermail/tz/2022-November/032336.html
---
 newctime.3    | 2 +-
 newstrftime.3 | 4 ++--
 newtzset.3    | 2 +-
 time2posix.3  | 2 +-
 tzfile.5      | 2 +-
 tzselect.8    | 2 +-
 zdump.8       | 6 +++---
 zic.8         | 2 +-
 8 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/newctime.3 b/newctime.3
index 2907f856..e25d841e 100644
--- a/newctime.3
+++ b/newctime.3
@@ -5,7 +5,7 @@
 asctime, ctime, difftime, gmtime, localtime, mktime \- convert date and time
 .SH SYNOPSIS
 .nf
-.ie \n(.g .ds - \f(CW-\fP
+.ie \n(.g .ds - \f(CR-\fP
 .el .ds - \-
 .B #include <time.h>
 .PP
diff --git a/newstrftime.3 b/newstrftime.3
index d68bc337..d5d8ee10 100644
--- a/newstrftime.3
+++ b/newstrftime.3
@@ -40,7 +40,7 @@
 strftime \- format date and time
 .SH SYNOPSIS
 .nf
-.ie \n(.g .ds - \f(CW-\fP
+.ie \n(.g .ds - \f(CR-\fP
 .el .ds - \-
 .B #include <time.h>
 .PP
@@ -55,7 +55,7 @@ strftime \- format date and time
 .ie '\(rq'' .ds rq \&"\"
 .el .ds rq \(rq\"
 .de c
-.ie \n(.g \f(CW\\$1\fP\\$2
+.ie \n(.g \f(CR\\$1\fP\\$2
 .el \\$1\\$2
 ..
 .de q
diff --git a/newtzset.3 b/newtzset.3
index c3742850..1e75acf0 100644
--- a/newtzset.3
+++ b/newtzset.3
@@ -5,7 +5,7 @@
 tzset \- initialize time conversion information
 .SH SYNOPSIS
 .nf
-.ie \n(.g .ds - \f(CW-\fP
+.ie \n(.g .ds - \f(CR-\fP
 .el .ds - \-
 .B #include <time.h>
 .PP
diff --git a/time2posix.3 b/time2posix.3
index e7c69206..e13c431c 100644
--- a/time2posix.3
+++ b/time2posix.3
@@ -5,7 +5,7 @@
 time2posix, posix2time \- convert seconds since the Epoch
 .SH SYNOPSIS
 .nf
-.ie \n(.g .ds - \f(CW-\fP
+.ie \n(.g .ds - \f(CR-\fP
 .el .ds - \-
 .B #include <time.h>
 .PP
diff --git a/tzfile.5 b/tzfile.5
index 9d312255..c3e86c62 100644
--- a/tzfile.5
+++ b/tzfile.5
@@ -11,7 +11,7 @@ tzfile \- timezone information
 .de q
 \\$3\*(lq\\$1\*(rq\\$2
 ..
-.ie \n(.g .ds - \f(CW-\fP
+.ie \n(.g .ds - \f(CR-\fP
 .el .ds - \-
 The timezone information files used by
 .BR tzset (3)
diff --git a/tzselect.8 b/tzselect.8
index 53a34cf6..846b867b 100644
--- a/tzselect.8
+++ b/tzselect.8
@@ -4,7 +4,7 @@
 .SH NAME
 tzselect \- select a timezone
 .SH SYNOPSIS
-.ie \n(.g .ds - \f(CW-\fP
+.ie \n(.g .ds - \f(CR-\fP
 .el .ds - \-
 .ds d " degrees
 .ds m " minutes
diff --git a/zdump.8 b/zdump.8
index 1ff92639..170e18d6 100644
--- a/zdump.8
+++ b/zdump.8
@@ -18,7 +18,7 @@ zdump \- timezone dumper
 .de q
 \\$3\*(lq\\$1\*(rq\\$2
 ..
-.ie \n(.g .ds - \f(CW-\fP
+.ie \n(.g .ds - \f(CR-\fP
 .el .ds - \-
 The
 .B zdump
@@ -151,7 +151,7 @@ Here is an example of the output, with the leading empty line omitted.
 tabbed columns line up.)
 .nf
 .sp
-.if \n(.g .ft CW
+.if \n(.g .ft CR
 .if t .in +.5i
 .if n .in +2
 .nr w \w'1896-01-13  'u+\n(.i
@@ -184,7 +184,7 @@ UT, a standard time abbreviated HST.
 Here are excerpts from another example:
 .nf
 .sp
-.if \n(.g .ft CW
+.if \n(.g .ft CR
 .if t .in +.5i
 .if n .in +2
 TZ="Europe/Astrakhan"
diff --git a/zic.8 b/zic.8
index 8b77ea12..f345f944 100644
--- a/zic.8
+++ b/zic.8
@@ -24,7 +24,7 @@ zic \- timezone compiler
 .el .ds > \(ra
 .ie \n(.g \{\
 .  ds : \:
-.  ds - \f(CW-\fP
+.  ds - \f(CR-\fP
 .\}
 .el \{\
 .  ds :
-- 
2.37.2

Re: [tz] Doubts about a typo fix

[Russ Allbery]

Paul Eggert via tz <tz@iana.org> writes:

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

[...]

> "\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).

You have to be very careful with the combination of \f(CW and \fP on
Solaris 10 nroff, and I suspect the construct you are using has nascent
bugs.  \f(CW doesn't produce a font change on Solaris 2.6 with nroff, so
if you write something like:

    \fBsomething\fP \f(CW-\fP something else

you will discover that "something else" is in bold because the second \fP
reverts to the "previous" font, which nroff thinks is \fB becuase \f(CW
was ignored.  (Just tested now on a Solaris 10 host.)  Pod::Man has fairly
elaborate workarounds for this bug.

>> I also note that "CW" is an old, AT&T device-independent
>> troff-compatible font name.[3] groff's preferred name for this face is
>> "CR", because for the past couple of decades a monospace font (often
>> Courier) has generally been available in all four styles (roman,
>> oblique, bold, and bold-oblique).

> Thanks, I didn't know that was preferred. I installed the attached patch
> into the tzdb development repository

Just be warned that \f(CR is not a valid font name in all *roff
implementations, which is why Pod::Man uses \f(CW by default.  Not sure
how much you care.  (And, to be honest, not sure how much anyone should
care about any implementations other than groff and mandoc these days.)

-- 
Russ Allbery (eagle@eyrie.org)             <https://www.eyrie.org/~eagle/>

Re: [tz] Doubts about a typo fix

[Paul Eggert]

On 2022-11-25 19:20, Russ Allbery wrote:
> You have to be very careful with the combination of \f(CW and \fP on
> Solaris 10 nroff

That should be OK, as \f(CW - which is now \f(CR - is used only if \n(.g 
is nonzero, i.e., only if it's groff and not traditional troff.

I toyed with using \f[CW] instead of \f(CW to underscore that it's 
groff-specific. However, that might be overkill given the number of 
non-*roff programs that read these files.

Re: [tz] Doubts about a typo fix

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

At 2022-11-25T19:50:14-0800, Paul Eggert wrote:
> On 2022-11-25 19:20, Russ Allbery wrote:
> > You have to be very careful with the combination of \f(CW and \fP on
> > Solaris 10 nroff
> 
> That should be OK, as \f(CW - which is now \f(CR - is used only if
> \n(.g is nonzero, i.e., only if it's groff and not traditional troff.

Just for precision's sake, the .g register interpolating a true value
means (by convention) that an implementation is claiming support for
groff extensions.

This happens with Heirloom Doctools troff, for instance, if one gives it
the "-mg" option.  (There are other ways to switch on its "groff mode".)

Also, to reiterate, "CW" as a font name is not a groff extension; it has
some history in Documenter's Workbench troff and I think it may have
appeared in Research Unix troff as well in the 1980s, but I don't have
convincing evidence of this, just educated guesses based on man(7) and
ms(7) man pages from that era.  If I had sources for Research Unix
V8-V10 I'd be a happy guy.

> I toyed with using \f[CW] instead of \f(CW to underscore that it's
> groff-specific. However, that might be overkill given the number of
> non-*roff programs that read these files.

In my opinion that's not necessary, and implies too much.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Doubts about a typo fix

[G. Branden Robinson]

[-- Attachment #1.1: Type: text/plain, Size: 3590 bytes --]

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

[-- Attachment #1.2: minus-and-hyphen-courier-roman.png --]
[-- Type: image/png, Size: 7851 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Doubts about a typo fix

[Deri]

On Saturday, 26 November 2022 03:52:53 GMT G. Branden Robinson wrote:
> 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?


Whenever there is a query about the "look" of a pdf it is important to rule 
out any vagaries in the particular fonts used by the pdf viewer used, so 
please repeat your tests adding "-P-e" to the command.

As regards the cut and paste of MINUS SIGN as a hyphen, this can be turned off 
by including -P-u as well. Note this will also affect the treatment of 
ligatures (ff/fi/ffi) in that cut and paste will not return them to their 
individual characters. It also affects string searching within the pdf, the 
troff input "\-b" would not be found by entering -b in the pdf viewer's search 
widget. Tested on Branden's minus-and-hyphen.man, with -P-u it finds -baz, 
without it finds both -bar and -baz.

Cheers 

Deri

Re: Doubts about a typo fix

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 3115 bytes --]

[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 #2: Screenshot from 2022-11-26 12-18-53.png --]
[-- Type: image/png, Size: 10928 bytes --]

Re: Doubts about a typo fix

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 5381 bytes --]

Hi Paul!

At 2022-11-26T13:01:58-0800, Paul Eggert wrote:
> [taking tz@iana.org 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Doubts about a typo fix

[Deri]

On Saturday, 26 November 2022 21:56:04 GMT G. Branden Robinson wrote:
> 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?

I think Peter has a section in the using mom for pdfs documentation.

Cheers

Deri

Re: Doubts about a typo fix

[Paul Eggert]

On 2022-11-26 13:56, G. Branden Robinson wrote:

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

In the meantime I filed an Ubuntu bug here:

https://bugs.launchpad.net/ubuntu/+source/groff/+bug/1998031

Unfortunately I don't have an Ubuntu 22.10 host that's public. The GCC 
Compile Farm has a 22.04 host; perhaps that's good enough.


> I believe Solaris troff to be fossilized

Yes and no. Solaris 10 is no longer supported after January 2024, so if 
it and all the other traditional troffs die out by 2024 we can stop 
worrying about this then.

Solaris 11.4, the only Oracle Solaris version that is planned to be 
supported after January 2024, is based on groff 1.22.3 instead of on 
traditional troff. See:

https://docs.oracle.com/cd/E88353_01/html/E37839/troff-1.html
https://www.illumos.org/issues/12692


Oh, and one more thing. And this is relevant to TZDB! Ubuntu's groff 
ignores the TZ environment variable; see:

https://bugs.launchpad.net/ubuntu/+source/groff/+bug/1908333

This is apparently due to Ubuntu's reproducible-build folks going off 
the deep end. For example, on Ubuntu 22.10:

$ echo $TZ; date; echo '\n[year]-\n[mo]-\n[dy] 
\n[hours]:\n[minutes]:\n[seconds]' | groff -Tascii | grep .

Sat Nov 26 18:30:29 PST 2022
2022-11-27 2:30:29

I hope upstream groff never does this....

Re: Doubts about a typo fix

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 4001 bytes --]

Hi Paul,

[delayed follow-up]

At 2022-11-26T18:32:09-0800, Paul Eggert wrote:
> On 2022-11-26 13:56, G. Branden Robinson wrote:
> 
> > 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.
> 
> In the meantime I filed an Ubuntu bug here:
> 
> https://bugs.launchpad.net/ubuntu/+source/groff/+bug/1998031
> 
> Unfortunately I don't have an Ubuntu 22.10 host that's public. The GCC
> Compile Farm has a 22.04 host; perhaps that's good enough.

I found some info about this and will have a look.

https://gcc.gnu.org/wiki/CompileFarm

> > I believe Solaris troff to be fossilized
> 
> Yes and no. Solaris 10 is no longer supported after January 2024, so
> if it and all the other traditional troffs die out by 2024 we can stop
> worrying about this then.

That may in fact prove out; the only _currently-maintained_ troffs I
know of are groff, Heirloom Doctools troff (though it has slowed down)
and neatroff.

> Solaris 11.4, the only Oracle Solaris version that is planned to be
> supported after January 2024, is based on groff 1.22.3 instead of on
> traditional troff. See:
> 
> https://docs.oracle.com/cd/E88353_01/html/E37839/troff-1.html
> https://www.illumos.org/issues/12692

How about that!  Be nice to get 'em moved past an 8-year-old release.  I
don't expect anyone at Oracle to care, but maybe the Illumos folks...

> Oh, and one more thing. And this is relevant to TZDB! Ubuntu's groff
> ignores the TZ environment variable; see:
> 
> https://bugs.launchpad.net/ubuntu/+source/groff/+bug/1908333
> 
> This is apparently due to Ubuntu's reproducible-build folks going off the
> deep end. For example, on Ubuntu 22.10:
> 
> $ echo $TZ; date; echo '\n[year]-\n[mo]-\n[dy]
> \n[hours]:\n[minutes]:\n[seconds]' | groff -Tascii | grep .
> 
> Sat Nov 26 18:30:29 PST 2022
> 2022-11-27 2:30:29
> 
> I hope upstream groff never does this....

Much as I have grievances with Ubuntu for many reasons--for its "BDFL"
personality cult governance structure, for starters[1]--this one can be
laid their upstream's doorstep, Debian.  With which I am affiliated.

$ echo TZ=$TZ; date; cat <<EOF | groff -Tascii | grep .
##> .af hours 00
##> .af minutes 00
##> .af seconds 00
##> .nf
##> groff \n[.x].\n[.y].\n[.Y]
##> \n[year]-\n[mo]-\n[dy] \n[hours]:\n[minutes]:\n[seconds]
##> EOF
TZ=
Tue 13 Dec 2022 01:16:19 PM CST
groff 1.22.4
2022-12-13 19:16:19

But I have good news.

$ echo TZ=$TZ; date; cat <<EOF | ./build/test-groff -Tascii | grep .
.af hours 00
.af minutes 00
.af seconds 00
.nf
groff \n[.x].\n[.y].\n[.Y]
\n[year]-\n[mo]-\n[dy] \n[hours]:\n[minutes]:\n[seconds]
EOF
TZ=
Tue 13 Dec 2022 01:23:02 PM CST
groff 1.23.0
2022-12-13 13:23:02

Speaking of NEWS, I'll quote the groff distribution's file of that name.

o The semantics of the environment variable SOURCE_DATE_EPOCH (support
  for which was added in 1.22.4) to groff were not established with
  respect to time zone selection, prompting divergent interpretations;
  Debian and distributions derived from it have for several years
  patched groff to implicitly use UTC as the time zone when interpreting
  the current time (or SOURCE_DATE_EPOCH) as a local time.  While a
  convenient and defensible choice for reproducible build efforts, it
  runs against the grain of user expectations.  Systems programmers like
  time zone-invariant, monotonically increasing clocks; the broader
  user base usually prefers a clock that follows an applicable civil
  calendar.  groff programs now reckon SOURCE_DATE_EPOCH with respect to
  the local time zone.  Users of SOURCE_DATE_EPOCH may wish to also set
  the TZ environment variable.

I hope you find this satisfactory.  Let me know.

Regards,
Branden

[1] Just like a _real_ software company!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Doubts about a typo fix

[Lennart Jablonka]

Quoth G. Branden Robinson:
>> > I believe Solaris troff to be fossilized
>>
>> Yes and no. Solaris 10 is no longer supported after January 2024, so
>> if it and all the other traditional troffs die out by 2024 we can stop
>> worrying about this then.
>
>That may in fact prove out; the only _currently-maintained_ troffs I
>know of are groff, Heirloom Doctools troff (though it has slowed down)
>and neatroff.

I am devastated that 9front troff is unhesitatingly disregarded 
again and again like this.  While it’s seeing few commits, it is 
serving us very well.

Nope, not all traditional troffs will die that easily.

Re: Doubts about a typo fix

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 4129 bytes --]

Hi Lennart,

At 2022-12-25T22:07:01+0000, Lennart Jablonka wrote:
> Quoth G. Branden Robinson:
> > > > I believe Solaris troff to be fossilized
> > > 
> > > Yes and no. Solaris 10 is no longer supported after January 2024,
> > > so if it and all the other traditional troffs die out by 2024 we
> > > can stop worrying about this then.
> > 
> > That may in fact prove out; the only _currently-maintained_ troffs I
> > know of are groff, Heirloom Doctools troff (though it has slowed
> > down) and neatroff.
> 
> I am devastated that 9front troff is unhesitatingly disregarded again
> and again like this.  While it’s seeing few commits, it is serving us
> very well.

I apologize for forgetting; I shouldn't have, as I corresponded
fruitfully with Russ Cox regarding 9front man(7)'s `MR` macro, and
submitted a patch for (rudimentary) `\~` escape sequence support in P9US
troff, which Dan Cross merged swiftly.

> Nope, not all traditional troffs will die that easily.

I have gone out of my way to document traits of Plan 9{, from User
Space} troff in groff's documentation where the discussion warrants.

ChangeLog:      origin in Plan 9 troff.  [style] Add examples of use.
ChangeLog:      and, per Ingo Schwarze, Plan 9 troff.  (It is, however, not
NEWS:  Plan 9 from User Space's troff in August 2020.  Its purpose is to
NEWS:  vary the line length freely (DWB troff, Solaris troff, Plan 9 troff)
doc/groff.texi:characters' length.  Also, Plan@tie{}9 @code{troff} allows tabs to
doc/groff.texi:@cindex @code{.S} register, Plan@tie{}9 alias for @code{.tabs}
doc/groff.texi:@cindex @code{.tabs} register, Plan@tie{}9 alias (@code{.S})
doc/groff.texi:argument to the @code{ta} request.@footnote{Plan@tie{}9 @code{troff}
doc/groff.texi:1c6ab0f6e, 2016-09-13), and Plan@tie{}9 from User Space @code{troff}
doc/groff.texi:Plan@tie{}9 @code{troff} all support it.} but valid values are specific
doc/groff.texi:files.@footnote{Plan@tie{}9 @code{troff} has also abandoned the binary
man/groff.7.man:.\" request or macro name of two characters' length.  Also, Plan@tie{}9
man/groff_diff.7.man:and Plan\~9
man/groff_diff.7.man:and Plan\~9 from User Space
man/groff_diff.7.man:.I troff \" Plan 9
man/groff_font.5.man:(Plan\~9
man/groff_font.5.man:.I troff \" Plan 9
tmac/groff_man.7.man.in:those containing space \" or tab (in Plan 9 troff [only?])
tmac/groff_man.7.man.in:or Plan\~9
tmac/groff_man.7.man.in:Plan\~9,
tmac/groff_man.7.man.in:Plan\~9,
tmac/groff_man.7.man.in:Plan\~9,
tmac/groff_man.7.man.in:Plan\~9 from User Space's
tmac/groff_man.7.man.in:.BR \(rs(rg , \" Heirloom Doctools, mandoc, neatmkfn, Plan 9, Solaris
tmac/groff_man.7.man.in:.BR \(rs(lq , \" Heirloom Doctools, mandoc, neatmkfn, Plan 9
tmac/groff_man.7.man.in:.BR \(rs(rq , \" Heirloom Doctools, mandoc, neatmkfn, Plan 9
tmac/groff_man.7.man.in:.B \(rs(tm \" Heirloom Doctools, mandoc, neatmkfn, Plan 9
tmac/groff_man.7.man.in:but not by Plan\~9,
tmac/groff_man.7.man.in:.IR troff s. \" Plan 9, Solaris, DWB
tmac/groff_man.7.man.in:Plan\~9 from User Space
tmac/groff_man.7.man.in:.I troff \" Plan 9
tmac/groff_man.7.man.in:like Plan\~9 or Solaris
tmac/groff_man.7.man.in:.IR troff , \" Plan 9, Solaris
tmac/groff_man.7.man.in:Plan\~9 from User Space's

That's from groff Git (actually my working copy).  Compare to groff
1.22.3, before I started contributing.

config.guess:    *:Plan9:*:*)
doc/groff.texinfo:spaces.@footnote{Plan@tie{}9's @code{troff} implementation also allows
doc/groff.texinfo:@cindex @code{.S} register, Plan@tie{}9 alias for @code{.tabs}
doc/groff.texinfo:@cindex @code{.tabs} register, Plan@tie{}9 alias (@code{.S})
doc/groff.texinfo:The @code{troff} version of the Plan@tie{}9 operating system uses
doc/groff.texinfo:files.@footnote{Plan@tie{}9 @code{troff} has also abandoned the binary
man/roff.man:roff tools found in the OpenSolaris and Plan\~9 operating systems, now
man/roff.man:Plan 9
man/roff.man:The Plan\~9 operating system
src/libs/gnulib/build-aux/config.guess:    *:Plan9:*:*)

I'll try not to forget again.

Live long and prosper,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Doubts about a typo fix

[Steffen Nurpmeso]

G. Branden Robinson wrote in
 <20221126035253.pli53qzgfx6tbax5@illithid>:
 |At 2022-11-25T18:18:46-0800, Paul Eggert wrote:
 ...
 |> 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.

It would be great if groff would release adjustments to grotty so
that one could again use copy+paste also in manuals.  And now
please do not beat me onto that hyphen-minus for options, and that
one should do this or that, but it is for many other characters,
too.  If i look at bash manual for example, hyphen-minus is ok,
but caret is not ^ but U+02C6 MODIFIER LETTER CIRCUMFLEX ACCENT,
and i see U+2018 LEFT SINGLE QUOTATION MARK instead of
single-quotes.  That is cool and maybe milks the shit out of the
typographic capabilities of modern UTF-8 terminal emulators (i
think i quote you here, more or less), but i always have to use
"LC_ALL=C man XY" to enable copy+paste for myself.  But hey, it is
only me, i am not a prof at an University who is prowd of dozens
of Noble price winners and other such prices, many of them still
worth something aka based upon scientific grounds.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Doubts about a typo fix

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 2932 bytes --]

[dropping Paul, Alex, and tz@iana]

At 2022-11-26T22:20:23+0100, Steffen Nurpmeso wrote:
> It would be great if groff would release adjustments to grotty so
> that one could again use copy+paste also in manuals.

One can.

> And now please do not beat me onto that hyphen-minus for options, and
> that one should do this or that, but it is for many other characters,
> too.  If i look at bash manual for example, hyphen-minus is ok, but
> caret is not ^ but U+02C6 MODIFIER LETTER CIRCUMFLEX ACCENT, and i see
> U+2018 LEFT SINGLE QUOTATION MARK instead of single-quotes.

Those mean ^ was typed when \(ha was meant, and ` was typed when \(ga
was meant.

> That is cool and maybe milks the shit out of the typographic
> capabilities of modern UTF-8 terminal emulators (i think i quote you
> here, more or less),

I don't think so.  When I milk something I emphatically do not
anticipate the production of excrement from the orifice.

I try to keep my cruder wise cracks off of mailing lists.

> but i always have to use "LC_ALL=C man XY" to enable copy+paste for
> myself.

That's not necessary.  You can employ the workaround documented in the
PROBLEMS file, as I believe I have told you before.

---snip---
* When viewing man pages, some characters on my UTF-8 terminal emulator
  look funny or copy-and-paste wrong.  Why?

Some Unicode Basic Latin ("ASCII") input characters are mapped to
non-Basic Latin code points in output for consistency with other output
devices, like PDF.  See groff_man_style(7) and groff_char(7) for correct
input conventions and background.  If you use the correct groff special
character escape sequences to input them, you will get correct output no
matter what device the input is formatted for.

However, many man pages are written in ignorance of the correct special
characters to obtain the desired glyphs.  You can conceal these errors
by adding the following to your site-local man(7) configuration.  The
file is called "man.local"; its installation directory depends on how
groff was configured when it was built.

--- start ---
.if '\*[.T]'utf8' \{\
.  char ' \[aq]
.  char - \-
.  char ^ \[ha]
.  char ` \[ga]
.  char ~ \[ti]
.\}
--- end ---

You may also wish to do the same for "mdoc.local".
---snip---

You can edit one file (or two, if you care about mdoc(7) pages), one
time, and never have to worry about typing LC_ALL=C before your man
commands again.

> But hey, it is only me, i am not a prof at an University who is prowd
> of dozens of Noble price winners and other such prices, many of them
> still worth something aka based upon scientific grounds.

I don't know who you're aiming at with this status-oriented gripe, but
it doesn't sound like me.  I am relatively unlettered person,
academically (can't you tell?).  I enjoy university classes but I'm not
good at being graded.  😅

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]