Follow-up Comment #7, bug #62923 (project groff):
This probably deserves its own bug number, since the original problem is now
fixed.
This second reported issue is not specific to PDF output, the same problem
exists with postscript, which is indicative the issue is other than the output
driver, or something which is common to both, such as the pfa font file.
I'm afraid I have not been able to pin down exactly what is happening, but I
will document what I have discovered so far. First I extended the example to
include the same equation but using the standard symbol font. This produces
this groff_out:-
x T pdf
x res 72000 1 1
x init
x F /usr/share/groff/1.22.4/tmac/eqnrc
x F t.trf
p1
V85173
H72000
DFd
x font 39 XITSMR
f39
s10000
v457
md
Csqrt
Cradicalex
h1660
Cradicalex
x font 38 TI
f38
h8390
V85173
tx
h530
n13173 0
x font 11 S
f11
V110455
H72000
Csqrt
Cradicalex
h740
Cradicalex
f38
h5520
V109173
tx
h530
n12000 0
x trailer
V792000
x stop
You can see that in both cases the sqrt is immediately followed by the
radicalex without an intervening "h" command. So although this looks
suspicious, on its own it can't be the underlying issue.
So, if you look at what eqn actually eventually outputs for both equations:-
XITSMR=\&\E*[0sfont]\f[I]\s'\En[0ssize]u'\Z\(EQ\s[10000u]\v'--457u'\[sqrt]\l'5740u\&\[sqrtex]'\s[10000u]\(EQ\Z\(EQ\h'15020u-5740u+9280u/2u'\,x\/\(EQ\h'15020u'\E*[0rfont]\x'-(9673u-85M)'
S
=\&\E*[0sfont]\f[I]\s'\En[0ssize]u'\Z\(EQ\s[10000u]\v'--1282u'\[sqrt]\l'5740u\&\[sqrtex]'\s[10000u]\(EQ\Z\(EQ\h'11230u-5740u+5490u/2u'\,x\/\(EQ\h'11230u'\E*[0rfont]
(Captured as a .tm of the value of \*(10 which eqn builds).
In both cases the sqrt, within a \Z, is immediately followed by a line created
by repeated sqrtex characters, with some overlapping to create a line of the
desired length, to fit over the "x". I am not sure there is a significant
difference between the two, differences in numbers can mostly be traced back
to the meta-data in the respective font files.
Here's the postscript which is produced:-
/F0 10/XITSMath-Regular@@0 SF -9.28(\(,)72 85.63 S(,)6.86 E/F1 10
/Times-Italic@0 SF(x)4.31 -.457 M/F2 10/Symbol SF 4.22 -5.49(\326` `)72
110.455 T F1(x)6.01 -1.282 M 0 Cg EP
The only interesting thing here is the Symbol version is output with the T
operator while the XITSMath version uses the S operator. Probably a complete
red herring, but unfortunately I've reached the boundary of my current
knowledge! I place all the information here hopeful it will be seen by a
"Gunga Din".
It is possible that the reason the .char fixes it for the XITSMR font (but
messes it up for the S font) is because the 2nd parameter is treated as a
string and dealt with in its own environment, which forces the previous glyph
to be treated "normally", i.e. a "c" followed by its width in an "h" command.
Incidentally, the "fix" still works if you do .char \[radicalex] \[radicalex]
instead, so it does not look like its to do with glyph aliases in the XITSMR
file.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?62923>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
