On 10.08.22 01:55, Deri wrote:
ok, in this case, yes. I would have expected the relative movement
being relative to the fraction bar itself, but that's obviously not
what eqn does.
This part I cannot speak to, as I have only barely begun coping with GNU
eqn's source code. If someone else knows, I hope they will clarify.
Sigh! Again.
It is not eqn.
It is not groff.
I've had finally got that before my last mail :): it is true, that the eqn-output is *identical*
irrespective of whether `download' contains the SS reference (sane ps and pdf in the end) or does
not (misformatted ps and pdf output).
what I meant, was, that the "1/2" misalignment seems to imply, then, that eqn's
output
does not do the positioning of the digits relative to the fraction bar (which
itself
is probably not from SS but from S or default text font anyway) but possibly
relative to
"end of preceding string of greek letters" in the example. I naively would have
expected that
eqn does
* print greek letters
* print fraction bar on same baseline
* move back by 1/2 width of fraction bar and up; print 1
* backspace and move down; print 2
in which case the whole fraction would be wrongly positioned but not internally
misaligned.
but that's idle and obviously wrong speculation and eqn actually does calculate the believed
position of the fraction bar (based on SS metrics and thus getting a position deviating
from the one actually realized in the ps/pdf output when that silent SS->S
substitution
happens) and then puts the digits on that horizontal position.
It is not grops (although a warning would be nice, but see above).
+1
It is ghostscript, which when it can't include the resource for Symbol-Slanted
picks Symbol instead, which has different glyph widths, rather than barf with
a message "Can't find font Symbol-Slanted".
