Re: Greek letters not slanted in -Tps eqn output

[joerg van den hoff]

hi deri,

thank you, although I am starting to feel obtuse :).

so what you say is *only* grops does not find SS (in my previous broken setup with disjunct 
`download' instances in system and my additional fonts tree) but groff still finds
the system SS font description file? and then groff bases all calculations 
where to move
on the SS metric while grops or gs puts the glyphs using the S metric it gets 
hold of elsewhere?

is this correct so far?

if yes, I can understand that after the `alpha beta gamma... ` sequence 
groff/eqn presume
a different position of last greek letter than actually is going to be true downstream when the ps 
oder pdf is generated. and so groff/eqn would position whatever comes next on a wrong horizontal 
position relative to the greek letters.

I still do not _quite_ get why this could lead to anything but a common 
horizontal
mispositioning of the `1 over 2' relative to the preceding `S' greek letters 
typeset
by gs with `S' metric (IIUC) but assumed to be positioned with `SS' metric by 
groff and eqn.

so the misalignment in 1/2 of digits relative to fraction bar still mystifies 
me. I looked
at the eqn output but only can discern that some width computation for the 
alpha beta gamma sequence
as a block is going on and that the fraction then somehow is put afterwards (of course). but I 
cannot "read troff" good enough to see what eqn is doing in terms of "draw fraction bar and put 1 
above and 2 below"....

but be this at it may. the problem is artificial in so far as it onl occurs 
with misconfigured
`download' in my additional fonts tree. so maybe not worth to go on about it 
too long ;).


best,
joerg


On 09.08.22 00:11, Deri wrote:
> On Monday, 8 August 2022 20:32:24 BST joerg van den hoff wrote:
> > thank you for this explanation. I think I nearly get it now regarding font
> > selection. but regarding font metrics: my rudimentary understanding was/is
> > that each glyph essentially gets assigned a rectangle ("bounding box" of
> > the glyph) and that troff just arranges those boxes next to each other
> > without gap or overlap, usually? probably there are finer points to this
> > (microtypograph, gaps between or overlap of those rectangles etc) but
> > mostly each glyph just occupies such a rectangle, no? if that were correct,
> > then I still do not understand how the 1/2 fraction in the example could
> > end up to look like
> >
> >      1
> >    -
> >      2
> >
> > i.e. the fraction bar is shifted relative to the digits. I would have
> > expected that the whole fraction just appears either too close to or too
> > far away from the preceding greek letters if the wrong symbol font is
> > found/used and a not-matching metric is used?
> >
> > and actually I do not even understand, _why_ a not-matching metric should be
> > used at all rather than the one of the actually (if erroneously) used font?
>
> Hi Joerg,
>
> I'll try to explain why the metrics might cause problems if the boxes defined
> for the glyphs in SS (used by groff) are different to the boxes for the font
> used by ghostscript. When each glyph is stroked there is an implicit movement
> equal to the width of the box for that glyph, so if there is a discrepancy in
> the metrics the position groff thinks the next character will be placed will
> not match the position ghostscript calculates.
>
> If I look at the pdf Robert supplied after converting the postscript to pdf, I
> noticed the widths it was using for the Symbol-Slanted font were:-
>
> /Widths [521 0 0 0 0 549 0 0 0 0 0 0 549]
> /Differences [102 /phi 107 /kappa 114 /rho]
>
> So the width for the kappa glyph is 549 but if I look at the groff fonts:-
>
> S:*k   549,501,0,9     3       107     kappa
> SS:*k  489,446,0,182,-56,99    3       107     kappa
>
> You can see that the width for kappa in the SS font is different, but matches
> the S font. So after each glyph the actual position in ghostscript will be
> different to what groff has calculated (since groff thinks the kappa width is
> 489 and ghostscript thinks it is 549, the implicit move after stroking is
> different). This is a bit of a simplification, since eqn is using the italic
> correction escapes as well, but it is sufficient to show that the different
> metrics could throw off horizontal positioning.
>
> Imagine the instructions:-
>
> abc move 1
>
> So this means: stroke glyphs abc then move right and stroke glyph 1. If the
> metrics for the font used for "abc" are wrong for ghostscript, the horizontal
> position after stroking the c will be wrong, and if the move is relative
> rather than an absolute position, the 1 will be in a different position than
> groff intended.
>
> I see Branden has gone into didact mode on the groff_out intricasies but the
> reason your equation was squiff is not to do with groff, its because
> ghostscript had no Symbol-Slanted font, picked Symbol instead and used its
> metrics which do not match.
>
> Cheers
>
> Deri
>
> > just wondering. no longer really relevant since problem solved :).
> >
> > best,
> > joerg