Ubuntu

hp laserjet postscript text print does not print some characters

Reported by rbmorse on 2008-10-03
40
This bug affects 4 people
Affects Status Importance Assigned to Milestone
HPLIP
Undecided
Unassigned
Poppler
Confirmed
High
cups (Ubuntu)
Undecided
Unassigned
Intrepid
Undecided
Unassigned
foomatic-db (Ubuntu)
Medium
Unassigned
Intrepid
Undecided
Unassigned
gtk+2.0 (Ubuntu)
Medium
Unassigned
Intrepid
Undecided
Unassigned
hplip (Ubuntu)
Medium
Unassigned
Intrepid
Undecided
Unassigned
poppler (Ubuntu)
Medium
Unassigned
Intrepid
Undecided
Unassigned

Bug Description

Binary package hint: hplip

Intrepid Beta (fresh install)
HPLIP 2.8.7-0ubuntu3

Symptoms: Printing from a text based application like text editor to my HP ColorLaserJet 2605Dn (using the recommended Postscript driver) results in certain characters being represented as empty squares. The number "8", the "<" and ">", the "/" character and the eol char seem to be most affected.

Changing the document's font does not correct the problem, but it may cause different characters to be substituted with boxes.

My other printer, which is an HP P1215 inkjet (non-Postscript) works normally.

The Laserjet works fine in Hardy. I tried copying the .ppd from hardy over the .ppd installed with Intrepid, but the problem remains. (note: subsequent testing indicates this para is incorrect. I had forgottent to restart CUPS. The Hardy .ppd does in fact correct the problem as noted below).

If I set the Laserjet to use the generic Postscript driver I lose some control features, but what does print is correct and the problem does not manifest.

To repeat the issue:

open text editor and enter the string

***this is a printer system test 1234567890abcdefghijklmnopqrstuvwxyz/.,<>?***

print the document. The "8" character, the "/" character, the ">" character and the eol character will be represented by a hollow square. I don't see any equivalent in the Latin character set chart.

rbmorse (rbmorse) wrote :

I have isolated the cause of this to a problem in the openprinting driver file for the HP ColorLaserJet 2605 printer:

/usr/share/ppd/openprinting/HP/HP_Color_Laserjet_2605.ppd.gz

If you have a Hardy installation available, the workaround is to use the .ppd file that came with 8.04:

1. Open HPLIP and remove (uninstall) the printer
2. Open your browser and navigate to localhost:631 to enter CUPS. Click "printers" and remove the 2605 if it still shows as present. If prompted for username and password, use your normal Ubuntu username/password. Close the browser window.
3. Open a terminal window and restart CUPS (sudo /etc/init.d/cups restart)
4. copy the Hardy version of the 2605.ppd file (HP_Color_Laserjet_2605.ppd.gz) to /usr/share/ppd/openprinting/HP/
5. Open the HPLIP utility and install the printer from there. That should update CUPS at the same time.
6. test.

Alternate workaround if you don't care about doing things correctly:

In your Hardy installation, find the file /etc/cups/ppd/HP_Color_Laserjet_2605dn.ppd. Copy that file to your Intrepid's /etc/cups/ppd/HP_Color_Laserjet_2605dn.ppd (replacing the existing file) and restart cups ( sudo /etc/init.d/cups restart).

Till Kamppeter (till-kamppeter) wrote :

What you are doing is only replacing your printer's PPD file by the version which came with Hardy.

Can you please attach this PPD file (and also the current non-working Intrepid one) to this bug report? Then one could compare and find out which change broke the workflow.

Changed in hplip:
status: New → Incomplete
importance: Undecided → Medium
milestone: none → ubuntu-8.10
status: New → Incomplete

Till Kamppeter wrote:
> What you are doing is only replacing your printer's PPD file by the
> version which came with Hardy.
>
> Can you please attach this PPD file (and also the current non-working
> Intrepid one) to this bug report? Then one could compare and find out
> which change broke the workflow.

Sure. the two files are attached. I have altered the names
to reflect the Ubuntu from which they came, merely deleting
the distro version will restore them to "as shipped" condition.

The files are from their respective
/usr/share/ppd/openprinting/HP/

directories.

