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

[Dorai Sitaram]

 Careful diff'ing reveals that in addition to the \[,.] for horizontal 
ellipsis, the only digraphs that Vim has over and above RFC 1345 are those for 
the currency symbols for euro and rouble. That RFC 1345 (written in 1992) 
missed the euro is understandable, as the latter clinked into existence in 
1999, but the rouble...?

I've added these into the latest https://gitlab.com/ds26gte/groff1345

--d



     On Monday, January 4, 2021, 10:43:53 PM EST, Dorai Sitaram via 
<groff@gnu.org> wrote:  
 
  To avoid emailing updated versions of rfc1345.tmac, I've created a temporary 
Git repo 

 https://gitlab.com/ds26gte/groff1345

I've added \[,.] from Vim. If I find any more Vim digraphs that aren't already 
covered by RFC 1345, I'll add them in due course.


--d





    On Monday, January 4, 2021, 03:12:42 PM EST, Dorai Sitaram via 
<groff@gnu.org> wrote:  
 
  Indeed it doesn't. (TBH, I've never warmed to the single-character ellipsis 
as it seems too narrow in most fonts.)

I notice Vim's digraph system (which is based on RFC 1345) uses the digraph ,. 
(comma-followed-by-period) for U+2026 HORIZONTAL ELLIPSIS. 

Vim's digraphs are pretty standard too, and stable, although they've of course 
changed more recently than RFC 1345. Perhaps we want the union of Vim's 
digraphs and RFC 1345 for our rfc1345.tmac, with one of them (maybe Vim) 
calling shotgun when there's a clash? (To be kept in mind is that Vim's 
digraphs are by definition two-character. Groff glyph names have no such 
restriction.) 

--d    On Monday, January 4, 2021, 10:06:40 AM EST, Denis M. Wilson 
<dmw@oxytropis.plus.com> wrote:  
 
 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.robinson@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   


--