HP Photosmart 2610 top first cm not printed

Can confirm. Get the same results with (32-bit) running a Brother HL-2070N. The suggested 2060 drivers print nothing, except some text headers followed by several blank pages.. But changing to the hl-1250 drivers prints the "diagnostic" page but with the top and bottom lines missing: can read GPL Ghostscript Version 3010 Revision 863 as the last item on the page. At least it prints!

I got the same problem with Brother HL-2140 (in hardy worked perfectly).

The problem is that probably the pstopdf filter does not determine the margins correctly.

Can you all replace your /usr/lib/cups/filter/pstopdf by the attached file? Please do not forget to make it executable

sudo chmod 755 /usr/lib/cups/filter/pstopdf

Can you print correctly now?

Till,

We've actually been looking at this the past couple of days and came to a similar conclusion. Dave or Raghu are going to email you with the information -- however it looks like you are a step ahead of us.

Do you still want our troubleshooting data?

Thanks!

Aaron

I have fixed another bug. Please test with this new version of pstopdf, not with the one of the previous comment.

Aaarin, please try whether my pstopdf fixes the problem. For me it fixes the bug definitely. If not, please send me your troubleshooting info when using the new pstopdf.

I'll try out the new filter. Problem is just, that atm I don't have the printer around. I think should be able to test within the next week. So might be a couple of days, until you get feedback from me.

Assuming it's pdftops' fault and that Till's patch fixes it. Please yell if you still have problems with the new filter. Thank you!

Update of the filter, to also cover another bug.

This bug was fixed in the package cups - 1.3.9-3

