[tz] [PATCH v2 3/4] zic.8: Use correct escape sequences instead of special characters

[G. Branden Robinson]

Hi Paul,

At 2022-11-25T18:31:02-0800, Paul Eggert wrote:
> On 2022-11-23 10:43, Paul Eggert wrote:
> > I installed that
> Further testing showed that the installed patch doesn't work with
> traditional troff, which doesn't support groff escape sequences like \(aq.
> To fix this I installed the equivalent of the attached further patch to
> TZDB.

My apologies.  I've gotten _really_ used to groff, Heirloom Doctools
troff, and even a bit to mandoc, all of which define special characters
for the various quotation marks that are available (aq, dq, oq, cq, lq,
dq).

There is a hazard here but I hasten to note that the \(aq and \(dq
special characters are not groffisms.  There is more than one
traditional troff out there.

My checkout of DWB (Documenter's Workbench) 3.3 troff defines 'aq' and
'dq' special characters for "devpcl", "devLatin1", "devpost",
"devnroff", and "devnroff-12" devices.[1]

And _any_ descendant of Kernighan's device-independent troff should be
able to define these by simply adding lines like

aq "

dq "

...after whichever "real" character provides the corresponding glyph (or
near approximation) in each font description file.

However, Solaris troff didn't do this, at least not in Solaris 10,[2]
and I confess to some doubt whether it ever will.

It may also be futile to expect any administrator of a proprietary Unix
system to undertake this effort themselves, even if it is a small one.

AT&T troff didn't have a way to directly test for the existence of a
special character, and two indirect approaches I tried to determine this
information failed.[3]

Maybe this is why James Clark added the '.if c' feature to groff over 30
years ago.  But a lot of people have decided they'll just be damned if
they borrow even good ideas...

Regretfully yours,
Branden

[1] https://github.com/n-t-roff/DWB3.3
[2] https://github.com/n-t-roff/Solaris10-ditroff.git
[3] Taking Heirloom Doctools as a proxy for DWB/Kernighan troff,
    measuring the width of a nonexistent special character fails; it
    returns the width of a space, which might coincidentally be the
    same.  Using the formatted output comparison operator [e.g., '.if
    "foo"bar"'] doesn't work either; a nonexistent glyph doesn't compare
    equal to a space nor to an empty string, and it doesn't produce a
    'c' command in device-independent output so I'm not much the wiser
    as to what its internal representation is.
-------------- 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/1402205b/signature-0001.asc>