Summary: | Printing web pages with images in them doesn't work | ||
---|---|---|---|
Product: | cairo | Reporter: | Andrew Benton <b3nton> |
Component: | postscript backend | Assignee: | Adrian Johnson <ajohnson> |
Status: | RESOLVED MOVED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
Severity: | normal | ||
Priority: | medium | ||
Version: | 1.9.6 | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
postscript file generated by firefox on a system with cairo-1.9.6
postscript file generated by midori/webkit on a system with cairo-1.9.6 patch Postscript output from Firefox on the system with the patched cairo-1.9.6 Postscript output from Midori/webkit-gtk with the patched cairo-1.9.6 postscript that cups sends to the printer when printing from Midori/webkit with the patched cairo-1.9.6 .ppd for the printer |
Description
Andrew Benton
2010-04-06 08:44:20 UTC
Can you print to a file, preferably with the simplest possible test case, and attach the PostScript file here. Also check that the file crashes Ghostscript directly with "gs file.ps" as well as via CUPS with "lpr file.ps". Created attachment 34735 [details]
postscript file generated by firefox on a system with cairo-1.9.6
This postscript file displays fine with gs file.ps. If I try to print it with lpr file.ps it's just the same as if I try to print it directly from firefox, the first page is blank and the second page prints OK. Actually the second page has got some small images on it that have printed so it's not as simple as I thought, it is able to print some images. I've just recompiled my system using cairo-1.8.10 and the bug is gone. Firefox compiled with --enable-system-cairo can print again
Created attachment 34741 [details]
postscript file generated by midori/webkit on a system with cairo-1.9.6
This file was created with Midori/webkit-gtk on a system with cairo-1.9.6. This one crashes ghostscript like so:
andy:~$ gs file.ps
GPL Ghostscript 8.64 (2009-02-03)
Copyright (C) 2009 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /nocurrentpoint in --show--
Operand stack:
(\001)
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1862 1 3 %oparray_pop 1861 1 3 %oparray_pop 1845 1 3 %oparray_pop 1739 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- --nostringval-- %array_continue
Dictionary stack:
--dict:1143/1684(ro)(G)-- --dict:2/20(G)-- --dict:111/200(L)--
Current allocation mode is local
Last OS error: 2
Current file position is 285891
GPL Ghostscript 8.64: Unrecoverable error, exit code 1
Trying to print it with lpr file.ps produces nothing, not even a blank page
If I boot into the system with cairo-1.8.10 then Midori can print fine
Created attachment 34756 [details] [review] patch This patch should fix the problem. Could you try it with your test case. The patch is a slight improvement, Midori no longer crashes ghostscript, it now behaves exactly the same as Firefox. gs file.ps shows the file without crashing. When I print the first page goes through the printer but nothing gets printed, the second page is printed. No change in the behavior of Firefox. When printing, CUPS converts the PS to PDF then back to PS using these commands: ps2pdf13 file.ps # ghostscript pdftops file.pdf file2.ps # poppler gs file2.ps The problem may be with cairo, gs, or poppler. Can you attach the new PS output from Firefox and I'll check if I can reproduce the problem. Created attachment 34761 [details]
Postscript output from Firefox on the system with the patched cairo-1.9.6
I'm unable to reproduce the bug with the attachment in comment 7 using either: lpr file.ps or ps2pdf13 file.ps pdftops file.pdf file2.ps gs file2.ps I'm using gs 8.70 and pdftops 0.13.1. Created attachment 34764 [details]
Postscript output from Midori/webkit-gtk with the patched cairo-1.9.6
Interesting.
I compile cups before poppler or xpdf (pdftops is provided by xpdf-3.02pl4 on my system). I see cups checks for pdftops during configure but it normally runs fine without it. I'm just in the process of running my build scripts on my kitchen computer to rebuild with cairo-1.8.10. It hasn't got as far as compiling poppler or xpdf so there isn't (yet) a pdftops on that system yet printing works fine. Cups doesn't seem to need pdftops.
On my main computer I've booted into the partition with the patched cairo-1.9.6 and reinstalled cups-1.4.2. It now sees that pdftops is installed and printing from Firefox is working again but Midori still outputs a blank page.
Try lpr file.ps with this new attachment
CUPS may have multiple options for converting PS to PDF. My experience is based on what my Ubuntu system does. To debug this problem you will need to figure out what is happening to your PS file when you print it. I can only help with cairo or poppler problems. I've pushed the patch out to master. Printing the file in comment 9 works for me. You didn't mention what printer you are using. If it is a PostScript printer you can capture the PS that CUPS sends to the printer and check if it works with ghostscript. To capture the output sent to the printer: Run the command: cupsctl FileDevice=yes Then create a clone of your print queue. I use system-config-printer to do this. Then run (assuming the copy of your queue is named "copy"): lpadmin -p copy -E -v file:/tmp/printout.ps Then print to "copy" and the output is in /tmp/printout.ps You can send printout.ps directly to your printer bypassing all filtering with: lpr -l printout.ps Created attachment 34878 [details]
postscript that cups sends to the printer when printing from Midori/webkit with the patched cairo-1.9.6
I couldn't figure out how to clone the print queue so I ran the lpadmin command on the default print queue, which produced this file.
Trying to view it with ghostscript crashes gs
andy:~$ gs printout.ps
GPL Ghostscript 8.71 (2010-02-10)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /undefined in $PJL
Operand stack:
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1878 1 3 %oparray_pop 1877 1 3 %oparray_pop 1861 1 3 %oparray_pop 1755 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval--
Dictionary stack:
--dict:1149/1684(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)--
Current allocation mode is local
Current file position is 332
GPL Ghostscript 8.71: Unrecoverable error, exit code 1
If I try to print it the output is just as before: the first page is blank. If I do the same thing with Firefox it produces a postscript file that is twice as big which make sense, 'cos when I print that file it prints both pages.
My printer is a Samsung ml-1210 postscript laser printer. I'm using cups-1.4.2
> Error: /undefined in $PJL Attachment #34878 [details] is not PostScript, but rather PJL. Probably PCL bitmaps. What does the print spool's ppd look like? Created attachment 34880 [details]
.ppd for the printer
This is the .ppd file I use for the printer. It normally works well.
That ppd uses ghostscript and the gs driver at: http://www.openprinting.org/download/printing/samsung-gdi/ to render the ps to the PJL-enclosed bitmaps the printer supports. The Samsung-gdi driver was added to ghostscript years ago. I can vaguely remember using those patches but it was a log time ago. The printer works perfectly if I use cairo-1.8.10 Mozilla bug #563255 reported a similar problem. The much smaller test case made it possible to find a mismatched save/restore in the PS output. I'm hoping the patch will also fix this bug: http://cgit.freedesktop.org/cairo/commit/?id=fa937913e06bc295750538be45aa83eb42332fb4 -- 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/cairo/cairo/issues/116. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.