If gs displays them correctly i suggest opining a bug against the HPLIP people, they were very responsive when i approached them with a ps that ghostscript rendered correctly but they did not print correctly.

Albert, the HP people have answered in the Ubuntu bug report mentioned in the URL field telling that they will not modify their PPDs. The printers work well with PS Level 3 under Mac OS X. They think that Poppler's PS Level 3 is buggy.

We have a problem then, there can be three buggy compoments:
  * both poppler and gs have "the same bug" and the two errors team up to end up doing correct rendering
  * hp code has a bug and poppler and gs are correct

I put my bet on the second, but i have to say i'm by no means a ps expert (i'm not even a pdf expert) so i can be wrong. All i can say i'm not going to work on fixing this, sorry.

> We have a problem then, there can be three buggy compoments:

>   * both poppler and gs have "the same bug" and the two errors team
>     up to end up doing correct rendering

The gs level3 postscript is in fact level2 postscript with just a couple
of names changed:

:; diff -U0 d00022-001-gs-l2.ps d00022-001-gs-l3.ps
--- d00022-001-gs-l2.ps	2009-03-17 03:39:27.497318352 -0400
+++ d00022-001-gs-l3.ps	2009-03-17 03:39:27.980322026 -0400
@@ -9 +9 @@
-%%LanguageLevel: 2
+%%LanguageLevel: 3
@@ -14,2 +14,2 @@
-%%BeginResource: procset GS_pswrite_2_0_1001 1.001 0
-/GS_pswrite_2_0_1001 80 dict dup begin
+%%BeginResource: procset GS_pswrite_3_0_1001 1.001 0
+/GS_pswrite_3_0_1001 80 dict dup begin
@@ -63 +63 @@
-GS_pswrite_2_0_1001 begin
+GS_pswrite_3_0_1001 begin


So the fact that gs's output prints on the HP is not really relevant.

This difference between poppler’s l2 and l3 output in this case (the PDF
uses DejaVuSans and DejaVuSansMono as its fonts) is that the l3 creates
CID keyed fonts whereas the l2 does not.

So, either the HP cannot handle CID-keyed type42 fonts, or the generated
CID fonts are buggy.

In any case, it is xpdf code that is different between l2 and l3 and the
primary difference is the use of CID keyed fonts when the PDF uses them.

Stated another way, the difference is the use of pdfMakeFont16L3 rather
than pdfMakeFont16 iff the font is CID keyed in the src PDF.

-JimC

(In reply to comment #2)
> Albert, the HP people have answered in the Ubuntu bug report mentioned in the
> URL field telling that they will not modify their PPDs. The printers work well
> with PS Level 3 under Mac OS X. They think that Poppler's PS Level 3 is buggy.

Till, you're going to have to debug this further with HP.  Can you compare the PS level 3 from Mac OS X and Poppler and see how it differs?

My printer is a HP M1522NF

I'm seeing a similar bug to this too, except only one or two fonts are replaced with a square/rectangle char.

Changing postscript level within the ppd file only works around the problem.

I first noticed this with using Abiword.  Open abiword and enter the available chars of the alphabet with numbers (ie. ABC..., abc..., 123...)  and print using cups.  Even printing to file and transfering the .ps file to and printing from Windows shows this problem.

Another method to find the problem, is create or view a webpage using utf-8 and print a list of chars (similar to above).  I happened across this method by finding and randomly printing a website within Seamonkey.

www-client/seamonkey-2.3.1-2.3.3 (I haven't tested the specific site since 2.3.1 or 2.3.2??)
app-text/poppler-0.16.7
app-office/abiword-2.8.6-r1
app-text/ghostscript-gpl-8.7.1-r6

I've got threads concerning this on the abiword & cairo mailing lists.

net-print/hplip-3.11.7

Oh, hplip comes with several ppd files for this device.  Using the pcl ppd file which uses PS Level 3, does print just fine, however the file printed has some unusually high margins -- but everything here is set to print Letter and not A4 or Legal.

A little more info, the HP M1522 is a PS Level 2 with PS Level 3 emulation.  Does this matter?

(In reply to comment #7)
> A little more info, the HP M1522 is a PS Level 2 with PS Level 3 emulation. 
> Does this matter?

I don't think you are reading the specifications correctly. It is PS Level 3 emulation which means it contains a non Adobe PostScript interpreter that implements all the Level 3 features.

Have you tried a firmware update?

http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=us&prodTypeId=18972&prodSeriesId=3442750&prodNameId=3442751&swEnvOID=181&swLang=8&mode=2&taskId=135&swItem=ma-70811-4

I do have the same problem on a HP Laserjet 2605dn, as someone else already had in the original bug report.

Using level2 postscript also makes it work for me.

I've found Ubuntu (via the Launchpad Ubuntu bug), as well as the Windows HP driver seems to be forcing HP product (M1522NF here) to use PS Level 2, even though PS Level 3 is specified.

In other words, you can explicitly state within the application to print PS Level 3, but you'll get a rendered PS Level 2 file instead without you knowing it.  I kind of complained this is "hackish" to the Ubuntu Launchpad filed bug.  At most, the box should be greyed or unavailable for these products that do not support PS Level 3.

On Gentoo here, cups printer support is setup to obey the user's configuration files -- as well as probably most others except Ubuntu.  I've made note of the PS Level 3 printing problems for HP products known on Gentoo Wiki.

(Also note, irrelevant to this bug, using a the HP M1522NF fax plugged into a phone outlet using DSL with a DSL filter, the fax modem on this device seems to misinterpret the DSL signals as a fax signal sometimes, and you'll hear noise through the HP product speaker.  Hard reset is the only cure, aside from also unplugging the phone/fax line when you're not using it.)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/167.