>
>
> ** Also affects: hplip
> Importance: Undecided
> Status: New
>
> ** Changed in: hplip
> Status: New => Incomplete
>
> ** Changed in: foomatic-db (Ubuntu)
> Sourcepackagename: hplip => foomatic-db
> Importance: Undecided => Medium
> Status: New => Incomplete
> Target: None => ubuntu-8.10
>

Till Kamppeter (till-kamppeter) wrote :

There is no difference in the PPDs concerning the PostScript code which gets sent to the printer. Only differences are the removal of unneeded UIConstraints lines and the addition of a missing colon. So it is strange that the PPD coming with Intrepid breaks the printing.

Can you switch back to the Intrepid PPD and see whether the bug appears again?

rbmorse (rbmorse) wrote :

On Fri, 2008-10-10 at 07:25 +0000, Till Kamppeter wrote:
> There is no difference in the PPDs concerning the PostScript code which
> gets sent to the printer. Only differences are the removal of unneeded
> UIConstraints lines and the addition of a missing colon. So it is
> strange that the PPD coming with Intrepid breaks the printing.
>
> Can you switch back to the Intrepid PPD and see whether the bug appears
> again?
>
Hi. Thank you for your assistance.

Yes, switching to the .ppd file that ships with Intrepid causes the
problem to manifest. I received an update to HPLIP yesterday that also
caused the problem to manifest, but replacing Interpid's .ppd with
Hardy's .ppd corrects the problem.

I should reiterate that I see the problem when printing documents from
Text Editor and Gnucash's check printing. I haven't really tested any
other applications, but will do so if you think that might be helpful.

Ron Morse

Till Kamppeter (till-kamppeter) wrote :

Try the following:

Redirect your print queue to a file:

cupsctl FileDevice=yes
lpadmin -p <print queue name> -v file:/tmp/printout.ps

Then print a file which causes the problem and attach the resulting /tmp/printout.ps to this bug report.

Switch to the other PPD file but keep your print queue pointing to /tmp/printout.ps.

Print the same file again, and attach the new /tmp/printout.ps. They must be different, as one works on the printer, the other not.

Make sure that when you attach the files that you tell which one of them is done with the Hardy PPD and which one with the Intrepid PPD.

rbmorse (rbmorse) wrote :
  • hardy.ps Edit (37.0 KiB, application/postscript; name="hardy.ps")
  • intrepid.ps Edit (42.0 KiB, application/postscript; name="intrepid.ps")

On Fri, 2008-10-10 at 13:58 +0000, Till Kamppeter wrote:
> Try the following:
>
> Redirect your print queue to a file:
>
> cupsctl FileDevice=yes
> lpadmin -p <print queue name> -v file:/tmp/printout.ps
>
> Then print a file which causes the problem and attach the resulting
> /tmp/printout.ps to this bug report.
>
> Switch to the other PPD file but keep your print queue pointing to
> /tmp/printout.ps.
>
> Print the same file again, and attach the new /tmp/printout.ps. They
> must be different, as one works on the printer, the other not.
>
> Make sure that when you attach the files that you tell which one of them
> is done with the Hardy PPD and which one with the Intrepid PPD.
>
The two files are attached, renamed to identify the version of the .ppd
file with which they were produced.

I used the same source file for both, and the errors produced with the
intrepid version of the .ppd consist of a "box" character substituted
for the "f" character in the Page header (1 o 1) and the three "8"
characters on the second line also print as "box" characters.

The hardy version of the .ppd produces correct output.

RBM

rbmorse (rbmorse) on 2008-10-11
description: updated
rbmorse (rbmorse) wrote :

After installing the latest updates to the openprinting.ppd package the previously functional workaround of substituting the .ppd file from the Hardy repository now produces identical output to the latest .ppd file in the Intrepid repository...i.e., when printing from a text-based application certain characters are not printed correctly.

Setting the printer to use the generic postscript driver via gnome-control-panel results in correct output, however certain printer functions are not available with this driver.

Till Kamppeter (till-kamppeter) wrote :

Can you tell exactly which text editor you have used?

rbmorse (rbmorse) wrote :

On Tue, 2008-10-14 at 07:03 +0000, Till Kamppeter wrote:
> Can you tell exactly which text editor you have used?
>
The problem manifests with applications that work in "text mode," such
as:

