converting to ditroff -- kern tables

[edmoy at ucbopal.BERKELEY.EDU]

In article <2457 at brl-tgr.ARPA> phil at RICE.ARPA (William LeFebvre) writes:
>Troff has a very stupid idea of kerning.  In fact, almost no idea.
> ...
>Personally, I think the entire idea of
>ditroff's kern tables needs to be rethought and reworked, but it will
>probably never happen.

A company in Toronto (SoftQuad, I believe) has added a fairly sophisticated
kerning scheme to ditroff.  Here at the UC Berkeley computer center, we
have a version of ditroff that does a simplier method of kerning, involving
character pairs (We are talking with CSRG about combining our version with
CSRG's and then possibly distributing it at some point).

>I also don't know of ANY utility (including
>ditroff) that uses this information!  "Eqn" certainly should.

Eqn does use this information, which it gets from the \n(ct register (which
is set when you use the \w width function).

>In fact, one of my pet peeves with the ditroff utilities "eqn" and
>"pic" is that they don't look at ANY of the fancy *.OUT tables that
>ditroff uses.  Both these utilities need to know the resolution of the
>target device -- a value easily determined by looking in the DESC.OUT
>file for the device.  But neither utility does this.  All the known
>resolutions are hard coded into the programs!

I agree this is a stupid problem in the preprocessors, and that is one
major change in our version of the preprocesors.  Ours do look in the
DESC.out file for the various information.  Our eqn even has a separate
set of tables for fine tuning the various character placements; one set
for each typesetter.

Edward Moy
Academic Computing Services
University of California
Berkeley, CA  94720

edmoy at ucbopal.Berkeley.EDU
ucbvax!ucbopal!edmoy