[Groff] Tweaking font metrics

[Ted Harding]

Hi Folks,

[Longish post -- sorry]

I'd like to air something that I have been pondering for
a while. In principle it could become quite a broad issue,
but I'm not clear in my mind how to define that broader
context, so I'll illustrate the question with a couple
of special cases (and use devps and font TR as the basis).

1. Introducing/modifying kern pairs.

The font files (e.g. devps/TR) list kernpairs. Thus, for
instance, we find

  W - -65

meaning that if "W" is followed by "-" then the "-" will
be shifted left by 65 units (65/1000 points) in 10-point
printing. However, one might prefer it to be different,
e.g. -70 (or whatever), for aesthetic reasons.

Also, there are no kern-pairs involving "en" (the en-dash,
groff name \[en]), "em" (the em-dash \[em]) or "/".

But I often want to kern these, so use the .char request
to define, for instance,

  .char \[En] \^\[en]
  .char \[eN] \[en]\^
  .char \[EN] \^\[en]\^

which gives much better appearance in sequences such as

  991\[en]1000
  900\(En]1000
  800\[EN]900

or

  .char \[Em] \^\[em]
  .char \[eM] \[em]\^
  .char \[EM] \^\[em]\^

for similar reasons. The case of "/" is more complicated,
because it divides its surrounding space obliquely, good
appearance is quite sensitive to spacing, yet no one size
fits all cases. In fact, in documents where I'm prepared to
be bothered about this, I define a parametrised string
\*[w/] ("wide /"):

  .ds w/ \Z'\h'\w'0'u-\w'/'u/2u+(\\$1p)'/'\0

which prints a "/" shifted by \\$1p (signed: + for right)
relative to the centre of a digit-width space. This does
(in my personal view) improve the appearance of things
like

  the ESRC\*[w/ 0]JISC Census
[centred looks OK in this case]

  The Guy's\*[w/ 1]Age Concern Survey
[shifted right 1p because of the right-slope of the "A"]

  MPhil Epidemiology\*[w/ -1.5]Diploma in Public Health
[shifted left 1.5p for similar reasons]

  1\*[w/ 0.5]11

[(i.e. page 11 of 11): contrary to expectation, this does
not look right with 1\*[w/ 0]11 because of the serifs!]


*** Now for the groff issue connected with this. There is
(I think) no provision to include in s groff document a
specification of additional kern-pairs which may arise
in the course of the document: you are limited to what are
set out in the font file (e.g. devps/TR). So: would it be
useful to have a new request, say ".kp" (kern pairs) like

  .kp TR 9 en -916   en 9 -916   ...

(i.e. it is specified that when \[en] follows 9 in font TR
it is shifted right by 916u (the width of "\^", etc.)

In other words, 

  .kp Font c1 d1 n1  c2 d2 n2 ...

would extend the kern-pair table for font Font by the lines

  c1 d1 n1
  c2 n2 d2
  ...


2. Modifying font metrics/Introducing new characters.

The particular context in which I've encountered a need for
this is when wanting to "pico-justify" so that inserted
hyphens (when a word is broken at the end of a line) can
protrude a little beyond the end of the line. Thus, if
there were a character in the font named \[h0] (zero-length
hyphen) which printed like \[hy] but was treated as having
zero length, then

  .shc \[h0]

would have the effect that the hyphen at the end of a hyphenated
line would protrude be the full length of \[hy].

However, the rules for the request .shc prevent you from
introducing a new character \[h0] by means of

  .char \[h0] \Z'\[hy]'

or (for less protrusion)

  .char \[h0] \Z'\[hy]'\h'\w'\[hy]'u/2u'

since .shc only works for a character which is in the current
font, and not one findable in a special font or defined by
.char or .tr!

So the only way to introduce such a character would be to add
a line like h0 below:

   -       333,257,0,0,-39 0       0055    -- hyphen
   hy      "
   h0      111,257,0,0,-39 0       0055    -- hyphen

in the "charset" section of the font file. This would have all
the properties of \[hy] except that it would be considered to
have length 1/3 of the length of \[hy].

However, re-writing all one's font files is not something
one wants to do! A request .chsl ("charset line") like

  .chsl Font h0 111,257,0,0,-39 0 0055 -- hyphen

which had an effect as if its arguments had been read in as a
charset line when the fonts file (e.g. devps/TR) for font Font
was first read, would give the user this facility without having
to edit the font files.

As well as an application like "protruding hyphen", one may have
a printer which has its own idea of font metrics, slightly
different from groff's.

In most cases, I've worked round issues like the latter by
having a conditional section of ".char" definitions which
are used when a certain printer is used, so the ".chsl" idea
may not add anything useful for this kind of application.

But I can;t see any other work-round for the "protruding hyphen"
problem!


Well, you can see the sort of thing I have in mind. I'm raising
it as a discussion point, aiming at the question "Would it be
useful to have extensions of this kind to the groff requests?"

Best wishes to all,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 094 0861
Date: 22-Oct-06                                       Time: 18:27:30
------------------------------ XFMail ------------------------------