[net.text] New 4.2bsd .AM accents fail with EQN and TBL strings

idallen@watmath.UUCP (04/06/85)

Here's at least one reason why the 4.2bsd .AM accents fail.  It's severe
enough to make the accents virtually useless.

The typical accent definition (simplified) looks like this:

    .\" The acute accent \*'
    .ds ' \\ka\h'-\\n(.wu'\'\h'|\\nau'

and is used:

    alle\*' au magazin

The definition marks the current horizontal place in register "a",
moves backward by the width of the last printed character, puts out the
accent, then moves back to the marked place.  This works fine, until
the accent appears in a string definition, such as used by TBL or EQN:

    .ds 34 "alle\*' au magazin

or in a macro argument, such as used by IP or XP:

    .IP "alle\*' au magazin"

Count the number of backslashes on the number registers in the accent
string definition, and you'll realize that the number registers are
interpolated as soon as the string is expanded; thus, they are
interpolated during the *copy* of the accent string or the reading of
the macro argument.  The actual content of the macro argument or string
34 shows the prematurely interpolated registers:

    alle\ka\h'-11u'\'\h'|22u' au magazin

where 11 and 22 are the (hypothetical) values of \n(.w and \na,
respectively, *at the time of the copy*.  But \n(.w is set by the
previous *output* character, not by the previous character *copied*.
So the value interpolated by \n(.w during the copy is whatever
character happened to be output last -- the value is not related to the
width of the character preceding the accent.  And \k does not execute
during a string copy, so the value of \na is not set either -- it is
whatever value happens to be in \na, and is also unrelated to the
actual horizontal position of the accented character.  In practice, the
value in \na is usually set by the \k from the *previous* accent -- so
you find massive jumps in horizontal position after each accent because
the wrong value has been interpolated.

The accents work in plain text (no pre-processors), because in plain
text the accent is never expanded until the text is actually put into
an output line -- the accent is never copied and the \k really sets \na
and the value in \n(.w really is the width of the character preceding
the accent.  The moment copying is done, the number registers expand
too soon.  One can't add extra backslashes to the number registers,
since the number to add is dependent on the number of times the accent
string is copied from one place to another or passed as a macro
argument.  One might pick a different escape character, but that would
foul up all subsequent escapes.  There is no general solution, except
to avoid using this kind of accent definition except in plain text.
-- 
        -IAN!  (Ian! D. Allen)      University of Waterloo