At 2026-11-12T15:37:44+0100, Morten Bo Johansen wrote: > On 2026-11-12 G. Branden Robinson wrote: > [...] > > Thanks for all the foregoing information.
I wish I could be more helpful. I don't feel I have a good enough
understanding of the problem space here. When that happens I try to
reason from principles, like "writing *roff input should not require
more than the absolute minimum of knowledge of output device
properties" and "arbitrary control of the output device should be
possible".
It seems like when I get into conflicts with Deri, they arise from him
taking an opposite stance: he knows a metric ton of PDF, and generalizes
from that knowledge. For groff development in general, that's not a
bug, but a feature: a programming language needs to be designed with the
properties of the "machine" it drives clearly in mind. That's why the C
language was so successful as a high-level assembly language for the DEC
PDP-11 line of machines.
Or as I say in other contexts: "attend always to material conditions".
I want a clean language for authors who think primarily about the
content of their document and not so much about the technology of
rendering it, and Deri wants to expose the full power of PDF to the
user as comfortably as possible. That's reasonable because people who
_read_ PDFs, be it in digital or hard copy form, naturally want to
exercise the some of the same idioms and capabilities in what they
write. Impedance mismatches in communication are part of the process.
> > ...but grepping _afmtodit.tables_ might help. I admit that that
> > might be feeble advice.
>
> The same information is included in the afmtodit executable, but again
> it won't tell me directly which font file has the glyph. But I could
> of course search that file and then get the corresponding hex code and
> then search for that code in the font files. I suppose that might be a
> solution albeit a slightly clumsy one.
I'm not happy with the thought of having to tell groff users that. It
seems like there's space for some kind of "what provides the glyph the
output device knows as 'foo'?" query facility. There could of course be
more than one matching font!
As a _highly_ tentative suggestion, possibly a `pglyph` request taking a
mandatory rest-of-line argument[1] would perform a search, and report
matching mounted fonts. I wouldn't want to freight such a facility with
taking the character-to-glyph resolution process into account, at least
not as a first cut of the feature. That's already a work item for the
`pchar` request.[2]
Regards,
Branden
[1] Glyph identifiers are named however the font file format names them;
we have no control over them and they are not *roff identifiers, so
no *roff naming rules apply. A font might name its glyphs with
spaces in the identifiers, like "LATIN CAPITAL LETTER A WITH ACUTE".
[2] https://savannah.gnu.org/bugs/?67492
signature.asc
Description: PGP signature
