On 30.06.22 18:35, G. Branden Robinson wrote:
Hi Joerg,
hi brenden,
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`.
ah, right, I see! should have recognized that myself. it is "obvious" in
retrospect. :)
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]
I think the straightforward way, then, is to double quote PI (or generally, any
font name...):
gfont "PI"
actually seems to do the trick and the font is set correctly. actually, there are some references in
the (g)eqn manpage of using double quoting to suppress macro expansion in certain contexts. it seems
to help here too :).
In the meantime, try this.
I can confirm that your solution works, too. thanks for this idea. did not
know of the `.ftr'
request so far.
--- 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.
understood.
altogether I now think the "correct" solution seems to be to just change the
eqn manpage regarding
the `gfont', `grfont', `gbfont' commands (at least grfont is needed, too, since otherwise the
numerals like the "sup 2" in my example still are typeset in using the base font) and to tell the
user to always double-quote the font names to be on the safe side and avoid unintentional
misinterpretation by eqn (PI being an obvious example...).
thanks a lot again. problem solved it seems :).
br/joerg
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.