Re: Greek letters not slanted in -Tps eqn output

[Deri]

On Tuesday, 9 August 2022 20:38:44 BST G. Branden Robinson wrote:
> [looping in groff@ again due to a shift in discussion focus to
> development]
> 
> At 2022-08-09T19:14:25+0200, joerg van den hoff wrote:
> It is possible for device or font description files to be incomplete; if
> they are missing essential information, they will fail validation and
> the output driver will issue diagnostics.  groff Git is much more
> fastidious about such validation than 1.22.4 was.
> 
> Are you not getting a diagnostic message from grops(1) when it can't
> find "Symbolsl.pfa"?  Are you running groff 1.22.4 or Git?  If the
> latter then this is something I want to fix.  Even if I or someone else
> implements further searching, we'll need that diagnostic for when all
> download files are exhausted without a match.

Hi Branden,

I did deal with this issue a bit earlier. Grops (currently) has no way of 
knowing it is missing a resource - Symbolsl.pfa. The logic seems to be that if 
there is a groff font file (e.g. TR) which contains an "internalname" (e.g. 
Times-Roman), and download does not contain a reference to that internalname, 
then it is assumed the font does not need to be downloaded into the postscript 
file. This would be true for one of the base-35 fonts, since grops just needs 
to include the instruction "%%IncludeResource: Times-Roman" which signals to 
the consumer of the postscript file that it needs to provide the font itself 
(i.e. it is not embedded).

When this logic is used for a font which is not base-35 problems can occur 
because the consumer (i.e. ghostscript) has guess what font to use. It does 
not look like grops is aware of the 35 internalnames which form the base-35, 
so I cannot see a way how it can know it has a missing resource. It is relying 
on the presence of an entry in the download file to determine that it requires 
a type 1 font to be embedded in the postscript, so if the download file does 
not include the intenalname Symbol-Slanted it does not know it should have 
embedded Symbolsl.pfa.

If grops did include the 35 internalnames in its source then it could 
determine a resource was missing, by checking the internalname against that 
list, if it is not there and it is not found in the download file, it will 
know there is a problem. 

[snip]
> 
> Yes, updating the gropdf man page sounds appropriate.  Deri, would
> prefer to handle this or would you like me to?

'tis done.

> > well, if the (newer) gropdf does that, maybe it should be "backported"
> > to grops :).
> 
> A simple matter of rewriting Perl code in C++.  ;-)

Ooh, I love a hash (particularly corned beef). :-)
 
> > > > 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.
> > > 
> > > After the greek characters comes the horizontal line between 1/2. If
> > > the move to the start of the line before drawing is a relative
> > > movement from the end of greek characters then it will be in the
> > > wrong position.
> > 
> > ok, in this case, yes. I would have expected the relative movement
> > being relative to the fraction bar itself, but that's obviously not
> > what eqn does.
> 
> This part I cannot speak to, as I have only barely begun coping with GNU
> eqn's source code.  If someone else knows, I hope they will clarify.

Sigh! Again.

It is not eqn.
It is not groff.
It is not grops (although a warning would be nice, but see above).
It is ghostscript, which when it can't include the resource for Symbol-Slanted 
picks Symbol instead, which has different glyph widths, rather than barf with 
a message "Can't find font Symbol-Slanted".

Your focus on what groff -Z produces is misplaced. It will have no bearing on 
the pdf code which ghostscript produces. Ghostscript must build up a page as 
an internal structure and then use an output driver to produce appropriate 
output, pcl, pdf etc.. So if you use ghostscript to process ps->ps or pdf->pdf 
you will find very big differences internally, but the actual output will look 
the same.

Just for a bit of fun!! Here's the groff_out,  the pdf instructions produced 
by ghostscript and the pdf instructions produced by gropdf.

First groff:-

x font 5 TR
f5
s10000
V84000
H72000
md
DFd
tA
wh2500
tsimple
wh2500
tequation
wh2500
tsuch
wh2500
tas
n12000 0

Each word is a separate t command, and since the TR font has "spacewidth 250" 
and the point size of the font is 10 this explains the wh2500 as a white-space 
horizontal movement.

Now for the ghostscript produced pdf instructions:-

2.5 Tc
/R7 10 Tf
1 0 0 1 72 708 Tm
(As)Tj
0 Tc
13.6102 0 Td
(imple equation such as)Tj

A bit of odd! "A s" has been squashed to "As" but it is preceded by the 2.5 Tc 
which is an instruction to use 2.5 points as the inter-character gap (usually 
zero), so this matches the wh2500 (in thousandths of a point). It may well be 
the postscript fed to ghostscript did it that way, perfectly fine, more than 
one way to skin a cat (not that I know any ways!!).

Gropdf produced this:-

1 0 0 1 72.000 708.000 Tm
/F5 10 Tf
0 Tc
0.000 Tw [(A simple equation such as)] TJ

Tw controls the interword gap, zero means use the spacewidth value. This shows 
that the groff -Z output has no direct control over what the output drivers 
actually produce.

Cheers 

Deri


> Regards,
> Branden