Re: eqn formatting issues with grops and gropdf

[joerg van den hoff]

hi deri,

thanks a lot for bothering. have read and understood everything. this is all 
interesting
and mostly was unknown to me so far. I also tried out your manual slanting 
suggestion
for grops with S font. this is all good and well so far :).

however, I presume that there really remains some bug to be found in grops or 
in the
way the installation/configuration of groff is done.

I have modified the example script integrating your suggestion re slanting for easier comparisons. 
if you copy+paste it to, say, "tt.trf" run it once with

groff -U -Rtep -ms -Tpdf tt.trf

and once with

groff -U -Rtep -ms -Tps tt.trf

to compare:
.\"====================cut==========================
.nr PS 14
.nr VS 17
.LP
.special S
Requesting .special S with \*[.T] device
.EQ (1)
alpha beta gamma delta rho sigma 1 over 2
.EN
.LP
.special SS
Requesting .special SS with \*[.T] device
.if '\*[.T]'ps' (which is broken: wrong interglyph space, messed up position of dividing line in 1/2 
ratio, seemingly glyphs from S)
.if '\*[.T]'pdf' (which is not supposed to be done and looks a bit as if gropdf slants (and messes 
up) the alredy slanted symobls from SS again?)
.EQ (2)
alpha beta gamma delta rho sigma 1 over 2
.EN
.de pdf:SS
.    char \\$1 \\S'16'\\$1\\S'0'\^
..
.pdf:SS \[+h]
.pdf:SS \[ts]
.pdf:SS \[*a]
.pdf:SS \[*b]
.pdf:SS \[*x]
.pdf:SS \[*d]
.pdf:SS \[*e]
.pdf:SS \[*f]
.pdf:SS \[*g]
.pdf:SS \[*y]
.pdf:SS \[*i]
.pdf:SS \[+f]
.pdf:SS \[*k]
.pdf:SS \[*l]
.pdf:SS \[*m]
.pdf:SS \[*n]
.pdf:SS \[*o]
.pdf:SS \[*p]
.pdf:SS \[*h]
.pdf:SS \[*r]
.pdf:SS \[*s]
.pdf:SS \[*t]
.pdf:SS \[*u]
.pdf:SS \[+p]
.pdf:SS \[*w]
.pdf:SS \[*c]
.pdf:SS \[*q]
.pdf:SS \[*z]
.if '\*[.T]'ps' \{\
.LP
.special S
Requesting .special S with \*[.T] device and explicit slanting (deri 
chuzzlewit, mailing list). this
looks similar to what gropdf produces but intentionally adds 1/12 em space 
between glyphs.
.EQ (3)
alpha beta gamma delta rho sigma 1 over 2
.EN
\}
.\"====================cut==========================
the result you should see is anticipated in the included text ;).

bottom line: there remain 2 issues (or 1 real one):

1.
gropdf can be forced to use SS in which case it "super-slants" the glyphs and uglifies them in other 
ways (see the delta glyph especially ...). I understand that this (using SS with gropdf) seemingly 
is not supposed to be done but I've read your mail in such a way that it simply would not work at 
all? in any case this is probably irrelevant and ultimately maybe even a non-issue since not 
supposed to work anyway?

2.
grops definitely does something wrong to the equations when using SS (which 
seemingly is the
default in my groff installation: I definitely did not touch DESC previously). 
the problem
seems threefold:

   a) using unslanted S glyphs anyway (or undoing the slanting in SS or 
whatever...)

   b) using the italics correction or probably the full glyph width/height etc. 
info
      nonetheless (it seems). in any case wrong positioning/spacing info is 
used.

   c) somehow confusing eqn's subsequent positioning of the 1/2 ratio in the 
example. I
      presume it is mostly the dividing line that gets pushed "downstream", but 
the digits
      also seem to be too far to the right. why this happens even in the 
presence of mis-positioning
      the preceding greek letters I do not understand at all: I would 
understand the the 1/2 ratio
      consequently also ends up at a wrong horizontal position as a whole but I 
do not understand
      at all why the 1/2 is intrinsically mis-aligned (digits vs. dividing 
line).

if grops *is* supposed to support/work with SS, than the observed behaviour is 
a real bug, no?

thanks again and best wishes,

joerg