---------------
cups (1.3.9-3) experimental; urgency=low

  [ Till Kamppeter ]
  * debian/filters/pstopdf: Fixed several bugs in the pstopdf filter. First,
    removed the use of CUPS' pstops filter for inserting option settings. This
    also inserts PJL headers and then Ghostscript cannot convert the PostScript
    to PDF in the next step. Fixed also the sed magic so that the paper size
    and the margins get really read from the PPD and fixed the calculation of
    the top and bottom margins, they were exchanged. Fixes LP: #289759,
    LP: #292690, LP: #282186. Possible fix for LP #293883.

  [ Martin Pitt ]
  * debian/local/apparmor-profile: Allow dnssd backend to create various less
    common network protocols (x25, appletalk, etc.) for detection. Also allow
    it to read /proc/*/net/, which the bonjour avahi library apparently uses.
    (LP: #254022)

 -- Martin Pitt <email address hidden> Wed, 29 Oct 2008 11:41:38 +0100

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Till, I can confirm this is fixed with your final patch.

Thanks!

Aaron
HP Linux Imaging and Printing

Copied to intrepid-updates.

Ok finally got around to test this. It is fixed in part only. It properly resizes the printout now so that no text is cutoff. And also the top margin is correct now. The only problem is that the bottom margin is too big now. Should be only about half the size.

I attachted a new printout of my printertest.pdf called printer_test_new_cups.pdf (If you see faint colored bars in the pdf its because on the other side of that page I printed the standart Ubuntu Test page).

I don't now to what I should change to bug status, so I decided for new, as it's kind of a new problem.

bash, the borders you get are exactly the ones described by the PPD file.

Aaron, is it possible that the PPDs contain too wide borders? I see that my PhotoSmart C8100 and Pro B8800 both have a lower border of 36 points (=0.5 inches or 12.7 mm) defined. In non-borderless mode these printers have borders of around 5 mm all around, and in addition, they have even a borderless mode.

Aaron, should the HPLIP PPDs perhaps get modified?

bash, can you replace every "36" in the "*ImageableArea ..." lines of the PPD in /etc/cups/ppd/ by "18" and then restart CUPS with "sudo /etc/init.d/cups restart"?

The border handling in pstopdf was only introduced to get the CUPS test page coming out correctly. Should we perhaps remove it as many printer allow narrower borders than the PPD tells?

Yea that was kind off what I mean. That just the default bottom border is set to high.

Tested your suggestion and as I use A4 as default changed it to 9.72 (same as top margin) and that worked perfectly. Now top and bottom margin are the same and printout margins are pretty close to what they were in Hardy.

Till,

We can reproduce the PPD margin issue and are looking at a solution.

A

Can you edit your PPD file back to its original state (or re-create the print queue) and then replace your /usr/lib/cups/filter/pstopdf by this one:

http://www.openprinting.org/download/printing/pdf-printing/pstopdf

Do not forget to make the filter world-executable.

Does printing work correctly for you now, too?

Aaron, I have modified the filter to ignore the PPD margin settings, but you should look anyway how well the margins in the PPDs are defined and whether corrections are needed.

The margins are set incorrectly. I'm working with Raghu on a fix and possible patch for you.

Sorry about that.

A

Ok, wow quite some development since I last checked. If there's anything I can help with, like testing, just let me know and I'll be happy to do it.

bash, please read my last comment directed to you

https://bugs.edge.launchpad.net/hplip/+bug/282186/comments/22

Tried that. Still have a too big bottom margin with that. Only thing that worked so far was editing the margins directly in the PPD.

Can you send me your error_log when using the original PPD and my new pstopdf filter?

Here is the errorlog of setting up the printer with original PPD and printing the printertest.pdf using the pstopdf filter you provided.

All is going the correct way for you. You are using the correct filter and PPD file. It seems that the hpijs driver is clipping the borders according to the PPD settings.

If I run a command line like

cupsfilter -m application/vnd.cups-pdf -p /etc/cups/ppd/Photosmart_C8100_series.ppd /usr/share/system-config-printer/testpage-a4.ps > output.pdf

and display the output with evince, the borders are cut with the original pstopdf and not touched with my new pstopdf. The command line runs the filter chain without the final driver step (in our case pstopdf and pdftopdf). It shows that pdftopdf does not clip the margins.

bash, for me the Ubuntu test page comes out correctly (not clipped at the lower border) when printing with my PhotoSmart C8100 with original PPD file.

bash, I have seen that you have printed printertest.pdf with the Adobe Reader. The cutting which you have now comes most probably from the Adobe Reader. It reads the PPDs from the CUPS queues and uses the data to offer you paper size, input tray and duplex options (in the "Proprties" sub dialog of the printing dialog. It also uses the margin information from the PPD file for adjusting the printout size. This is controlled by the "Page Scaling" option in the "Page Handling" group. You have probably selected "Fit to Printable Area" or "Shrink to Printable Area", which makes Adobe Reader scaling or clipping the document into the printable area according to the PPD file. So the output of Adobe Reader does not put anything into the last 12.7 mm of the page. As you know that the borders in the PPD are wrong, choose "None" for "Page Scaling" and Adobe Reader will output the file in original size without clipping. Or edit the PPD file to get the best from the "Fit to Printable Area" and "Shrink to Printable Area" settings.

Aaron, here you see that it is very important that the PPD files represent the exact capabilities of the hardware. With the too conservative margins functions like "Fit to Printable Area" and "Shrink to Printable Area" (and also number-up or fitplot in CUPS) will not give the desired results.

intrepid fix: http://bazaar.launchpad.net/~ubuntu-core-dev/cups/intrepid/revision/575

Accepted cups into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Till, tried printing the Ubuntu Test page and it indeed prints out now correctly. Lower border is not missing anymore so I guess that pstopdf filter did do the trick. Same for Adobe Reader printing with resize set to "None". As for wrong margins in the PPD: Will that be fixed/looked into/worked on?

One more thing just for curiosity: If I print the printertest.pdf from Adobe Reader set to "None" the printout still ends up with 5mm borders around. AFAIK the Photosmart 2610 support borderless printing. Since I'm not to knowledgable about the whole printing options of the HP driver, you happen to know the command/prefix/setting to print a page borderless?

The wrong margin settings in the PPDs will be taken care of by the HPLIP developer team at HP.

The 5 mm borders you get are indeed there because the printer is not set to full-bleed mode. To set it to full-bleed, you must set the "Quality" option to one of the full-bleed modes (this option is not reachable by the printing dialog of Adobe Reader, use system-config-printer for changing the default). Note that for getting printouts which go perfectly up to the borders the printer "oversprays" more or less 3 mm all around. Therefore the driver scales up the printout a little bit. This means that a little bit gets lost on the borders. For most photos this is no problem. But for putting text to touch the edges of the paper but not to run over them the full-bleed mode is not suitable.

bash, do not forget to test the package from -proposed.

Ok here are my findings. First of all the packages didn't show up in update-manager although a lot of other updates from proposed did. So I pulled them directly from the archive. Here are the files I got: cups, cups-bsd, cups-client, libcups2, libcupsimage2. All are version 1.3.9-7 for amd64. If I forget anything please tell me.

So here is what I got printing out: After updating & restarting cups I tried printing the Ubuntu test page and the missing bottom margin was back (All the ------ lines at the bottom are missing). Replaced the pstopdf with the one you provided yesterday and restarted cups. Tried printing the page again and now it works, all bottom lines are printed perfectly. So the update itself didn't fix anything. Replacing pstopdf with the one you gave me does.

The package you have loded is not from proposed. It is from Jaunty and was uploaded before I created the fixed pstopdf. The correct package has the version number 1.3.9-2ubuntu2.

Sorry, version number will be 1.3.9-2ubuntu3.

Thanks for the update. Is there a chance providing those packages as 64bit as well? Or are they still being compiled? Because I can only find i386 debs which are more or less useless on my 64bit machine.

Win! I can report that with the 1.3.9-2ubuntu3 packages the Ubuntu Test Page gets printed correctly. All margins are correct and all border lines are printed. So it looks like on this front everything is good. Just remain the strange margin settings in the PPD itself, but at least I know how to change them now manually until a fix is released for that part.

This bug was fixed in the package cups - 1.3.9-2ubuntu3

---------------
cups (1.3.9-2ubuntu3) intrepid-proposed; urgency=low

  * debian/local/filters/pdf-filters/filter/pdftoraster.cxx: Fix include path
    of image.h, to fix FTBFS if libcupsimage-dev is not installed.

cups (1.3.9-2ubuntu2) intrepid-proposed; urgency=low

  [ Till Kamppeter ]
  * debian/local/filters/cpdftocps: The cpdftocps filter did case-sensitive
    checking for CUPS options to keep them away from the pstops filter. CUPS
    treats such options case-insensitive, so in some cases CUPS options got
    applied twice (LP: #299707).
  * debian/local/filters/pdf-filters/filter/pdftoraster.cxx: Fix handling of
    CMYK color space. Patch taken from upstream:
    http://svn.sourceforge.jp/view/pdftoraster/trunk/src/pdftoraster.cc?root=opfc&rev=850&r1=848&r2=850
    (LP: #294671)
  * debian/filters/pstopdf: Do not supply the margins from the PPD to the
    ps2pdf process, as this breaks full-bleed printing and is also disturbs
    the printing if PPDs have too conservative margin definitions. (LP: #282186)

  [ Martin Pitt ]
  * rootbackends-worldreadable.dpatch: Apply the same relaxed permission check
    to cups-deviced, so that backends installed as 0744 don't disappear from
    printer detecttion. This unbreaks the ipp/http and lpd detection.
    (LP: #275407, Debian #503644)
  * debian/rules: Install the serial backend with 0744 permissions to make it
    run as root, since /dev/ttyS* are root:dialout and thus not accessible as
    user "lp". Thanks to Chanoch (Ken) Bloom. (part of #506181, LP: #154277)
  * debian/control: Update Vcs-* for intrepid branch.

 -- Martin Pitt <email address hidden> Fri, 21 Nov 2008 13:13:14 +0100

Copied to intrepid-updates.

This bug was fixed in the package cups - 1.3.9-8

---------------
cups (1.3.9-8) experimental; urgency=low

  * debian/local/filters/pdf-filters/pdftopdf/P2POutputStream.cxx,
    debian/local/filters/pdf-filters/pdftopdf/P2POutputStream.h: Removed
    an endianess dependency from the pdftopdf filter, so that it also
    works on non-PC platforms like PowerPC (LP: #271350).
  * debian/filters/pstopdf: Do not supply the margins from the PPD to the
    ps2pdf process, as this breaks full-bleed printing and is also disturbs
    the printing if PPDs have too conservative margin definitions (LP: #282186).

 -- Martin Pitt <email address hidden> Wed, 26 Nov 2008 15:14:57 +0100

Till,

With the latest update it seems the the printer margins are getting set to 0x0 when they should be 0.125x0.125 depending on the ppd.

Thoughts? We can reproduce it here and I think it's a pstopdf thing?

A

Aaron, this is intended, to not break full-bleed jobs and to get the best even in case the PPD has wrong margin info. I know that it breaks the CUPS test page, but one should not use the CUPS test page in a PDF printing workflow anyway. Use the Ubuntu test page /usr/share/system-config-printer/testpage-a4.ps instead.

Till,
  This also breaks the HPLIP test page too. It has the edges cut off as in
the Cups test page. I tried this on 2 different LaserJets with the same
results.
  I am also confused by your statement that people shouldn't use the CUPS
test page. I alerted Aaron to this issue with the CUPS test page because
it's part of my own test cycle. I printed it using the "Print Test Page"
button on the CUPS web server page.

Paul

On Wed, Nov 26, 2008 at 1:57 PM, Till Kamppeter <email address hidden>wrote:

> Aaron, this is intended, to not break full-bleed jobs and to get the
> best even in case the PPD has wrong margin info. I know that it breaks
> the CUPS test page, but one should not use the CUPS test page in a PDF
> printing workflow anyway. Use the Ubuntu test page /usr/share/system-
> config-printer/testpage-a4.ps instead.
>
> --
> HP Photosmart 2610 top first cm not printed
> https://bugs.launchpad.net/bugs/282186
> You received this bug notification because you are a member of HP Linux
> Imaging and Printing, which is subscribed to HPLIP.
>

The CUPS test page is not simply a representation of a document to be printed, like the PostScript files which you get from applications, it is a PostScript program (note that PS is a programming language like Python or Perl), The CUPS test page (and also the HPLIP test page as it is a hacked CUPS test page) asks the PostScript interpreter for the page size, resolution, margins, interpreter version, ... and then it draws its content in the size which it got from the interpreter. In the PDF workflo everything is converted to PDF before further processing. This also includes the CUPS test page, making it executed by a PostScript interpreter (Ghostscript called by the pstopdf CUPS filter). Normally the CUPS test page is designed to be executed on the rasterizing process for the printer, either in the printer itself or by the last CUPS filter step where Ghostscript is called together with the printer driver.

As one usually sends normal print jobs and not test pages we must design the filters to get the best out of normal print jobs. Test pages are not sent often and they should be designed to resemble normal documents,, so a PDF file looking more or less like the Ubuntu test page would be a good solution.

Till,
if I understand your above comment correctly,
does it mean that via the PDF workflow,
true PostScript programs do no longer work as before
(i.e. are executed on the final PostScript interpreter)?

If yes, it is no solution to replace test-pages with
whatever appropriate PDFs (can a single generic PDF
determine the actual imageable area of the device?).

The solution would be an option setting for the
PDF workflow so that true PostScript programs
still work as before.
But I wonder if this is possible at all with the
PDF workflow.
Is it perhaps possible to bypass certain steps of the
PDF workflow - e.g. by setting an appropriate
document-format option for example something like
"-o document-format=application/vnd.cups-postscript"
so that true PostScript programs still work as before?

Yes, with the option "-o document-format=application/vnd.cups-postscript" you override the PDF workflow and can get PostScript programs get directly executed by the PostScript printer or the rasterizing instance of Ghostscript for non-PostScript printers. Only disadvantage is that both pstops and pdftopdf get overridden and so page management options, like N-up, selected pages, ... will not get obeyed, but with a PostScript program you probably do not want to use such options. Note also that it only works for PPD files without "cupsFilter" line or having at least one "cupsFilter" line for the application/vnd.cups-postscript input format. If in the future pure PDF printer driver solutions come up, execution of PostScript programs by the rasterizer will not be possible any more.

This way you can run arbitrary PostScript programs on your printer, for

- examining the printer's capabilities, with the CUPS test page and also with the code snippets in manufacturer-supplied PPDs which server for polling the printer default of an option (for the latter you would need some form of getting the printer's answer back to the sender of the job, this can perhaps disqualify CUPS from sending such jobs).

- using the printer as a compute server and CUPS as a compute job queuing system

- rewrite CUPS in PostScript and "print" this file to make the printer configuration-less in CUPS networks

But PDF is the better format if you simply want to print a document on your printer ...

Then I think that HPLIP (and all other printer setup tools)
which send a PostScript program as printing test page
should submit their test page print jobs using
"-o document-format=application/vnd.cups-postscript"

A positive sude-effect is that this way document manager options
like "n-up" and "fitplot" (which might be preset for a print queue)
are ignored which is wanted for a real test page printout.

For a real PostScript printer a PostScript test page program
might be even submitted using "-o raw" to ignore any possible
"cupsFilter" setting (those exist in particular PPDs even for real
PostScript printers).

Of course PDF is the better format for usual documents.
If in the future pure PDF printer driver solutions come up,
the default test page should be also an appropriate PDF.

Till, I have a question:
In comment "Till Kamppeter wrote on 2008-11-26:" you wrote
--------------------------------------------------
one should not use the CUPS test page in a PDF printing workflow anyway.
Use the Ubuntu test page /usr/share/system-config-printer/testpage-a4.ps instead.
--------------------------------------------------
I assume there is also a testpage-letter.ps but what do you send to the printer
when its default paper size is neither A4 nor Letter but e.g. A3 or Legal
and/or when the printer cannot print on A4 or Letter (e.g. because it is
a small-format photo output devide or a label printer or whatever else).

I think the attempt to provide ready-made test pages is futile
(except the test page is a true PostScript program).

The real solution would be that the printer setup tool autogenerates
the test page (in PostScript or perhaps even better in PDF format)
during runtime according to the current actual settings for
DefaultImageableArea, ColorDevice/DefaultColorSpace,
and DefaultResolution of the print queue.

Printing a PostScript program with "-o document-format=application/vnd.cups-postscript" is only an interim solution for the time being as long as the rasterizing process (printer driver, PostScript printer) can still be done with PostScript input. Ass son as the PDF workflow gets common and drivers come up which take only PDF as input thios approach will stop working.

The real solution is a utility which generates a test page dependent on paper size, margins, color/bw, resolution, ... and perhaps even allows to choose between PostScript and PDF output. This could be used by all printer setup tools.

The tool could even be a CUPS filter which has "application/testpage" as input format and "application/pdf" as output format. The input file (which is recogized by a *.types rule) could simply contain nothing more than a magic string:

### TESTPAGE ###

The test page is generated then based on PPD defaults and command line options. The content of the input file is ignored, the file serves only to trigger test page printing.

Printer setup tools then simply do something like "echo '### TESTPAGE ###' | lpr -P <printer>" to print a test page.

Regardless that it is about HPLIP here,
FYI:

Printing /usr/share/cups/data/testprint.ps with
"-o document-format=application/vnd.cups-postscript"
does not work for me for the Gutenprint driver, see
https://bugzilla.novell.com/show_bug.cgi?id=467877#c2

I use CUPS 1.3.9 and a HP LaserJet 1220 with this Gutenprint PPD:
"HP LaserJet 1220 - CUPS+Gutenprint v5.0.2"

Printing /usr/share/cups/data/testprint.ps without
"-o document-format=application/vnd.cups-postscript"
rsults those filters called (see /var/log/cups/error_log):

Started filter /usr/lib/cups/filter/pstops
Started filter /usr/lib/cups/filter/pstoraster
Started filter /usr/lib/cups/filter/rastertogutenprint.5.0

and a succesful printout of the CUPS test page.

Printing /usr/share/cups/data/testprint.ps with
"-o document-format=application/vnd.cups-postscript"
rsults those filters called (see /var/log/cups/error_log):

Started filter /usr/lib/cups/filter/pstoraster
Started filter /usr/lib/cups/filter/rastertogutenprint.5.0

but no printout of the CUPS test page.

You can download the driver for the HP Deskjet 2630 in : https://file-hpdrivers.com/hp-photosmart/