GNU eqn clarifications and reforms (was: EQN - special words)

[G. Branden Robinson]

At 2023-05-31T12:34:10+1000, Damian McGuckin wrote:
> On Tue, 30 May 2023, G. Branden Robinson wrote:
> 
> > "sin" through "det" get a spacing type of "operator" applied to
> > them, whereas the last three get no type at all.
> > 
> > The man page doesn't quite get around to documenting this, but it
> > appears that eqn tokens with type "operator" get a thin space placed
> > to their left.
> 
> Thanks.
> 
> I assume that thin space is the '^' token.

For groff 1.22.4 and earlier, this is basically true, but Doug requested
that we separate the "thin space", which is in GNU eqn terms an amount
of spacing used in automatic adjustments, from the '^' token.  I have
implemented this (with a complementary separation for the "thick_space"
and '~') in my private branch for merge to master after we release
1.23.0.

This is the subject of <https://savannah.gnu.org/bugs/?64216>.

Right now in Git HEAD, eqn(1) documents the "thin space" as follows.

    set p n
        assigns parameter p the integer value n; n is interpreted in
        units of hundredths of an em unless otherwise stated.  For
        example,

            set x_height 45

        says that eqn should assume that the font's x-height is
        0.45 ems.

        Available parameters are as follows; defaults are shown in
        parentheses.  We intend these descriptions to be expository
        rather than rigorous.
[...]
        thin_space       This amount of space is automatically inserted
                         after punctuation characters.  It also
                         configures the width of the space produced by
                         the ^ token (17).

> On the man page, is
> 
>       >=
> or
>       <=
> 
> a relation.  They are in a mathematical sense , just list == and ~=
> but not in src/preproc/eqn/lex.cpp

This is also documented better in groff Git HEAD's eqn(1).

    Equation components include mathematical variables, constants,
    numeric literals, and operators.  eqn remaps some input character
    sequences for economy in equation entry and to ensure that glyphs
    from an unstyled font are used; see groff_char(7).

        +   \[pl]                '    \[fm]
        -   \[mi]                <=   \[<=]
        =   \[eq]                >=   \[>=]
[...]
    eqn sets up spacings and styles as if by the following commands.

        chartype "letter"      abcdefghiklmnopqrstuvwxyz
        chartype "letter"      ABCDEFGHIKLMNOPQRSTUVWXYZ
        chartype "letter"      \[*a]\[*b]\[*g]\[*d]\[*e]\[*z]
        chartype "letter"      \[*y]\[*h]\[*i]\[*k]\[*l]\[*m]
        chartype "letter"      \[*n]\[*c]\[*o]\[*p]\[*r]\[*s]
        chartype "letter"      \[*t]\[*u]\[*f]\[*x]\[*q]\[*w]
        chartype "binary"      *\[pl]\[mi]
        chartype "relation"    <>\[eq]\[<=]\[>=]
        chartype "opening"     {([
        chartype "closing"     })]
        chartype "punctuation" ,;:.
        chartype "suppress"    ^~

Regarding "~=", I will note that the special character \[~=] itself is
_not_ treated specially by GNU eqn--its spacing type is therefore
"ordinary" and its style type effectively "digit"[1].  However, the
predefined macro "approx", which produces this special character, _does_
have the "relation" type.

Quoting src/preproc/eqn/lex.cpp:

static struct builtin_def common_defs[] = {
  { "ALPHA", "\\(*A" },
[...]
  { "approx", "type \"relation\" \"\\(~=\"" },
[...]
};

I have yet another reformatory proposal to make about this list.[2]

> And what the man page calls a relation is a relational operator or a
> more precisely a relational predicate but that is overly strict
> mathematically for a man page.

Agreed; the current language,

      relation      relation such as "="

...could really use improvement here.  I'll fix that...

...and, having done that in my working copy, I'm attaching fresh
versions of eqn(1) in source and PDF (with embedded fonts this time).

Regards,
Branden

[1] I propose to reorganize automatic style typing in GNU eqn.  Instead
    of "letter" and "digit", the former meaning "set in italics" and the
    latter meaning nothing,[3] I think it might be better if we had
    style types named "normal", "slanted", and "heavy" instead.  These
    would more obviously couple to typeface styles and also expose a
    means to define a style type that automatically boldfaced its
    members, a property that would cohere nicely with GNU eqn's
    long-standing "gbfont" feature.

[2] It feels a lot cleaner to me to stop imputing the style type
    "letter" to directly to the *roff special characters \(*a, \(*b,
    etc., and instead to assign this type _as part of the macro
    definitions that eqn users employ for inputting them anyway_.

    So instead of

  { "alpha", "\\(*a" },
  { "beta", "\\(*b" },
[...]

    in that same array of structs above, we'd have

  { "alpha", "type \"letter\" \"\\(*a\"" },
  { "beta", "type \"letter\" \"\\(*b\"" },
[...]

    instead.  This is the subject of
    <https://savannah.gnu.org/bugs/?64232>.

[3] 
https://git.savannah.gnu.org/cgit/groff.git/tree/src/preproc/eqn/text.cpp?h=1.23.0.rc4#n460

    Lines 460-497 constitute the entirety of this "digit" feature.  As
    one can see, it is sparse.

eqn.1
Description: Text document

eqn.1.pdf
Description: Adobe PDF document

signature.asc
Description: PGP signature