Follow-up Comment #14, bug #65098 (group groff): Hi Deri,
At 2025-06-10T12:13:19-0400, Deri James wrote:
> Follow-up Comment #13, bug #65098 (group groff):
> [comment #9 comment #9:]
> [...]
>> 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.
I understand (now).
> 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!
Hah!
> 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 won't prevail upon you to do that. I think it'd be better if we had a
superior font construction story in the first place so we don't have to
duplicate such workarounds for other fonts in the future.
I still hold out hope for resolving bug #62932 some day.
> 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.
Ah, I didn't notice _any_ collateral damage.
>> 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.
It quite possibly will, and I'm eager to test it. I should observe in
the meantime that I don't think anything else in groff parses a, uh,
"search path supplementation option" (`-I` and `-M` come to mind on top
of the aforementioned `-F`) as having an additional list structure, with
the "runtime path element separator" serving as a field separator. Only
the values of environment variables work this way.
It's fine if gropdf(1) supports `-F foo:bar` as an extension, though.
I'll double check that claim about other groff programs' `-[FIM]`
options when I'm not in the midst of non-groff tasks, but if some
language in troff(1) misleads the reader into thinking otherwise, please
let me know.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65098>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
