Follow-up Comment #13, bug #65098 (group groff): [comment #9 comment #9:] > Hi Deri, > [...] > Also, if you could regenerate the "SS" file using a contemporary _afmtodit_ > that records more information, that would be helpful. Do you have an "afm" > file for "StandardSymSL.pfb"?
Not one that "works", for the same reason we can't run afmtodit on the
symbolsl.afm file in grops, it produces the wrong values because the
width/height values do not take into account the transformation by .89. The
best way of producing the gropdf/SS file is:-
grep -v "^---" src/font/devps/SS
Grops's SS file is the only place with the correct numbers! I might be able to
write a script which tekes the symbol afm file and adjusts the numbers so that
when run with afmtodit -i 50 it will actually generate the correct numbers.
I have noticed commit 66df2be1a90c88efda979305cde588c1ed3e3b7c actually stops
gropdf picking up the unicode number from the comment field because it
replaced "--\tcode" with "-- code", (I'm splitting the line on tabs so it is
one field less), but I do like the intention of the patch, to stop the comment
output if there is no unicode.
> I ask for all this stuff because it's hard to get _gropdf_ to find
> "StandardSymSL.pfb" to embed it when running it from a build tree that is not
> also the source tree. That is a supported build scenario (and my usual one).
> The "download" file doesn't have any concept of source tree and build tree;
> to it, everything is an installation.
I hope the patch to allow multiple -F flags simplifies the problem, SS and the
pfb file sit in the src until make install, the same way grops treats its SS.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65098>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
