Summary: | PS output of gnuplot, filtered through CUPS' pstops is rendered to 0 pages by Ghostscript | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Carl Michal <michal> |
Component: | PS Interpreter | Assignee: | Alex Cherepanov <alex> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | till.kamppeter |
Priority: | P4 | ||
Version: | 8.61 | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | Word Size: | --- | |
Attachments: |
working postscript file
postscript file that fails to print error log with debug loglevel gnuplot-pstops.ps |
Description
Carl Michal
2008-07-31 17:06:44 UTC
Created attachment 4251 [details]
working postscript file
Created attachment 4252 [details]
postscript file that fails to print
re-assign two cups bugs, having no activity from Mike Sweet for a while. This bug report is already 2 years old. Can you tell us whether the problem still persists with the current versions of CUPS, Ghostscript, Foomatic, HPIJS/HPLIP, and gnuplot? Thanks. With: gnuplot 4.2.6 hplip-3.9.12-r1 ghostscript-gpl-8.71 cups-1.3.11 foomatic not installed, I still see a problem with the same general issue, though its maybe simpler now. the entry in cups' error.log is: [05/Jul/2010:11:14:13 -0700] [Job ???] Request file type is application/postscript. I [05/Jul/2010:11:14:13 -0700] [Job 412] Adding start banner page "none". I [05/Jul/2010:11:14:13 -0700] [Job 412] Adding end banner page "none". I [05/Jul/2010:11:14:13 -0700] [Job 412] File of type application/postscript queued by "michal". I [05/Jul/2010:11:14:13 -0700] [Job 412] Queued on "test-1012" by "michal". I [05/Jul/2010:11:14:13 -0700] [Job 412] Started filter /usr/libexec/cups/filter/pstops (PID 10280) I [05/Jul/2010:11:14:13 -0700] [Job 412] Started filter /usr/libexec/cups/filter/pstoraster (PID 10281) I [05/Jul/2010:11:14:13 -0700] [Job 412] Started filter /usr/libexec/cups/filter/hpcups (PID 10282) I [05/Jul/2010:11:14:13 -0700] [Job 412] Started backend /usr/libexec/cups/backend/hp (PID 10283) E [05/Jul/2010:11:14:13 -0700] [Job 412] No %%Pages: comment in header! E [05/Jul/2010:11:14:13 -0700] PID 10282 (/usr/libexec/cups/filter/hpcups) stopped with status 1! I [05/Jul/2010:11:14:13 -0700] Hint: Try setting the LogLevel to "debug" to find out more. E [05/Jul/2010:11:14:13 -0700] [Job 412] Job stopped due to filter errors. it appears to be complaining about the lack of a %%Pages comment in the ps file. Carl, can you set CUPS to debug logging, either with the command cupsctl LogLevel=debug or by putting a line "LogLevel debug" into /etc/cups/cupsd.conf and restarting CUPS (/etc/init.d/cups restart)? After that do cancel -a cupsenable test-1012 then send a your problematic print job and after the job has disappeared from the print queue (or got into "stopped" state) attach your error_log here again. Created attachment 6605 [details]
error log with debug loglevel
Done.
I don't see anything obvious till the last 10 lines...
This is not a bug of the CUPS Raster output device, either it is a bug of CUPS' pstops filter or of the PostScript interpreter of Ghostscript. Feeding the offending file directly into GhostScript cat ../testfiles/gnuplot.ps | /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS -sDEVICE=cups -sstdout=%stderr -sOUTPUTFILE=%stdout -c -f -_ > out.raster cat ../testfiles/gnuplot.ps | /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS -sDEVICE=png16m -sstdout=%stderr -sOUTPUTFILE=%stdout -c -f -_ > out.png Gives correct output with both "cups" and "png16m" output devices, whereas passing the file through CUPS's pstops filter, as it usually happens when printing with CUPS, both "cups" and "png16m" produce empty output files (0 pages): cat ../testfiles/gnuplot.ps | /usr/lib/cups/filter/pstops 1 1 1 1 'PageSize=A4' | /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS -sDEVICE=cups -sstdout=%stderr -sOUTPUTFILE=%stdout -c -f -_ > out.raster cat ../testfiles/gnuplot.ps | /usr/lib/cups/filter/pstops 1 1 1 1 'PageSize=A4' | /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS -sDEVICE=png16m -sstdout=%stderr -sOUTPUTFILE=%stdout -c -f -_ > out.png Strangely enough Ghostscript can display the output of pstops on the screen: cat ../testfiles/gnuplot.ps | /usr/lib/cups/filter/pstops 1 1 1 1 'PageSize=A4' > gnuplot-pstops.ps gs -sDEVICE=x11 gnuplot-pstops.ps As the PNG output device shows the same problem as the CUPS Raster output device here, the problem cannot be in the CUPS Raster output device. Created attachment 6654 [details]
gnuplot-pstops.ps
Attached is the offending PostScript file after being treated by CUPS' pstops filter:
cat ../testfiles/gnuplot.ps | /usr/lib/cups/filter/pstops 1 1 1 1 'PageSize=A4' > gnuplot-pstops.ps
The original file is not DSC-conforming and pstops makes it rather messy, especially appending the "%%BeginSetup ... %%EndSetup" section to the end of the file, after the code which draws tha page.
The file from the comment 9 redefines --showpage-- as no-op. Without --showpage-- Ghostscript doesn't show the page. Everything works as designed. Alex, but why is Ghostscript then able to display the page with the "x11" output device? Michal, for me it looks like a problem of the pstops filter. Please report it on the bug tracker of CUPS: http://www.cups.org/str.php Alex, I have sent the file to a PostScript printer without any filtering now and the printer only wakes up from power-saving mode, it does not print any page. So it is not a Ghostscript bug. Perhaps we can consider as a Ghostscript bug that the "x11" device displays the file. x11 device shows intermediate states of the output buffer as a way to deliver some results faster and demonstrate the progress to the user. Alex, then this is really not a Ghostscript bug, so I will close it. Michal, please report a bug against CUPS, see my comment #12. ok, bug opened here: http://www.cups.org/str.php?L3641+Qversion:1.3 |