gs renders images as black boxes when generating PDF files

Bug #817049 reported by Hadmut Danisch
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
GS-GPL
Invalid
Medium
acroread (Ubuntu)
Incomplete
Medium
Unassigned
ghostscript (Ubuntu)
Invalid
Undecided
Unassigned
poppler (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Hi,

I just noticed that for several days my cupspdf printer driver (generating PDF files in the home directory as a special printer) generated broken PDF files when printing from firefox to cupspdf.

Debugging and breaking it down into its processing steps showed that firefox itself generates a PDF files and sends it to the cupspdf printer, which then runs something like (filenames replaced for debugging tests)

pdftops -level2 -origpagesizes x.pdf y.ps

/usr/lib/cups/filter/pstops 619 hadmut test 1 finishings=3 < y.ps > z.ps

/usr/bin/gs -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile=a.pdf -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f z.ps

The first and the second step work, the generated postscript file (y.ps in this example) is correct (i.e. ghostview shows it correctly, I did not check it's internals).

But then gs generates a broken pdf.

Just try a

/usr/bin/gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile=a.pdf -f z.ps

with the attached z.ps as an example. I'll attach both z.ps and a.pdf.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: ghostscript 9.01~dfsg-1ubuntu5
ProcVersionSignature: Ubuntu 2.6.38-11.47-generic 2.6.38.8
Uname: Linux 2.6.38-11-generic x86_64
Architecture: amd64
Date: Wed Jul 27 17:13:18 2011
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100427.1)
Lpstat:
 device for Deskjet-F2100-series: hp:/usb/Deskjet_F2100_series?serial=CN7CK4T2NP04TK
 device for HP-LaserJet-1300: socket://192.168.160.1:9100
 device for hp-LaserJet-1320-series: hp:/usb/hp_LaserJet_1320_series?serial=00CNM1G08790
 device for Laser: ///dev/null
 device for PDF: cups-pdf:/
MachineType: Gigabyte Technology Co., Ltd. GA-MA78G-DS3H
Papersize: a4
PpdFiles:
 PDF: Generic CUPS-PDF Printer
 HP-LaserJet-1300: HP LaserJet 1300 Series Postscript (recommended)
 hp-LaserJet-1320-series: HP LaserJet 1320 Foomatic/pxlmono (recommended)
 Deskjet-F2100-series: HP Deskjet f2100 Series hpijs, 3.10.6
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/tcsh
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-2.6.38-11-generic root=/dev/mapper/raid2-ubuntu64 ro quiet splash vt.handoff=7
SourcePackage: ghostscript
UpgradeStatus: Upgraded to natty on 2011-05-17 (70 days ago)
dmi.bios.date: 04/03/2008
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F2
dmi.board.name: GA-MA78G-DS3H
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF2:bd04/03/2008:svnGigabyteTechnologyCo.,Ltd.:pnGA-MA78G-DS3H:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-MA78G-DS3H:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: GA-MA78G-DS3H
dmi.sys.vendor: Gigabyte Technology Co., Ltd.

Related branches

Revision history for this message
Hadmut Danisch (hadmut) wrote :
Revision history for this message
Hadmut Danisch (hadmut) wrote :
Revision history for this message
Hadmut Danisch (hadmut) wrote :
Revision history for this message
Hadmut Danisch (hadmut) wrote :

Uhm, I just realized that I still can print these files and display them with okular.

Maybe it is not a problem of ghostscript but of evince (which I use as a pdf viewer...)

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

A had reported this problem to Ghostscript upstream some days ago:

http://bugs.ghostscript.com/show_bug.cgi?id=692380

Thet have checked your PDF file and it still contains the images. the problem are PDF renderers/viewers. Acrobat Reader and evince dispaly black boxes whereas most other viewers, like Okular, XPDF, gv, ... display your files correctly.

So the bug is in the viewers or in the rendering libraries behind them.

Changed in ghostscript (Ubuntu):
status: New → Invalid
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Added tasks for acroread and poppler. The latter is the rendering library used by evince.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Can you try a live CD of Ubunru Oneiric? Here the filters have somewhat changed, especially Ghostscript instead of Poppler is used for CUPS' pdftops filter. Perhaps there your PDFs get generated in a form that all PDF viewers can display it. Note that this is not a fix, but only a side effect of changes.

Changed in gs-gpl:
importance: Unknown → Medium
status: Unknown → Invalid
Revision history for this message
Hadmut Danisch (hadmut) wrote :

Can anyone please point out why I am asked on saturday to perform further tests, and on monday the report is set to „invalid” ?

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

I did not set the whole bug report to Invalid. I simply followed the Ghostscript upstream bug report where the result was that the PDF itself is OK but some viewers show black boxes. So I have moved this bug report from Ghostscript to the viewers, by setting the Ghostscript task to Invalid and adding tasks for the viewers..

Please still do the tests I have asked you for in comment #7. The results can perhaps help on fixing the viewers.

Changed in acroread (Ubuntu):
status: New → Incomplete
Changed in poppler (Ubuntu):
status: New → Incomplete
Changed in acroread (Ubuntu):
importance: Undecided → Medium
Changed in poppler (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Hadmut Danisch (hadmut) wrote :

Just allow me a few days, I'm completely busy at the moment.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Bug 820820 causes this, but the viewers need to be fixed, too.

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

The problem appears to be caused by pdftops writing tiling pattern images as Type 3 fonts. I am assuming this was done to support level 1 PS. The PLRM section 4.9 (Patterns) states "The ability to paint with patterns is a feature of LanguageLevels 2 (tiling patterns) and 3 (shading patterns). With some effort, it is possible to achieve a limited form of tiling patterns in LanguageLevel 1 by defining them as character glyphs in a special font and painting them repeatedly with the show operator". But section 5.7 (Type 3 fonts) states: "Normally, it is unnecessary and undesirable to initialize the current color parameter, because show is defined to paint glyphs with the current color.". The PDF specification also contains the same text.

The best solution would be to fix pdftops to use patterns for level 2 or higher output.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

In Oneiric I have switched CUPS' pdftops filter from Poppler to Ghostscript. Please try whether this helps.

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

I don't have Oneiric installed. However I did try:

  pdf2ps firefox.pdf
  ps2pdf firefox.ps output.pdf

and while it looks correct the text has been converted to bitmaps and as a result is not selectable.

I also tried printing to PostScript from firefox and running ps2pdf. The result appears to be as good as the native PDF from firefox. Images worked and all text is selectable.

So it should be possible to fix this by improving pdftops to use patterns instead of Type 3 fonts and use the correct glyph names so that gs can correctly encode the fonts.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Can you edit /usr/bin/pdf2ps and assure that the Ghostscript command line has "-sDEVICE=ps2write" and NOT "-sDEVICE=pswrite"?

Revision history for this message
Hadmut Danisch (hadmut) wrote :

I just tried to install oneiric on a notebook (alpha-2 alternate installer) which failed due to bugs in the installation procedure.

Will have some delay to test this...

Revision history for this message
Hadmut Danisch (hadmut) wrote :

The pdf2ps command of my natty installation already uses -sDEVICE=ps2write

Revision history for this message
Hadmut Danisch (hadmut) wrote :

Strange.

I just installed oneiric alpha-3 (32bit alternate) on a notebook, apt-upgraded to latest packets, installed cups-pdf, visited the example page http://www.economist.com/node/17723223/print with firefox, printed to PDF printer, and displayed with evince.

Astonishingly, evince displayed the graphics on the first page correctly, page 2 does not contain graphics, but the graphics on pages 3 and 4 are still rendered as black boxes. So the bug has somewhat changed but still exists.

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

In comment 12 I wrote:
> The best solution would be to fix pdftops to use patterns for level 2 or higher output.

I've now fixed poppler to use patterns instead of Type 3 fonts:

https://bugs.freedesktop.org/show_bug.cgi?id=40076

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package poppler - 0.16.7-2ubuntu2

---------------
poppler (0.16.7-2ubuntu2) oneiric; urgency=low

  * debian/patches/15_output-tiling-patterns-issuing-PS-patterns.patch,
    debian/patches/17_dont-use-patterns-when-only-one-instance-is-used.patch:
    Backported upstream patch to use PostScript Patterns for tiling fill when
    output PostScript level >= 2 and to avoid using /PatternType if only one
    instance of the pattern is used. This should fix LP: #817049.
 -- Till Kamppeter <email address hidden> Fri, 19 Aug 2011 15:10:18 +0200

Changed in poppler (Ubuntu):
status: Incomplete → Fix Released
Revision history for this message
Alexander List (alexlist) wrote :

This bug is still present in current Precise. I can reproduce it using Firefox.

There are no instructions how to instruct Firefox to use poppler instead of gs, and the upstream gs authors simply closed the bug invalid without a reason...

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Alexander, we need to know what exactly happens with your print jobs, therefore follow the instructions of the sections "CUPS error_log" and "Capturing print job data" of https://wiki.ubuntu.com/DebuggingPrintingProblems.

If you have installed all updates on your Precise system, you can decide whether to use Poppler or Ghostscript in the pdftops filter (which is used if you have a PostScript printer, a printer using the foo2zjs driver, or the cups-pdf PDF printer). To do so, run the command

lpadmin -p <queue> -o pdftops-renderer-default=gs

or

lpadmin -p <queue> -o pdftops-renderer-default=pdftops

After testing with your current configuration, please try also these two possibilities. Tell us whether they solve your problem or not.

Revision history for this message
Gianfranco Costamagna (costamagnagianfranco) wrote :

Hi, a new acroread release (0.9.4) is available for update, could you give it a try and tell us if the problem persists?
If you still have this bug please set back the status to "new"
thanks

Revision history for this message
sandipahire007 (sandipahire007) wrote :

hi Team,

i have send print from windows 2003 server 192.168.0.2
and printer connected 192.168.105.208 ( Ubuntu 10.10 )
 print job not Accepted in Ubuntu 10.10
printer install parallel port

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

Other bug subscribers

Remote bug watches

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