|Summary:||PostScript Level 3 of pdftops broken|
|Product:||poppler||Reporter:||Till Kamppeter <till.kamppeter>|
|Status:||RESOLVED MOVED||QA Contact:|
|Priority:||medium||CC:||cweiske, rbmorse, rogerx.oss, twaugh|
|i915 platform:||i915 features:|
Description Till Kamppeter 2009-01-18 04:45:53 UTC
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.
Comment 1 Albert Astals Cid 2009-01-18 05:07:07 UTC
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.
Comment 2 Till Kamppeter 2009-03-16 14:06:08 UTC
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.
Comment 3 Albert Astals Cid 2009-03-20 16:35:23 UTC
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.
Comment 4 James Cloos 2009-03-21 00:54:23 UTC
> 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
Comment 5 Tim Waugh 2009-12-10 03:35:00 UTC
(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?
Comment 6 Roger 2011-09-22 22:48:02 UTC
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.
Comment 7 Roger 2011-09-22 22:50:32 UTC
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?
Comment 8 Adrian Johnson 2011-09-22 23:31:20 UTC
(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
Comment 9 Christian Weiske 2011-11-07 14:47:14 UTC
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.
Comment 10 Roger 2011-11-07 17:49:31 UTC
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.)
Comment 11 GitLab Migration User 2018-08-20 22:02:20 UTC
-- 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.