Gedit 2.24.0
Printing checks with Gnucash 2.2.6 and 2.2.7 (but, reports are fine)
Printing mail from Evolution 2.24.0.
Kate
Krusader (printing a file using Krusader's text editor)

I can test some other applications, if it will be of assistance

Ron Morse

rbmorse (rbmorse) wrote :

I see this report is still listed as "incomplete." What information do you require?

rbmorse (rbmorse) wrote :

If I install a new instance of the 2605DN printer using the HP Color LaserJet 4500 openprinting driver the problem does not manifest, and works as expected. This may indicate the reported problem may lie somewhere in the 2605DN .ppd

I have a similar problem with my printer using the most recent postscript driver.

OS: Ubuntu 8.10 32bit desktop
Printer: HP Laserjet 4100 (with duplexer/network/trays)
Driver: HP LaserJet 4100 Series v.3010.107 Postscript
Software: gedit (I didn't test other software yet)
Problem: some characters are printed as empty boxes. Not necessarily the same characters as the user above. I seem to have problems with at least the characters 'v', '?' and 'A'.

Switching to the non-postsript driver (HP LaserJet 4100 series Foomatic/hpijs, hpijs 2.8.7.3 - HPLIP 2.8.7) fixes the problem. In the past I didn't have any problems with the postscript-driver. I'm not sure when the problems started. Not too long ago, that's for sure.

ubunturox (ubunturox-kk) wrote :

I can confirm on HP LaserJet 8150DN. 8.10 32-bit

Can you all please do the following:

Return to the PPD file which gives the broken printouts. Then do

cupsctl LogLevel=debug
cancel -a

and then print a job which gives the broken characters on the printout. Directly after the job got printed, do

sudo cp /var/log/cups/error_log ~
sudo chmod 777 ~/error_log

and then attach the ~/error_log file (error_log in your home directory) to this bug report.

Can you also do the following:

cupsdisable <name of your print queue>
cancel -a

Print a job (will be held in queue) and then

sudo cp /var/spool/cups/d* ~
sudo chmod 777 <the d* file you have copied>
cupsenable <name of your print queue>

If the print out comes out broken, attach the d* file ofyour home directory to this bug report.

rbmorse (rbmorse) wrote :

Hi Till.

Error log attached as requested. Please let me know if I can do anything else.

Ron Morse

Can you also do the second part which I have asked for:

cupsdisable <name of your print queue>
cancel -a

Print a job (will be held in queue) and then

sudo cp /var/spool/cups/d* ~
sudo chmod 777 <the d* file you have copied>
cupsenable <name of your print queue>

If the printout comes out broken, attach the d* file of your home directory to this bug report.

rbmorse (rbmorse) wrote :

Here's the second part. The "d" file was totally correct, however the paper print that completed when I enabled the queue showed the flaw. I'm attaching a scan of the paper print. I still have the "d" file, if you need it.

Can you please attach the "d" file, I will need it to reproduce the bug.

rbmorse (rbmorse) wrote :

No problem. Thank you for your assistance.

Do you want me to post the requested output here too? I'd be more than willing to help. I did some more tests today with the following results on my HP LaserJet 4100 printer, connected via JetDirect:

- HP LaserJet 4100 Postscript PPD fails to print correctly
- HP LaserJet 4100 MFP Postscript PPD fails to print correctly
- HP LaserJet 4200 Postscript PPD fails to print correctly
- HP Color Laserjet 4500 Postscript PPD SUCCEEDS!! to print correctly (as mentioned by rbmorse)
- HP LaserJet 4050 Postscript PPD SUCCEEDS!! to print correctly

Since the LaserJet 4050 is very similar to the LaserJet 4100 I own I'll use the 4050-PPD for now. But if I can be of any help to sort these problems out I'd be more than willing to help.

To easily reproduce the problem do (d00022-001 is PDF printing output of gedit, captured from the spool directory of CUPS):

wget http://launchpadlibrarian.net/21294491/d00022-001
pdftops -level3 -paper A4 d00022-001 > l3.ps
pdftops -level2 -paper A4 d00022-001 > l2.ps
pdftops -level2 -noembtt -paper A4 d00022-001 > l2noembtt.ps

Then send the files unfiltered to a PostScript printer from HP (Ghostscript displays all files correctly on the screen). The l3.ps prints some characters as squares, the l2*.ps print correctly. This means that something is broken with the Level 3 PostScript output, at least for HP printers.

The HP LaserJet P3005 even crashes on the faulty PostScript Level3 output of pdftops.

See

http://launchpadlibrarian.net/21292602/img001.jpg

for the broken output of l3.ps.

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.

There are the following problems:

1. PPDs for PostScript level 3 show the problem and for PostScript level 2 not. The difference occurs when the data runs through the pdftops CUPS filter. This filter uses the /usr/bin/pdftops utility of Poppler and in case of PostScript level 2 and no "TTRasterizer" specified in the PPD the option "-noembtt" gets added. With this "-noembtt" the output is correct. In this case certain fonts from the PostScript interpreter of the printer are used. Without "-noembtt" embedded fonts from the file are used.

So this means that either the PDF with embedded fonts coming from the app is faulty, or a font which got embedded is broken.

2. The PPD parser of CUPS treats the Hardy PPD for the Color LaserJet 2605 as PostScript level 2 without TTRasterizer and the Intrepid version as PostScript level 3.

Can you try to make your application do the exact same printout but with another font? How does the printout look then?

Changed in hplip:
status: Incomplete → Invalid

You can try to add

psEmbedTrueTypeFonts no

to /etc/xpdf/xpdfrc, but note that it can cause font problems with other documents. This is only a workaround, not a fix.

Another possibility is that the bug is in font embedding done by pdftops.

Changed in poppler:
importance: Undecided → Medium
status: New → Incomplete

To easily reproduce the problem do

wget http://launchpadlibrarian.net/21294491/d00022-001
pdftops -level3 -paper A4 d00022-001 > l3.ps
pdftops -level2 -paper A4 d00022-001 > l2.ps
pdftops -level2 -noembtt -paper A4 d00022-001 > l2noembtt.ps

Then send the files unfiltered to a PostScript printer from HP. Ghostscript displays all files correctly on the screen. The two "-level2" calls give the same output, so the problem is not the font embedding, but the difference in PostScript Level 2 and Level 3 output of pdftops. The Level 3 output (l3.ps) shows the problem, the Level 2 output (l2*.ps) not.

The real fix would be to fix Poppler, a workaround would be to patch the pdftops CUPS filter to never call the Poppler pdftops with "-level3".

The HP LaserJet P3005 even crashes on the faulty PostScript Level3 output of pdftops.

Changed in gtk+2.0:
status: Incomplete → Invalid
Changed in poppler:
status: Incomplete → Triaged

You can do

sudo perl -p -i -e "s/level3/level2/g" /usr/lib/cups/filter/pdftops

as a workaround for the time being.

I can confirm this behaviour for my HP LaserJet 4100 with the LaserJet 4100 postscript PPD from Ubuntu 8.10:
- both level2 files print correctly
- the level3 file prints faulty

On Sun, 2009-01-18 at 12:55 +0000, Till Kamppeter wrote:
> You can do
>
> sudo perl -p -i -e "s/level3/level2/g" /usr/lib/cups/filter/pdftops
>
> as a workaround for the time being.
>
Thank you. This works for me.

Is this persistent or do I need to run it each time the system is
restarted?

Ron Morse

This is persistent until the next time when the CUPS package gets updated.

rbmorse (rbmorse) wrote :

On Sun, 2009-01-18 at 14:26 +0000, Till Kamppeter wrote:
> This is persistent until the next time when the CUPS package gets
> updated.
>
Thank you, again, for all your help on this.

RBM

rbmorse (rbmorse) wrote :

On Sun, 2009-01-18 at 14:26 +0000, Till Kamppeter wrote:
> This is persistent until the next time when the CUPS package gets
> updated.
>
There may be another work around:

Open the file:

/etc/cups/ppd/{nameofdriverfile}.ppd

with a root-permissioned text editor. About line number 70, in the
section named "Basic Device Capabilities", find the line that reads:

*LanguageLevel: "3"

and change the "3" to "2". Save and restart CUPS:

sudo /etc/init.d/cups restart

and test. This work-around mitigates the problem on both Intrepid and
Jaunty 64-bit installations.

Changed in hplip:
status: Invalid → New

As lp3.ps displays correctly with Ghostscript ("gs l3.ps") it is possible that we are hitting a bug of the PostScript interpreters in many HP printers here (or even more than one bug, as the HP LaserJet P3005 crashes). So it is not necessarily to be fixed in Poppler but by perhaps by HP in their PPDs.

The simplest fix HP could do is following Ron Morse's suggestion to switch their PPDs to PostScript Level 2 by changing the "*LanguageLevel:" lines. Perhaps their are more sophisticated solutions, like adding a "*JobPatchFile"s, but this only the developers at HP can now.

Reopening HPLIP upstream task.

Changed in hplip:
importance: Undecided → Medium
status: New → Triaged
Changed in foomatic-db:
importance: Undecided → Medium
status: New → Triaged
Changed in poppler:
status: Unknown → Confirmed

The CUPS package in Jaunty uses a Ghostscript-based pdftops filter and so the problem should not occur there. To get the problem solved in Intrepid I suggest an SRU on CUPS letting pdftops only producing PostScript level 2. This is understood by all PostScript level 3 printers and is sophisticated enough to print all jobs.

This does not mean that no fix is needed in HPLIP. There is still a bug in amny PostScript level 3 printers from HP, so the HP developers should supply an appropriate workaround in the PPD files coming with HPLIP. There are enough users which are using HPLIP with an unpatched version of CUPS 1.3.9 or older.

Changed in cups:
status: New → Fix Released

Attached is a debdiff for the cups package of Intrepid to fix this problem.

Martin Pitt (pitti) wrote :

Till, are hplip, poppler, and foomatic really all affected by this, too?

Changed in gtk+2.0:
status: New → Invalid
milestone: ubuntu-8.10 → none
Changed in cups:
status: New → Fix Committed
Martin Pitt (pitti) wrote :

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!

Martin Pitt wrote:
> 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!
>
>
FWIW I can tell you that the problem has been fixed (for me) in the 9.04
Alpha releases.

pitti, the fix in CUPS is a workaround. It simply makes the pdftops filter of Intrepid (Poppler-based) never generating PostScript level 3 (pdftops of Jaunty is Ghostscript-based).

The HPLIP task is for HP to fix the PPDs of all HP PostScript printers which are faulty in PostScript Level 3.

The Poppler task is there as it is not excluded that the PostScript Level 3 generated by Poppler is broken.

foomatic-db also ships the PPDs from HP, so if HP fixes them, also foomatic-db needs to be updated.

Closing all these tasks for Intrepid ...

Changed in hplip:
status: New → Invalid
Changed in poppler:
status: New → Invalid
Changed in foomatic-db:
status: New → Invalid

rbmorse, please check on an Intrepid box whether the package in -proposed fixes the problem for Intrepid. We need this information to check the integrity of the package. Note also that the Intrepid and Jaunty packages of CUPS use different solutions for this problem.

Till Kamppeter wrote:
> rbmorse, please check on an Intrepid box whether the package in
> -proposed fixes the problem for Intrepid. We need this information to
> check the integrity of the package. Note also that the Intrepid and
> Jaunty packages of CUPS use different solutions for this problem.
>
>
Till -- I installed the packages in -proposed, into my Intrepid machine
as requested, undid the work around I described on 01/18 (above) and
restarted CUPS. The printer produces correct output.

I then used HPLIP to first delete and then install a new instance of my
printer. That too produces correct output. Apparent success!

Thank you again for your assistance. Please let me know if I can do
anything else.

Thank you, rbmorse, the fixed package will soon be added to the official updates for Intrepid.

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,
We have no plans for converting our Postscript Level 3 PPDs to Level 2. These are valid Postscript PPDs from the Mac driver. We view this as a Poppler issue. I would rely on you work-around for now.

-dave

Dave. I have updated the bug report closing all tasks concerning the PPD files. It works well on Jaunty where Poppler is replaced by Ghostscript to convert PDF to PS. I will keep Jaunty this way and so the PPDs from HP do not need to be changed.

Changed in hplip:
status: New → Invalid
Changed in foomatic-db (Ubuntu):
status: Triaged → Invalid
Changed in hplip (Ubuntu):
status: Triaged → Invalid

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

[I posted this to the poppler bug, but it may be of interest here, too. -JimC]

The reason the level3 ghostscript generates does not cause the problem is that ghostscript’s level3 is essentially the same as its level2; only the name of the procset is different.

Xpdf, OTOH, does generate different code for level2 and level3.

The significant difference seen in ps generated from the posted example pdf is that xpdf, when generating level3 ps, embeds CID keyed fonts as CID keyed fonts.

The question, then, is: do the HP printers have bugs when dealing with CID keyed type42 fonts in PostScript jobs, or is Xpdf’s CID-related PS code buggy? A related question is whether CID keyed type1 fonts also have problems. The test would be to send the printer pstopdf -level3 output of a PDF which has CID keyed cff fonts embedded. (I can generate such a test job, if anyone is interested, but do not have access to a PS printer to test it on.)

Launchpad Janitor (janitor) wrote :

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

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

  * debian/local/filters/cpdftocps: Only the last digit of the number of
    copies was used (LP: #309314).
  * debian/patches/pdftops-cups-1.4.dpatch: Let the pdftops filter only emit
    PostScript level 2 and not level 3, as some PostScript printers have
    problems with PostScript level 3 from Poppler, even if they are level 3
    printers (LP: #277404).
  * debian/local/filters/pdf-filters/pdftopdf/pdftopdf.cxx: Do not preceed the
    PDF output with a newline (LP: #303691).

 -- Till Kamppeter <email address hidden> Fri, 13 Mar 2009 19:08:02 +0100

Changed in cups:
status: Fix Committed → Fix Released

It is possible but I am not sure. Please try the update and see whether it helps.

Johannes Hessellund (osos) wrote :

Unfortunately it didn't fix bug #313713 !

I'm printing on a HP Laserjet 4 Plus which should support PS level 2.
Printing on Gutsy worked. Problems started with Hardy. I did try out the Gutsy ppd, but that didn't fix anything.

The printer gives me this error:
Error: invalidfont
Offending command: definefont
Stack:
/Font
-dictionary-
/KPSHBO+f-1-0

The .ps sent to the printer says its level 2, how can I verify it ?
Seems to be an issue embedding the fonts!

Jamie Strandboge (jdstrand) wrote :

I see this with my HP Color Laserjet 2550 too. Adjusting:

*LanguageLevel: "3"

to:
*LanguageLevel: "2"

works around the problem.

Jamie, which Ubuntu version you are using? What kind of file/from which app are you printing.

The problem should not occur with Karmic and most probably also not with Jaunty (fully updated), as these let PostScript level 2 be sent to the printer.

chrone (charlesalva) wrote :

using hp deskjet 3920 connected to windows xp shared network printing from ubuntu jaunty could not print any. :(

the job is sent/done completely from the notification manager, but not a page printed on the windows xp machine.

chrone, your problem is completely different to the one described here. Please file a separate bug for your problem.

(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?

Could someone who can reproduce this bug test the attached files.

As a first attempt at fixing this bug in poppler I'm attaching a zip containing two files (original.ps and modified.ps). original.ps has been created by using gedit, saving to pdf, and runing pdftops -level3. Printing this should reproduce the bug. View the file with evince and compare with the printout to see if any characters are missing.

modifed.ps contains some changes that I'm hoping might fix the bug. I've removed one of the fonts from the file so there should only be the string "12345" printed.

Print both files with "lpr -l <file>" to bypass any cups filtering and send the file directly to the printer.

Changed in poppler:
importance: Unknown → High
Changed in poppler:
importance: High → Unknown
Changed in poppler:
importance: Unknown → High

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

Roger (rogerx-oss) wrote :

I've posted this over in freedesktop bug #19640 as well. (See references at top of page.)

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
net-print/hplip-3.11.7

Oh, hplip comes with several ppd files for this device. Using the pcl ppd file
which specifies PS Level 3, does print all chars 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?

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

Which Ubuntu version are you using? Can you try Oneiric (Live CD)? It should not use Poppler for converting PDF to PostScript any more.

> On Fri, Sep 23, 2011 at 07:04:16AM -0000, Till Kamppeter wrote:
>Which Ubuntu version are you using? Can you try Oneiric (Live CD)? It
>should not use Poppler for converting PDF to PostScript any more.

I'm not a Ubuntu fan, Gentoo here -- all from source with latest and greatest
-- but will download Oneiric i386 live cd tonight and give it a try.

http://cdimage.ubuntu.com/daily-live/current/

... I'll try some debugging scenarios to see how it handles things as I'm
wondering if it's bad hardware or what.

Roger (rogerx-oss) wrote :

I'm not a Ubuntu fan, Gentoo here -- all from source with latest and greatest
-- but will download Oneiric i386 live cd tonight and give it a try.

http://cdimage.ubuntu.com/daily-live/current/

... I'll try some debugging scenarios to see how it handles things as I'm
wondering if it's bad hardware or what.

I'm assuming no hacks or work-arounds are used to force PS Level 2 printing,
when PS Level 3 is specified.

--
Roger
http://rogerx.freeshell.org/

Roger, note that Gentoo and Ubuntu have completely different filter chains, Gentoo uses probably the original PostScript-centric model of upstream CUPS and Ubuntu (and Debian) use a PDF-centric model. So problems you find in Gentoo do not necessarily occur in Ubuntu and me as maintainer of the Ubuntu printing stack cannot help you much in solving Gentoo problems. So you should better file a bug on Gentoo's bug tracker. You can naturally reference to this Ubuntu report and the Poppler upstream report.

Roger (rogerx-oss) wrote :

> On Fri, Sep 23, 2011 at 06:10:44PM -0000, Till Kamppeter wrote:
>Roger, note that Gentoo and Ubuntu have completely different filter
>chains, Gentoo uses probably the original PostScript-centric model of
>upstream CUPS and Ubuntu (and Debian) use a PDF-centric model. So
>problems you find in Gentoo do not necessarily occur in Ubuntu and me as
>maintainer of the Ubuntu printing stack cannot help you much in solving
>Gentoo problems. So you should better file a bug on Gentoo's bug
>tracker. You can naturally reference to this Ubuntu report and the
>Poppler upstream report.

This is what I was pressuming. Thanks, I've downloaded and gotta burn/test for
the next few hours.

--
Roger
http://rogerx.freeshell.org/

Roger (rogerx-oss) wrote :

(Oops. Sorry, I thought I was on the hplip site and not ubuntu! I should look more closely at the URL domain name!)

Anyways, this bug with misprinting chars at PS Level 3 is not fixed. It is merrily worked-around (aka hacked fix).

And it's not even proper.

No matter how I tried to specify to print Postscript Level 3 (by specifying within the .ppd file and by gui settings), I kept getting a Postscript Level 2 file written!!! This is WRONG.

I emailed Till Kamppeter my thoughts as well. (I'm sure he's happy to hear them ;-)

Roger, you are right that the HPLIP developers at HP also use this site as their upstream bug tracking system, but this particular bug report has an HPLIP upstream task which is marked invalid as it turned out that the problem described here is not a problem of HPLIP. The problem is a Poppler upstream bug and all Ubuntu package tasks marked as fixed here are indeed workarounds, making Poppler only generating PostScript level 2 or replacing Poppler by Ghostscript (the latter is done in Oneiric) due to lack of a fix in Poppler upstream. Plaes continue discussion in the Poppler upstream bug (as you already do). This is the real culprit and these developers have to provide a fix.

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.)

bruno (brunob) wrote :

I had to apply the workaround on post#35 (force level 2 in the PPD) here on Maverick (even with all the updates and the hplip PPA). The printer is a Laserjet 2605dn (and it works now). Note also that I changed the driver for the 2605 Postscript model (not the 2506dn Foomatic proposed by default). The Foomatic PPD doesn't have the problem discussed in this thread but have many others (lack of color options, jpeg and pdf GTK printing problems).

My suggestion: This PPD (with the fix) should be proposed by default for future releases and updates (for this printer).

Roger (rogerx-oss) wrote :

THIS BUG IS STILL NOT FIXED AND APPLICATIONS ARE STILL NOT PRINTING CORRECTLY WITH THE HPLIP INSTALLED PPD FILE!

THIS HP 1522NF PRINTER NEEDS PostScript Level 2 and NOT PostScript Level 3!!! Trying to print with Postscript Level 3 will cause character anomolies.

Roger (rogerx-oss) wrote :

... oops ... Replace "CORRECTLY" with "INCORRECTLY"!

Didier Raboud (odyx) wrote :

Please also replace upper-case shouting with lower-case. Upper-case claims don't help to have this bug fixed; much to the contrary I'd say.

Roger (rogerx-oss) wrote :

Your criticism is noted.

However, this bug is already solved, or likely solved. HP just hasn't implemented the fix. And, there's likely no other solution aside from using capitol letters. ;-)

It would be more helpful if you provided better information.

As such, only seems two solutions, either use all capitol letters or buy another manufacturer's hardware. Nothing wrong with using all capitol letters when a bug not fixed with a resolution goes unoticed and unfixed for so long. It would also be rational for people to start thinking their printer is broken at the hardware level since a fix wasn't implemented upstream.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.