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.