rfc1345 does not have a base-line ellipsis, a character frequently used in English writing. I've also found it surprising that it is not in groff either considering groff was originally written by a British person.
It is available as \N'188' in the symbol font or as \[u2026]. Denis On Mon, 4 Jan 2021 05:20:26 +0000 (UTC) Dorai Sitaram via <groff@gnu.org> wrote: > Enclosed is my draft for does.tmac. > > > --d > > On Sunday, January 3, 2021, 09:27:06 PM EST, Dorai Sitaram via > <groff@gnu.org> wrote: > I'll be happy to write up an rfc1345.tmac and send it to you. I > don't think it requires a tremendous amount of maintenance, as the > list of mnemonics appears not to have changed since June 1992. > > > --d > > On Sunday, January 3, 2021, 08:16:12 AM EST, G. Branden Robinson > <g.branden.robin...@gmail.com> wrote: > 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 --
