(REGRESSION) printable area is not taken into account correctly

[Teo]

NOTE: I have no idea which package this bug is in, I chose "cups" only because it's the only one I know related to printing.

Whenever I print anything, e.g. a pdf file from the Document viewer or a web page from Google Chrome or a document of any kind from OpenOffice (they all share the same system dialog for printing options), the top of the document is always printed outside of the printable area, and hence lost.

I use a HP Deskjet 940c and this is the printer that the system is configured to use (e.g. it is listed as Deskjet 940c when I choose it for printing).

Even if I choose "shrink to printable area" or "fit to printable area", the actual printing always exceeds the top border of the printable area.
So either the software doesn't take into account the printable area correctly, or the printable area information for this particular printer is wrong.

This is a REGRESSION in some recent or not-so-recent upgrade, as in the past I had used this very same printer on this same system and it used to print properly.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: cups 1.5.3-0ubuntu4
ProcVersionSignature: Ubuntu 3.2.0-32.51-generic 3.2.30
Uname: Linux 3.2.0-32-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 2.0.1-0ubuntu14
Architecture: i386
Date: Sun Oct 21 21:21:59 2012
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
Lpstat:
 device for DESKJET-940C: hp:/usb/DeskJet_940C?serial=MY17O671S5BH
 device for DESKJET-970C: usb://HP/DESKJET%20970C?serial=MY17O671S5BH
 device for HP-Photosmart-C6200-series: hp:/net/Photosmart_C6200_series?zc=HP586D2D
 device for Photosmart-C6200-series: hp:/usb/Photosmart_C6200_series?serial=MY7B6H51S40506
MachineType: ASUSTeK Computer Inc. M51Sn
Papersize: letter
PpdFiles:
 HP-Photosmart-C6200-series: HP Photosmart c6200 Series, hpcups 3.12.2
 Photosmart-C6200-series: HP Photosmart c6200 Series, hpcups 3.12.2
 DESKJET-970C: HP Deskjet 970c, hpcups 3.11.7
 DESKJET-940C: HP Deskjet 940c, hpcups 3.12.2
ProcEnviron:
 TERM=xterm
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-32-generic root=UUID=173acbf5-26a0-49e3-8d2b-f1c142582cbf ro quiet splash vt.handoff=7
SourcePackage: cups
UpgradeStatus: Upgraded to precise on 2012-05-17 (157 days ago)
dmi.bios.date: 12/24/2007
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 303
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: M51Sn
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: ATN12345678901234567
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr303:bd12/24/2007:svnASUSTeKComputerInc.:pnM51Sn:pvr1.0:rvnASUSTeKComputerInc.:rnM51Sn:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
dmi.product.name: M51Sn
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.

[Pavlo (pavlo-solntsev)]

I conform the bug. I used evince to print my pdf, but no luck. I also tried lpr directly with lpr -o page-range=3 -o fitplot myfile.pdf, but maybe i missed something in the command line. I didn't have this problem using acroread.

Since i don't know what information will be useful, i will be glad to present it upon request.

Best.

Pavel.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[TJ (tj)]

Affects Ubuntu 13.04 Raring amd64, with HP Deskjet 995C ink-jet using HP drivers 3.13.3 hpcups. Using the hpijs driver the top margin is correct.

That seems to confirm the issue is in the CUPS driver.

[TJ (tj)]

Added the source package "hplip" since the issue is likely in binary package "printer-driver-hpcups".

[TJ (tj)]

I tried using the driver "HP DeskJet 995C - CUPS+Gutenprint v5.2.9" - the third option for this printer - and the same top-margin crop occurs, so the common issue is CUPS.

[TJ (tj)]

Using the debugging instructions from

https://wiki.ubuntu.com/DebuggingPrintingProblems#Capturing_print_job_data

I captured the job whilst using the hpcups driver. The spooled file was PDF format. Evince (the PDF viewer) showed that the data in the spool file has an identical top-margin to the original document (probably because the PDF is passed through untouched).

However, after experimenting with changes to HWMargin and HPMechOffset in /etc/cups/ppd/DESKJET-995C.ppd on a hunch I tried printing to a different page size.

Instead of Print > Page Setup > Paper size: "A4" I used "A4 Small Margins 210x297mm". This printed the top margin precisely as expected.

For all my tests I've had Print > Page Handling > Page Scaling: "Fit to Printable Area" selected with "Auto Rotate and Centre" and "Select page size using document page size" disabled (not selected).

The difference according to the PPD file is in the page and printable area definitions:

*PageSize A4/A4 210x297mm: "<</cupsInteger0 26/PageSize[595 833]/ImagingBBox null>>setpagedevice"
*PageRegion A4/A4 210x297mm: "<</cupsInteger0 26/PageSize[595 833]/ImagingBBox null>>setpagedevice"
*ImageableArea A4/A4 210x297mm: "18 27 577 797"
*PaperDimension A4/A4 210x297mm: "595 833"

*PageSize A4.SM/A4 Small Margins 210x297mm: "<</cupsInteger0 26/PageSize[595.44 841.68]/ImagingBBox null>>setpagedevice"
*PageRegion A4.SM/A4 Small Margins 210x297mm: "<</cupsInteger0 26/PageSize[595.44 841.68]/ImagingBBox null>>setpagedevice"
*ImageableArea A4.SM/A4 Small Margins 210x297mm: "18 36 577.440002441406 832.679992675781"
*PaperDimension A4.SM/A4 Small Margins 210x297mm: "595.440002441406 841.679992675781"

That shows that "A4 Small Margins" dimensions are over-sized and "A4" are undersized. In particular the "A4" page length is 3.13mm short.

All dimensions are in points (72 points = 1 inch, 2.834... points = 1 millimetre). An A4 page measures 595.27559 x 841.889763 points.

ImageableArea values are: lower-left-x lower-left-y upper-right-x upper-right-y. Its coordinates are within the PaperDimension coordinate space.

According to other references [1] the A4 PageSize should be 595 x 842 (see table 10-4).

[1] http://docs.oracle.com/cd/E14571_01/bi.1111/b32121/pbr_uxprt004.htm

[Teo (teo1978)]

Is this so difficult to fix (or to even decide the importance of)? It's been almost 2 years and this makes something as basic as printing a hell of the problem

AND IT USED TO WORK BEFORE the regression.

A little hint for the importance:
* Renders essential features or functionality of the application or dependencies broken or ineffective

Perhaps the impact of this issue is being underestimated.