Re: Greek letters not slanted in -Tps eqn output

[joerg van den hoff]

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".