Re: Problems with .PDFPIC caused by pdfinfo

[Deri]

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