On 26.07.22 22:44, Deri wrote:
> I have managed to rescue my second message which was truncated!!
>
> On Tuesday, 26 July 2022 17:19:04 BST Deri wrote:
> > On Tuesday, 26 July 2022 09:00:25 BST joerg van den hoff wrote:
> > > me again with an update/correction to the previous description of the
> > > issue
> > > (the described problem remains, though):
> > >
> > > 1.
> > > regarding the symobl fonts used by grops and gropdf I previously stated
> > > the
> > > former were using SS (symbols slanted) and the latter S (symbols) which I
> > > presumed according to the looks of the greek letters in the ps output
> > > (upright) and pdf output (slanted to the right like italics). this was
> > > *wrong*. looking into the font information in the formatted files it was
> > > the other way around (grops was using SS and gropdf using S).
> > >
> > > looking into the DESC files, I do find indeed entries
> > >
> > > grops:  fonts 9 0 0 0 0 0 SS S ZD ZDR
> > > gropdf: fonts 9 0 0 0 0 0 0 S ZD ZDR
> > >
> > > which explains the font selection that occurred. I do not understand,
> > > however, while this ultimately lead to _slanted_ glyphs with gropdf and
> > > _upright_ glyphs with grops (exactly the other way around as I would have
> > > expected for S vs SS).
> > >
> > > 2.
> > > forcing grops to also use S (by editing the DESC file and removing SS from
> > > the entry) leads to sane ps and pdf output with both devices (no
> > > misalignment and strange irregular widths of the greek letters). so this
> > > would be the quick patch to "repair" grops: change the DESC file.
> > >
> > > 3.
> > > using now the same font S, the glyphs produced by grops are upright
> > > (expected) and those produced by gropdf are slanted (unexpected). why is
> > > that??
> > >
> > > the main observation remains unaltered: in standard setup grops uses SS
> > > for
> > > typesetting greek letters since SS is found before S according to DESC and
> > > this leads to rather massive typesetting errors in equations using
> > > possibly
> > > many greek letters: cumulative mispositioning of stuff later on the same
> > > line.
> > >
> > > what do to about this?
> > >
> > > thank you
> > > joerg
> >
> > Hi Joerg,
> >
> > You are correct that gropdf does not include the SS font. The reason is
> > because it is not a proper font, it is instead a postscript program, which,
> > when run by a postscript interpreter such as ghostscript or a postscript
> > printer, generates a slanted version of the symbol font. This is not valid
> > as a pdf font.
> >
> > The SS font and the S font both define *a but only S defines *A so when they
> > are both loaded with .special SS S the lower case is found in SS but
> > uppercase in S. Since gropdf does not have SS *a is found in S and a
> > special command is sent to gropdf "x Slant 16" which tells it to slant the
> > glyph by 16 degrees.
> >
> > If you type:-
> >
> > echo "\[*a]" | groff -Z
> >
> > You will see:-
> >
> > x T ps
> > x res 72000 1 1
> > x init
> > p1
> > x font 11 S
> > f11
> > s10000
> > V12000
> > H72000
> > md
> > DFd
> > C*a
> > h6310
> > n12000 0
> > x trailer
> > V792000
> > x stop
> >
> > But if you type:-
> >
> > echo "\[*a]" | groff -Tpdf -Z
> >
> > It changes to:-
> >
> > x T pdf
> > x res 72000 1 1
> > x init
> > p1
> > x font 11 S
> > f11
> > s10000
> > x Slant 16
> > V12000
> > H72000
> > md
> > DFd
> > C*a
> > h6310
>
>
> This is a bit of a disappointment, 80% of my email is missing, my fault I'm
> sure. So this will be the short version!
>
> The reason the pdf version slants the S characters when outputting lowercase
> greek is because of this code in pdf.tmac:-
>
> .de pdf:SS
> .    char \\$1 \\S'16'\\$1\\S'0'
> ..
> .pdf:SS \[+h]
> .pdf:SS \[ts]
> .pdf:SS \[*a]
> .pdf:SS \[*b]
>
> Which slants each character when you use it. The reason grops outputs
> lowercase greek is because it searches in SS before S which has definitions
> for lowercase but not uppercase. The S font has definitions for both cases, so
> when you prevent grops from using SS you end up with non-italicised glyphs.
>
> Now to look at why the character spacing is different. Italic fonts have extra
> metrics which determine how much space to add for italic correction (space to
> add when italic and normal characters are directly adjacent). SS has these
> extra metrics, S does not. You tell groff to add this space by placing \, or
> \/ between the two characters. When eqn is processing your equation it
> encapsulates each greek character with these escapes. Which causes the extra
> space to appear. I suspect it does this because usually these greek characters
> appear on their own in formula, rather than a group together.
>
> So the solution, if you want the slanted characters you see from gropdf, but
> using grops. Is to prevent grops using SS, as you have done, and include the
> code you find in pdf.tmac, which slants the characters, into your own file.
> The "x Slant" command is understood by grops as well as gropdf so it should
> work.
>
> Here's your test file.
>
>
> .\"====================cut=================
> .\"groff -e -ms tt.trf > tt1.ps         -- broken output (output from ps2pdf
> tt1.ps, too, of course)
> .\"groff -e -ms -Tpdf tt.trf > tt2.pdf  -- looks good.
> .
> \"----------------------------------------------------------------------------------------------
> .
> .\" Use S only not SS (don't have to modify DESC)
> .special S
> .de pdf:SS
> .    char \\$1 \\S'16'\\$1\\S'0'\^
> ..
> .pdf:SS \[+h]
> .pdf:SS \[ts]
> .pdf:SS \[*a]
> .pdf:SS \[*b]
> .pdf:SS \[*x]
> .pdf:SS \[*d]
> .pdf:SS \[*e]
> .pdf:SS \[*f]
> .pdf:SS \[*g]
> .pdf:SS \[*y]
> .pdf:SS \[*i]
> .pdf:SS \[+f]
> .pdf:SS \[*k]
> .pdf:SS \[*l]
> .pdf:SS \[*m]
> .pdf:SS \[*n]
> .pdf:SS \[*o]
> .pdf:SS \[*p]
> .pdf:SS \[*h]
> .pdf:SS \[*r]
> .pdf:SS \[*s]
> .pdf:SS \[*t]
> .pdf:SS \[*u]
> .pdf:SS \[+p]
> .pdf:SS \[*w]
> .pdf:SS \[*c]
> .pdf:SS \[*q]
> .pdf:SS \[*z]
> .LP
> .EQ (1)
> alpha beta gamma delta rho sigma 1 over 2
> .EN
> .LP
> .EQ (2)
> a b c d r s 1 over 2
> .EN
> .\"====================cut=================
>
> I have added a tiny amount of space between the characters. If you don't like,
> remove the \^ from line 9.
>
>
> Cheers
>
> Deri