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