[tz] Doubts about a typo fix

G. Branden Robinson g.branden.robinson at gmail.com
Wed Nov 23 21:40:19 UTC 2022


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.
-------------- 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/20221123/0fc88db1/signature-0001.asc>


More information about the tz mailing list