[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: thin_space causes collateral damage in eqn
From: |
G. Branden Robinson |
Subject: |
Re: thin_space causes collateral damage in eqn |
Date: |
Wed, 17 May 2023 00:52:49 -0500 |
First of all, I predictably forgot my attachment of the retypeset AT&T
eqn user's guide. So let me fix that.
At 2023-05-17T15:17:55+1000, Damian McGuckin wrote:
> I would agree with Doug 100%
Confidence...increasing...
> > Another parameter, thick_space, has the same effect on ~.
>
> There is also 'medium space' but it corresponds to nothing explicit or
> deliberate as far as can see.
Huh!
> The documentation says that *_space are only for automatic spacing.
...but automatic spacing applies to anything that has a "type" in GNU
eqn jargon, so this is consistent with Doug's observation. In other
words, with its application to ^ and ~ tokens being a bug.
> I actually cannot see where the meaning of either '~' or '^' is
> defined in the GNU eqn(1) manual page.
They aren't. Practically no AT&T eqn features are.
> But maybe my eyes are getting old. Or I should consider Branden's
> comment and take that as a delta against some implied expert's
> understanding of EQN. Sadly I am not an expert yet because I am still
> learning things about EQN after 40 years.
I'll be a happy guy if I can complete the GNU eqn man page, then--it
sounds like it will do a lot of groff users some good. At least the
ones that care about typesetting math.
> I note that the Plan 9 eqn(1) man page says
>
> "Tokens within eqn are separated by spaces, tabs, newlines,
> braces, double quotes, tildes or circumflexes. Braces {} are
> used for grouping; generally speaking, anywhere a single
> character like x could appear, a complicated construction
> enclosed in braces may be used instead. Tilde ~ represents a
> full space in the output, circumflex ^ half as much."
>
> Maybe text along those lines needs to go into GNU eqn's man page.
I think you're right.
In practice, AT&T eqn was a bit Postelian, enough that I had to alter
the K&C document (the one I remembered to attach this time) to get it to
format correctly with GNU eqn.
Exhibit:
.\" Correct missing space after x for GNU eqn. GBR, 2022.
$lim from {x -> pi /2} ( tan~x) sup{sin~2x}~=~1$
AT&T eqn would apparently let you get away with this:
$lim from {x-> pi /2} ( tan~x) sup{sin~2x}~=~1$
I don't think bug compatibility would serve us well here. Plenty of
languages permit '-' in identifiers or tokens (like Lisp and *roff).
> One can argue that there needs to be
>
> thin_space_user
> thick_space_user
>
> if control is needed over those for the user's deliberately defined
> cases.
>
> That said, they should be called
>
> full_space_user
> half_space_user
>
> because that is what they technically are. We could just drop the
> '_user' and note in the documentation that they are
> explicitly/deliberately forced into the said equation by '~' and '^'
> respectively.
I like this idea. "{full,half}_space_width" might be even better.
[...]
> P.S. Sadly Lorinda Cherry passed away a bit over 12 months ago.
I learned that shortly before beginning my work on my little
"retypesetting mathematics" project. :(
Regards,
Branden
eqnuser-retypeset.pdf
Description: Adobe PDF document
signature.asc
Description: PGP signature