Fwd: Re: suspected `eqn' bug.

[G. Branden Robinson]

I meant to CC this list, but forgot.

Joerg's original message can be found at
<https://lists.gnu.org/archive/html/bug-groff/2022-06/msg00263.html>.

----- Forwarded message from "G. Branden Robinson" 
<g.branden.robinson@gmail.com> -----

Date: Thu, 30 Jun 2022 11:35:09 -0500
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: joerg van den hoff <veedeehjay@gmail.com>
Cc: bug-groff@gnu.org
Subject: Re: suspected `eqn' bug.

Hi Joerg,

At 2022-06-29T19:45:41+0200, joerg van den hoff wrote:
> hello,
> 
> currently coming back to groff more seriously after quite a long time
> (so having got somewhat "rusty"), I have stumbled today over the
> following (observed with version 1.22.4 and ms macros):
> 
> I tried to use the `eqn' `gfont' command for switching the font used
> in equations to something different from the default I style of the
> presently selected font family. this works as advertised *except* when
> issuing
> 
> gfont PI
> 
> which fails to do what it should (namely switching to Palatino
> italics).  consider the following ms-document demonstrating the issue.

Thanks for the report.  This appears to be because "PI" is a magic token
in eqn(1), preferentially interpreted even in this context as a
shorthand for the capital Greek pi symbol; it is therefore replaced with
a special character escape sequence to access the corresponding glyph,
which is `\(*P`.

https://git.savannah.gnu.org/cgit/groff.git/tree/src/preproc/eqn/lex.cpp#n142

How do we cope with this problem?

groff's eqn(1) man page is not a full reference, just a list of featural
differences from AT&T eqn.  So I checked Kernighan & Cherry's
"Typesetting Mathematics -- A User's Guide" (2nd ed., 1978), and it did
not appear to document any means of escaping or quoting special tokens
like "PI" or "OMEGA".  However, you can still work around the problem by
remapping the Palatino italic typeface in groff to use a name that
eqn(1) doesn't recognize as a primitive token.  Needless to say, this
method is not portable to older-style troffs.

Someone on this list may well know of an escaping mechanism that eqn(1)
lexers should portability recognize to avoid this problem in a better
way.[1]

In the meantime, try this.

--- ATTIC/vandenhoff.ms 2022-06-30 10:35:18.535037049 -0500
+++ ATTIC/vandenhoff2.ms        2022-06-30 11:27:04.787662565 -0500
@@ -2,6 +2,7 @@
 .nr PS 14
 .nr VS \n(PS+4
 .ds FAM H
+.ftr PITALIC PI
 .LP
 The following equation should be typeset with Palatino as italic font but it 
is not
 since the  eqn command
@@ -10,7 +11,7 @@
 Since the font is not set correctly, as a fallback it seems the current regular
 font (in the present example: Helvetica) is used:
 .EQ
-gfont PI
+gfont PITALIC
 E = m cdot c sup 2
 .EN
 .ds FAM P
@@ -45,4 +46,5 @@
 .DS
 .CW "warning: can't find font '\\\(*P'
 .DE
+.ftr PITALIC
 .\"----------------------------------------------------------------------

The removal of the font name remapping at the end is for tidiness and, I
expect, not necessary for most documents' purposes.

Regards,
Branden

[1] The trusty workhorse for this sort of thing, the ineffable `\&`, did
    not work to sneak the name "PI" past eqn in the guise of "P\&I", but
    I didn't really expect it to since eqn is a _preprocessor_ that
    doesn't necessarily recognize the ineffable escape sequence.



----- End forwarded message -----

signature.asc
Description: PGP signature