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