Re: [ms] Add a standard glyph name for hooked o instead of relying on .AM?

[G. Branden Robinson]

At 2020-12-14T19:07:06+0000, Dorai Sitaram via wrote:
> s.tmac defines a bunch of strings to display extra glyphs if the user
> calls the .AM macro.  Most of these glyphs are already available with
> standard glyph names, and, as far as I can tell, the only new glyph
> defined is the hooked o, (equivalent to Latin small letter o with
> ogonek).  Both a string \*q and an escape sequence \[hooko] are
> defined.

The history is not completely clear to me, but I believe these "improved
accent marks" and the .AM macro are for compatibility with a feature
added to ms by Berkeley[1].  However it does not appear that they were
ever merged into "official" ms as part of the Documenter's Workbench
(DWB)[2].

> Is there any reason why the \[hooko] definition can't be
> moved outside of .AM, preferably with the more standard (RFC1354) name
> that looks like a winking pig, i.e.,  \(o;  ?  
>
> (For comparison, .AM defines \*3, but the corresponding escape
> sequence \[yogh] is defined outside of .AM.)

There is no reason the character definition for "hooko" _can't_ be moved
outside of .AM.  The question is whether it is wise do so, or even to
retain \[yogh].  These special characters are defined only within the ms
macro package (hence my update of the subject of this thread).

I recall Werner Lemberg being skeptical that there was any use in
continuing to expand the list of special characters recognized by groff
in general--that is, those documented in groff_char(7)[3].  With
Unicode-style escapes and character composition groff has access to the
full Unicode repertoire, which is immense.  It would be a maintenance
burden to maintain our own glyph names for the ever-growing set of
defined Unicode code points.

Probably the best thing is for document authors (except of man(7) and
mdoc(7) documents) to come up with mnemonics that make sense to them for
the subset of Unicode characters of use and to define special characters
or strings to interpolate them.

The standard macro packages, like ms, fall between these two stools.  My
personal inclination would be not only to not move "hooko" outside of
ms's .AM, but to get rid of "yogh" as well; it is not necessary for
compatibility with Berkeley ms since Berkeley ms could not have
recognized a special character name of that length.

At the same time, an rfc1345.tmac file might be a useful thing to have,
and if all it does is define strings and/or special characters, it could
be sourced by users of almost any macro package, not just ms.  However,
such a file would need to be contributed, as I don't have the cycles to
construct one myself at present.

My advice would thus be to ignore both .AM and the original AT&T ms
accent mark feature and define strings and/or special characters in
terms of Unicode special character escapes as you need them on a
per-document basis, in the expectation that the formatter will be groff.
If you need portability to formatters other than groff (like Heirloom
Doctools troff), then you won't be able to use \[yogh] or \[hooko]
anyway--it doesn't recognize these special character escapes.

However, I am very far from the world's premier ms document author and
there are people on this list who can doubtless share better-informed
opinions.

What do people think?

[1] https://www.hactrn.net/ietf/rfcgen/textms.html
[2] https://github.com/n-t-roff/DWB3.3/tree/master/macros/ms
[3] https://man7.org/linux/man-pages/man7/groff_char.7.html

signature.asc
Description: PGP signature