[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Denis M. Wilson
Subject: Re: [ms] Add a standard glyph name for hooked o instead of relying on .AM?
Date: Mon, 4 Jan 2021 15:06:36 +0000

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

It is available as \N'188' in the symbol font or as \[u2026].


On Mon, 4 Jan 2021 05:20:26 +0000 (UTC)
Dorai Sitaram via <> wrote:

>  Enclosed is my draft for   does.tmac.
> --d
>      On Sunday, January 3, 2021, 09:27:06 PM EST, Dorai Sitaram via
> <> 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
> <> 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]
> [2]
> [3]    


reply via email to

[Prev in Thread] Current Thread [Next in Thread]