Re: eqn formatting issues with grops and gropdf

[joerg van den hoff]

On 27.07.22 14:29, Deri wrote:

On Wednesday, 27 July 2022 08:49:01 BST joerg van den hoff wrote:

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 :).

Hi Joerg,

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.

Hmm, I'm not sure, there's definitely an argument to use .fschar S rather than
plain .char to stop gropdf slanting greek glyphs in other fonts, I'll be
investigating this.

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:

[...]

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?

I can't reproduce this. When run with -T pdf I get this error:-

troff: tt2.trf:11: warning: can't find font 'SS'

oh sorry, my bad: I do have a "private" font/devpdf directory holding 
additional fonts
and I erroneously also put a link to the system's font/devps/SS there (and 
immediately forgot
about it again). so this one is on me. my apologies...

And equations 1 and 2 are identical. This is because font SS is not in the
font/devpdf directory. In addition the symbolsl.pfa in the grops directory is
not a type 1 font so even if I copy SS and symbolsl.pfa to font/devpdf and
insert the necessary into the download file, when I run the program gropdf
barfs on loading the symbolsl.pfa file since it does not recognise the format. >
It must be that on your system you do have the SS font and a valid
symbolsl.pfa which is a real type 1 font. In that circumstance you would get a
double slant, because the SS font contains glyphs which have already been
slanted and they would be slanted again by the code in pdf.tmac.

* standard groff 1.22.4 system installation





so with this setup I've got the results I described for gropdf. I do not quite 
understand,
whether I should be surprised by this since I read your mail as "should not work at 
all"?
if I can provide further information to hunt this down, please let me know.

see above: yes, I had erroneously SS on the gropdf font search path but nothing else was unusual. specifically, my setup was/is: * local/user font/devpdf with some fonts and a single softlink to system's font/devps/SS. this is seemingly stupid and wrong and should not be there * a symbolsl.pfa is residing out of the box in system's font/devps dir. I did not touch/modify it and it is not a type1 file but rather the short standard file (I presume).

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

I thought this only happened if you include .special S to force grops to use S
rather than SS. So not an issue.

no, it happens when explicitly demanding SS (or in my case even using the 
default
since here SS is present before S in devps/DESC) as symbols font with grops 
(Eq. 2).

     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.

attached _my_ pdf file generated with `groff -e -ms tt.trf |ps2pdf -  > 
grops.pdf'

as you can see it is exactly as said (for me...): something strange is going on

when using SS with grops (Eq. 2): missing slant despite SS requested, wrong spacing of the letters as well as alignment of the 1/2 ratio.

It is eqn which is requesting this extra space by including the \/ and \,
escapes in the output it produces. Why does it do this?

I suspect the convention in mathematical equations is that variables are
italicised and lowercase greek are used for variables. Also, that the greek

latin variables are definitely italicised commonly, lower case greek variables 
are
usually italicised (but not always, I believe: must check a few of my books :)) 
as well.

symbols used in equations are most often single characters. The greek alphabet
in a symbol font is not meant for writing greek text. If you have a normal

that's sort of correct (as with all variables in mathematical equations :)). but
of course products of variables like `xy' or `[alpha][beta]' occur frequently 
enough


.EQ
x y
.EN



.EQ
alpha beta
.EN

at the same point it generates `\f[R]\,\[*a]\/\fP\f[R]\,\[*b]\/\fP' which 
seemingly in fact
does add some small `\,' inter-glyph space but otherwise does the same as with 
`xy' -- nothing much.

and these are supposed to be typeset like a "word" (without sizable additional inter-character space). so does exactly that. it adds a bit of space before ("left italic correction") and does italic correction after the xy: `\,x\&y\/' is what I find in the eqn output.

font which contains the greek alphabet this what you need to write greek text.
Which is why the code in pdf.tmac is wrong, it should only be slanting the
symbol font, not all fonts which contain lowercase greek letters. Thanks to
Robert Goulding for bringing this to my attention, I will be working on it.

that I can understand :).

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

I'm afraid I can't see any mis-alignment of 1/2 when I run your test program,
I've attached a screen shot.

that's strange (but nice since your output is correct). attached my result
which disagrees in Eq. 2 with yours.

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

I consider what eqn is doing is a "feature". :-) It is a reasonable assumption
that a lower case greek letter will be followed by a roman character,
presumably a mathematical symbol, a number, a bracket, etc. so the extra space
is required to prevent the possibility of it touching the adjacent glyph.

I am not a mathematician, maybe someone can give a better answer.

I do not think eqn is the culprit here :). it seems it only tries to insert
additional `\,' space between greek letters/symbols in comparison to latin 
letters
which it just "fuses into a word". I do not think there are any further implicit
assumptions of what comes after what etc. and this is all fine it seems.

the actual mystery remains that your pdf and mine look different and that mine 
looks wrong.


.special SS
.LP
.EQ
alpha beta
.EN

the resulting pdf contains *unslanted* symbols while `pdffonts' tells me the 
only font
used in that document is Symbol-Slanted. and if those symbols are followed by 
other
stuff that stuff is misaligned to a different degree, depending on the number 
of preceeding
greek letters (each letters seems add additional wrong space). so Eq.(2) in the 
attached
pdf is "the" problem. which very probably is not eqn's fault but grops' 
(somehow). but whatever
the reason: that output is buggy and even if it is some sort of 
configuration/setup quirk that



I cannot see that... ;).

thank you and cheers,
joerg

I am of course afraid that it's all my fault and I am spamming the list and burning your time but I do not see where that fault could have happened. even if I boil the document down to could trigger this (and then would ultimately be my responsibility) it ideally should be accounted for/detected/handled by groff or grops, no? but actually I cannot come up with a plausible tentative explanation what could cause this on my system (OSX) and standard groff setup (except for that stupid SS link in local fonts/devpdf ...). maybe in the next step I nevertheless will re-install groff and see whether that helps although

thanks again and best wishes,

Cheers

Deri

joerg

grops.pdf
Description: Adobe PDF document