groff
[Top][All Lists]
Advanced

[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: Dave Kemper
Subject: Re: [ms] Add a standard glyph name for hooked o instead of relying on .AM?
Date: Wed, 13 Jan 2021 04:20:09 -0600

On 1/3/21, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
> 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.
>
> 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.

If this is the direction we're moving in, is it time to consider
fixing the not-quite-a-bug-cuz-it's-documented restriction on
characters defined with the various .*char requests?  To quote the
documentation, "Only the current font is checked for ligatures and
kerns; neither special fonts nor entities defined with the 'char'
request (and its siblings) are taken into account."
(http://savannah.gnu.org/bugs/?58930#comment9 shows a real-world
consequence of this limitation.)

This seems the wrong default.  If kerning were done by default for
.char-defined characters, users who want to disable kerning before or
after such a character could easily do so with \&.  But instead we
have the situation where such kerning is inactive by default, and
there is really no way to tell groff to turn it on.

So with the situation the way it currently is, introducing a host of
.char-defined characters, as proposed here, will also introduce a
spate of subpar typography.  (Certainly not every character defined in
the proposed rfc1345.tmac will have a kernpair in every font, but I
expect the most commonly used characters from this file will be the
variously accented Latin letters, which are likeliest to be part of a
font-defined kernpair.)



reply via email to

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