Resurrecting a three year old thread ... On 21/09/14 05:38, Werner LEMBERG wrote: >>> A good starting point may be to implement a C/C++ library function, >>> to extract the MediaBox properties; that would open the gate to a >>> possible pdfbb request, which gtroff.exe could process internally. >> >> Alternatively, we could modify the existing implementation of .psbb, >> such that it will discriminate on `%!PS-Adobe-´ or `%PDF-´ as >> initial file content, then DTRT wrt parsing a `%%BoundingBox:´ or >> `/MediaBox´ record accordingly. > > Good idea!
You may recall that I did begin to explore possibilities, at the time, but then life ... explicitly a protracted visit to Australia and New Zealand, followed by too many other priorities on return ... got in the way. I've now found a bit of time to revisit it, and have posted some prototypical code at https://osdn.net/users/keith/pf/groff-psbb/files Although I did, initially, consider a C++ solution, I'd actually given up on that idea, before heading off to the antipodes; I now believe a lex scanner, coupled with a minimal yacc parser to drive it, offers a much more practical implementation. The mechanism for integrating it into groff is illustrated in t-psbb.cpp, (which compiles to a free standing test program for the lex/yacc code). At present, it seems to work for EPS and regular PDF files, (but not for linearised PDF); I have yet to implement handling for the effect of the /Rotate operation on PDF /MediaBox properties ... I'd like some agreed understanding of exactly what transformation that should represent, before I proceed. Also, should /CropBox, /BleedBox, /TrimBox, or /ArtBox be considered to have any relevance, in this context? Does anyone foresee any possible difficulties in incorporating such a solution into groff, before I pursue it further? -- Regards, Keith.
