GNOME Bugzilla – Bug 303621
Incorrect formatting of simple pdf document *only* when printing
Last modified: 2005-05-18 08:45:43 UTC
Distribution/Version: Gentoo I'm the author of PDF::ReportWriter, and I've just stumbled across a printing bug in gpdf that corrupts the formatting of PDFs when printing. I'm attaching a very simple pdf that demonstrates nicely. Open the PDF in gpdf. Examine the group footers, for example the 1st one says "Total sales in January 2005: 21". Note how gpdf correctly renders the 1st column of the footer ( Total sales in January 2005: ) right-aligned, hard against the 2nd column ( 21 ). Now print the report ( 1 page is fine ... the problem exists on all pages ). The 1st column of the footer extends into the 2nd column. The problem is even more pronounced on the last page, where the 1st column of the grand total footer extends *way* into the 2nd column. Printer setup: All printers shared from a CUPS server via IPP browsing. I've tried a Ricoh AP3200 and an HP 4500C - printing to either results in exactly the same problem. I have checked against Acrobat 7 under Windows 2000, printing to the above 2 printers ( also shared via IPP ... ie no Samba in between ). Acrobat both displays and prints the PDF perfectly. I have also checked Acrobat 7 on the same Linux box as gpdf is running on, and it too produces perfect output on both printers. The PDF rendering engine I've written uses the same routing *exactly* to render normal data rows and headers / footers ... ie as far as it is concerned, there is no difference between data and footers. The only difference I can think of ( and why the data rows print fine while the footers do not ) is that the footers in this case are of a bigger font size ( 12 point instead of 10 ). I still don't see how this should affect things, particularly since the PDF renders perfectly on the screen.
Created attachment 46263 [details] PDF document that demonstrates bad formatting when printing
I can confirm the problem. But it does not relate to gpdf/gnome-print. "lpr" has the same problem. gpdf/gnome-print does not modify PDF data at all. It just sends it to the printer. I guess the filter used in order to convert PDF data to "printer data" (PostScript, PCL...) does not get your file right. Try to figure out what your printing setup (CUPS?) does with the PDF file.
Fair enough. I assume that Acrobat for Linux does this conversion to postscript and then sends *that* to the printer, right? Anyway, thanks for pointing me in the right direction. I will see what the CUPS people think about it.
That's not a CUPS bug, CUPS' pdftops filter doesn't have this problem. gpdf doesn't use CUPS' filter but xpdf. So it seems to be a bug in the postscript output of xpdf resp. poppler (xpdf fork used by evince). Evince is affected, too.