Re: eqn formatting issues with grops and gropdf

[Deri]

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'

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. 

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

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

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

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

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

> thanks again and best wishes,

Cheers

Deri

> joerg

grops view
Description: PNG image