CUPS test page does not display correct print job data. pstopdf filter needs improvements, test page needs some changes

Looking at the different test page output I just realized that on intrepid - no matter
what driver I select - it always reports "Product: GPL Postscript", while on the correct
output from hardy/cups 1.3.7 it correctly reports "Product: Brother MFC-7820N"

here is /var/log/cups/error_log

Imageable area is wrong under cups 1.3.8 on intrepid.

page size: 209.9x297.0 (mm) -- should be 201.5x288.5 (mm)
lower-left: 0.0x0.0 (mm) -- should be 4.2x4.3mm
upper-right: 209.9x297.0 (mm) -- should be 205.7x292.8 (mm)
resolution: 720x720dpi -- should be 600x600dpi

This is a problem of the printer driver. Reassigning ...

The brother drivers included in hardy and intrepid are exactly the same. There is not changes. Could this be a bug in the driver that cupsys did tolerate in the past, but not anymore? Or is that a cupsys problem?

I must have been blind, but I just realized that it seems like cups is
not using the right driver at all - the printer test page list:

Product: GPL Ghostscript
Serial #: 42

when it should really be:

Product: Brother-MFC-7820N
Serial-#: 888078254

The cups web interface of course reports that the printer is using the "Brother MFC-7820N BR-Script3"
driver, as configured it to.

I am certainly no cups-expert, but this doesn't look like a bug in brother-cups-wapper-laser to me.

Sorry, did not see that this printer is PostScript, reassigning to system-config-printer, as it seems that the printer got set up with the wrong PPD file.

Please attach the PPD file /etc/cups/ppd/<print queue name>.ppd to this bug report.

Closing CUPS task, as printer was probably set up with system-config-printer here. Reopen the CUPS task if the CUPS web interface also selects a wrong PPD if you set up a queue for your printer with it.

The printer has NOT been configured with system-config-printer but using the cups
web interface.

The ppd file in /etc/cups/ppd is correct - it is the brother printer file. In fact
I even tried copying the ppd file from my working hardy installation over this one which
had no effect (and as been mentioned before they should be the same anyhow)

For completeness-sake i attached the ppd file, but there is nothing much
to see there, it is the ppd from the brother wrapper package. Yet printing
results in a pretty screwed up test-page where it reports a Ghostscript printer
instead of the Brother driver and wrong imageable dimension.. which I find
rather puzzling.

I hope I am not doing something overly stupid without realizing it, but I wouldn't
know what that should be. As I said.. I set up the printer the same way
on a hardy installation and it works just fine.

I have found out what the issue is:

We have switched the printing workflow from PostScript to PDF as standard print job format (see https://blueprints.edge.launchpad.net/ubuntu/+spec/pdf-as-standard-print-job-format). This means that jobs which reach a CUPS queue and which are not in PDF format are converted to PDF before further processing. After processing, the jobs get converted to the format needed by the printer, in case of a PostScript printer back to PostScript. See the Blueprint to know why we do this.

PostScript is not a simple vector graphics format. It is a programming language, like Perl or Python. So one can make it generating the desired print output in very different ways. This leads for example to the case that some applications output PostScript on which you cannot separate the pages so that you can re-order them for ptinting booklets or simply print only a part of the pages. This is one of the reasons why we want to use PDF as standard print job format.

Another example for using the capabilities of PostScript as a programming language is the CUPS test page. It asks the PostScript interpreter for certain data of the output device and writes the results into the output. This only works if the PostScript interpreter which renders the test page is the actual rasterizer for the printer and not a file converter which renders the PostScript into an intermediate vector graphics format. In our PDF printing workflow the test page is converted to PDF with the interpreter not knowing the resolution and the margins of the printer. Therefore the test page shows wrong margin and resolution data and it draws the black border rectangle at the wrong place. This means that the CUPS test page is completely unsuitable for the PDF printing environment. We should take it from the distro. The test page should be a scalable PDF file.

ion, can you modify the pstopdf filter so it propagates the job's page size, resolution, and margins into the conversion process?

At first find the settings for the options PageSize and Resolution. First via the fifth command line argument and if not specified there via the PPD's default settings. Get width and height of the page via the *PaperDimension line corresponding to the PageSize setting and the margins via the appropriate *ImageableArea line in the PPD.

Add appropriate option settings to the ps2ps and ps2pdf calls

ps2pdf -dDEVICEWIDTHPOINTS=XXX -dDEVICEHEIGHTPOINTS=YYY -rXRESxYRES ...

For the margins it is more complicated as a PostScript variable of a complex data type (array) has to be defined. This is not possible on the command line. One has to inject PostScript code, for example with a command line like this:

( echo -en '%!\n<</.HWMargins[50 50 50 50] /Margins[0 0]>>setpagedevice\n'; cat /usr/share/cups/data/testprint.ps ) | ps2pdf -dDEVICEWIDTHPOINTS=800 -dDEVICEHEIGHTPOINTS=1200 -r600 - testprint.pdf

With all this we get at least the left box of the test page right and we assure a clean conversion independent which paper size and resolution is requested for the job and whether the incoming PostScript already comes in the desired page size and defines it well and we are also prepared if the conversion process does any optimization for the final printing resolution.

ion, pitti, the test page itself still needs to be modified, as the content of the right box is wrong. Users of a PostScript printer would expect model name and serial number of their printer there. This info cannot be pulled from the printer by the pstopdf filter. So these items the test page should not show any more.

I would like to emphasize that this the problems I am having are by no means limited
to the cups test page. No document is printed correctly. image data is shifted beyond the top
border of the paper, ie top part of any printed document is cut off.

I get this when using the exact same ppd which works fine on my hardy installtion so I
doubt this is a Brother printer driver. This bug report is now focused only on the test page
but there are problems beyond that.

http://heh.fi/patches/cups/01-pstopdf-ppd-settings

Till, can you please review Johan's patch? It seems pretty complicated, thus I'd appreciate more eyes/tests on it. Thanks!

I have checked it now and it works as advertized on real printers. The "bc" dependency is really needed as page sizes and margins can be given as floating point numbers, whereas the shell's "$[...]" construct is only capable of calculating with integers. "bc" is usually already installed, so there will be no new package blowing up the desktop CDs.

I have committed the package to the SVN.

Current state now is that for all PPDs with a "Resolution" option or at least with a "*DefaultResolution: ..." entry the left hand side info box on the CUPS test page is absolutely correct. The right hand side info box will always show Ghostscript, also if the printer is a native PostScript printer used with a Ghostscript-less PPD file.

Suggestion for further improvement: Let cpdftocps also take paper size, margins, and resolution into conversion process, simply to assure that the conversion is done the best way possible.

Forget about my "Suggestion for further improvement" in the last comment. It is not needed as cpdftocps calls only CUPS filters and not Ghostscript directly.

This bug was fixed in the package cups - 1.3.8-10

---------------
cups (1.3.8-10) experimental; urgency=low

  [ Martin Pitt ]
  * rootbackends-worldreadable.dpatch: Do not run backends as root if they are
    group or world writable (this is by and large a paranoia fix, though).
  * dont-chown-symlinked-ssl.dpatch: Replace patch with the upstream committed
    version, which is more general.
  * debian/control: Package development moved to bzr, update Vcs- tags.
  * cupsaccept.dpatch: Replaced with the more comprehensive solution upstream
    committed to 1.4 trunk. Removed debian/cups-client.links, since the links
    are now installed by upstream. Adapt manpage-translations.dpatch
    accordingly.
  * Move installation of D-BUS configuration files from debian/rules to
    debian/cups.install.
  * debian/libcups2-dev.install: Add missing sidechannel.h.

  [ Johan Kiviniemi ]
  * debian/filters/pstopdf: Apply PPD settings (resolution, page size, page
    margins) to the conversion (LP: #263049).
  * debian/control: cups Depends: bc (for margin calculation).

 -- Martin Pitt <email address hidden> Thu, 11 Sep 2008 13:43:34 +0200

Possible regression in 1.3.9-2 ?
Not sure if it is the same bug, but I at least experience the exact same problem since I upgraded Hardy to Ijtrepid two days ago.
I had the same problem earlier (pre-Hardy), but all got fixed in Hardy. Now in Intrepid the problem resurfaced.

Different (most but not all) tests show the printeable arease scrolled upwards, cutting of a header and leaving soms blank space on the bottom. Different tests, including the cups test page, shows a difference of about 2-3 cm

some apps where the problem shows up:
- test page through cups web interface
- test page through gnome config panel
- PDF files, both via Document Viewer, and acroreader
- openoffice
- gedit

seems not affected:
- printing from firefox

cups packages are at 1.3.9-2

I have the same problems since intrepid, current cups is 1.3.9-2ubuntu1.
May I help with any information?

Please reopen the bug.

derdom, Serge, your problem is not this bug. Please open a new bug, also telling which printer you are using, attaching the PPD file, and the troubleshooting file which you get when using the "Help"/"Troubleshooting" function of system-config-printer.

I already filed a new #293690
I'll look into and add the extra info you requested.

derdom, Serge, your problem is most probably bug 293832.