[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Greek letters not slanted in -Tps eqn output
Re: Greek letters not slanted in -Tps eqn output
Wed, 10 Aug 2022 00:55:32 +0100
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
> 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.
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
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.
> Yes, updating the gropdf man page sounds appropriate. Deri, would
> prefer to handle this or would you like me to?
> > 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.
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
Just for a bit of fun!! Here's the groff_out, the pdf instructions produced
by ghostscript and the pdf instructions produced by gropdf.
x font 5 TR
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
Now for the ghostscript produced pdf instructions:-
/R7 10 Tf
1 0 0 1 72 708 Tm
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.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