Follow-up Comment #7, bug #55107 (project groff): Hi, Keith,
[comment #6 comment #6:] > Sorry, I don't know; the choice was made, w.r.t. EPS files, before my association with the project began. I can imagine, however, it may be a matter of convenience, because by having the psbb parsing code accessible as linked in functions, the assignment to troff's internal registers is straightforward, I suppose, but putting .nr llx 1234u .nr lly 5678u .nr urx 6789u .nr ury 7890u onto the output stream isn't too hard, either. (Though while I'm here I'll note the unnecessary intrusion into the user's name space. There's no reason these couldn't have been called groff*bbox*llx and similar, for instance. If the user desires short names for these, the `aln` request is at hand. Beyond that, isn't PSPIC pretty much the _only_ invoker of the `psbb` request in the first place?) > whereas, if the parsing is delegated to a preprocessor, not only does that preprocessor have to implement the same parsing logic, I'm thinking more of "moving" than "reimplmenting" here, though I admit if my other spitball idea of writing the thing in Perl would indeed make it a question of reimplementation. > but troff then incurs the overhead of setting up an IPC pipeline, to capture the preprocessor output, then fork the preprocessor, groff already handles all of this. Some of the most important bits are: https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/groff/groff.cpp#n54 https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/groff/groff.cpp#n576 https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/groff/pipeline.c ...or I am badly misunderstanding you. > and ultimately, reinterpret the preprocessor output to assign the requisite register values. The contract of writing something called a groff preprocessor is that you will emit output that GNU troff can parse. Every time I've looked at the psbb code in GNU troff <https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/input.cpp#n6068> I've become uneasy. It _feels_ strongly like something that should have a higher barrier of interfacing around it. It's about 5% of the source lines of the file, which contains the implementations of about 100 requests _and_ the troff program's command-line option parsing and diagnostic handling to boot. The psbb part of the file defines its own bespoke classes, and and most of the psbb-related functions call only each other or standard C library functions (like sscanf, strlen, and fseek), not other troff functions. I wonder if anyone else feels a similar unease. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?55107> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
