On Monday, 20 September 2021 20:39:49 BST Keith Marshall wrote: > On 20/09/2021 19:22, Dave Kemper wrote: > > Hi Heinz-Jürgen, > > > > Thanks for debugging and submitting a fix for this problem! > > Except that it's not really the most appropriate solution; that was > proposed four years ago... > > > In general, when proposing changes to the groff code base, it's best > > to open a bug report ... > > ...and Bertrand opened a (belated) ticket: > https://savannah.gnu.org/bugs/index.php?55107 > > which has shown no activity since; (so even open tickets aren't immune > to fading into obscurity).
I did try to help Keith with this previously, but I was mildly "told off" (on list) for sending my help off list. I've learned my lesson. I attach a couple of pdfs with which the current code has problems. Picture.pdf [derij@pip groff-psbb]$ ./psbb ../../Picture.pdf ../../Picture.pdf: bounding box = (0,0)..(0,0) [derij@pip groff-psbb]$ pdfbb ../../Picture.pdf Processing '../../Picture.pdf' ../../Picture.pdf: CropBox: 162.085,623.346,340.825,716.546 (178.74,93.2) This is a simple drawing with two circles and a rectangle and some transparency. croptest.pdf [derij@pip groff-psbb]$ ./psbb ../../croptest.pdf psbb:t-psbb (t-psbb.cpp):193: PDF file '../../croptest.pdf' is malformed; no trailer found [derij@pip groff-psbb]$ pdfbb ../../croptest.pdf Processing '../../croptest.pdf' ../../croptest.pdf: MediaBox: 0,0,595,842 (595,842) This file shows that it is sometimes preferable to embed a pdf in a groff document rather than convert to an eps. This is because if the picture contains transparency it is lost if you convert the picture to eps and use grops/ghostscript to produce the pdf. The file croptest-ps.pdf illustrates using Picture.pdf converted to an eps with the tool pdftops (which does a better job than convert). Also, if you zoom right in, you will see that there are some artifacts due to anti-aliasing since the conversion has rendered the vector graphics to a bitmap. > > Regarding the specific change you've proposed, there may be some > > resistance to using a grep option that's not part of the POSIX > > standard for the command. I'm not sure how widely implemented -a is, > > or what equivalent solution might be more portable. > > I would go even further ... groff should *not* be calling out to > external tools, such as grep — much less pdfinfo — from within core > code, in a manner which requires use of unsafe mode, *especially* when > core code to achieve the required functionally has been awaiting > integration for a number of years! The program I used above to check the correct bounding boxes (pdfbb) is in fact groff code already, it is using the pdf loading code in gropdf.
croptest.pdf
Description: Adobe PDF document
croptest-ps.pdf
Description: Adobe PDF document
Picture.pdf
Description: Adobe PDF document
