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: G. Branden Robinson
Subject: Re: [ms] Add a standard glyph name for hooked o instead of relying on .AM?
Date: Thu, 14 Jan 2021 16:31:50 +1100
User-agent: NeoMutt/20180716

First of all, let me say thanks to Dorai for quickly coming up with
rfc1345.tmac!

It needs a Free Software license put on it.  I can write a unit test for
it and fix up the man page, those aren't big problems.  It would be nice
to get it into groff 1.23.0, about which I am now getting anxious
because Debian is entering a release freeze on 12 February.

Colin, are you around?  People sure did get quiet over the holidays.

At 2021-01-13T04:20:09-0600, Dave Kemper wrote:
> 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.

I have no argument against your reasoning.  The main reason this isn't
being done is because no one is working on it (to my knowledge).  I
don't know where to look in the code for the kerning logic, though I
have some educated guesses.

> 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.)

This is a good point.  I think the best thing to do in the short run is
accept Dorai's contribution and warn of this limitation in the man page,
assuming the larger kerning issue isn't resolved in time for 1.23.0.

Regards,
Branden

Attachment: signature.asc
Description: PGP signature


reply via email to

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