[bug #55107] PDFPIC: .psbb: support extraction of MediaBox from pdf files

[G. Branden Robinson]

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/