bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Greek letters not slanted in -Tps eqn output


From: Deri
Subject: Re: Greek letters not slanted in -Tps eqn output
Date: Mon, 08 Aug 2022 23:11:02 +0100

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








reply via email to

[Prev in Thread] Current Thread [Next in Thread]