Created attachment 16292 [details] PDF that was printed + 918 and 925 spoolfile With GS 9.18 we were able to print A5 duplex on Xerox and HP printer. After GS 9.25 was installed (security update?) the same A5 duplex print fails on same Xerox and HP printers: simplex is printed. No problems are encountered with A4 duplex printing. I zip attached the A5 pdf that was printed, with the spoolfiles produced by both GS versions. What is causing the failure?
Without a Ghostscript command line, we can't investigate. FWIW, both the Postscript files contain: %%Requirements: duplex and %%BeginFeature: *Duplex DuplexNoTumble (<<) cvx exec /Duplex true /Tumble false (>>) cvx exec setpagedevice %%EndFeature So, both appear to be appropriately requesting duplex printing.
(In reply to Chris Liddell (chrisl) from comment #1) > Without a Ghostscript command line, we can't investigate. > > FWIW, both the Postscript files contain: > > %%Requirements: duplex > > and > > %%BeginFeature: *Duplex DuplexNoTumble > > (<<) cvx exec /Duplex true /Tumble false (>>) cvx exec setpagedevice > %%EndFeature > > > So, both appear to be appropriately requesting duplex printing. The position of .. /pagesave save def ...differs in the spoolfiles. Could that be a factor?
(In reply to Rijk Ravestein from comment #2) <SNIP> > The position of .. > > /pagesave save def > > ...differs in the spoolfiles. Could that be a factor? It could, yes. It's possible the configuration change is being "restored away". But, as I say, to reproduce and debug the problem, we'll need a set of command line arguments.
(In reply to Chris Liddell (chrisl) from comment #3) > (In reply to Rijk Ravestein from comment #2) > <SNIP> > > The position of .. > > > > /pagesave save def > > > > ...differs in the spoolfiles. Could that be a factor? > > It could, yes. It's possible the configuration change is being "restored > away". > > But, as I say, to reproduce and debug the problem, we'll need a set of > command line arguments. Right now, I can't retrieve the actual command for the sample spoolfiles, but basically this is it: lpr -P Printer -o number-up=1 -o sides=two-sided-long-edge -o fit-to-page=1 test-pages-1-2-A5.pdf
(In reply to Rijk Ravestein from comment #4) > > But, as I say, to reproduce and debug the problem, we'll need a set of > > command line arguments. > > Right now, I can't retrieve the actual command for the sample spoolfiles, > but basically this is it: > > lpr -P Printer -o number-up=1 -o sides=two-sided-long-edge -o fit-to-page=1 > test-pages-1-2-A5.pdf That's not a Ghostscript command, we need the invocation being used for Ghostscript.
Rijk, if you print with CUPS and want to know which Ghostscript command line gets used for the job, you can find it in the /var/log/cups/error_log when you have set CUPS to debug mode before printing the job. To set CUPS to debug mode run cupsctl --debug-logging After that print your job again and in error_log look for lines with "[Job XXX]" in it with XXX being the number of your print job.
Created attachment 16302 [details] grep result of [Job 12920]
Comment on attachment 16302 [details] grep result of [Job 12920] Thanks Till. This the test with GS 9.25 D [21/Nov/2018:14:04:57 +0100] [Job 12920] Running command line for gs: gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout -dLanguageLevel=3 -r600 -dCompressFonts=false -dNoT3CCITT -dNOINTERPOLATE -c \'save pop\' -f /tmp/050d15bf6851a grep result of error_log is attached.
Created attachment 16303 [details] zip archive of trial files The output files in the original archive are the result of the entire CUPS pipeline, not the output originally from Ghostscript. I can see several differences, but obviously I can't tell which is causing your problem, since I don't have your printer. I've attached a zip archive with 3 files in it, please try these and let me know which (if any) print duplex.
(In reply to Ken Sharp from comment #9) > Created attachment 16303 [details] > zip archive of trial files > > The output files in the original archive are the result of the entire CUPS > pipeline, not the output originally from Ghostscript. I can see several > differences, but obviously I can't tell which is causing your problem, since > I don't have your printer. > > I've attached a zip archive with 3 files in it, please try these and let me > know which (if any) print duplex. We tested on a Xerox and HP device: all 3 spool files print A5 duplex correctly.
Created attachment 16321 [details] test file 4 (In reply to Rijk Ravestein from comment #10) > We tested on a Xerox and HP device: all 3 spool files print A5 duplex > correctly. Well, that's surprising. Try the attached file 4.ps please ?
(In reply to Ken Sharp from comment #11) > Created attachment 16321 [details] > test file 4 > > (In reply to Rijk Ravestein from comment #10) > > > We tested on a Xerox and HP device: all 3 spool files print A5 duplex > > correctly. > > Well, that's surprising. Try the attached file 4.ps please ? 4.ps prints A5 duplex correctly.
(In reply to Rijk Ravestein from comment #12) > 4.ps prints A5 duplex correctly. That appears to be down to a change back in Ghostscript between versions 9.20 and 9.21, somewhere up to 2+ years ago, its going to take a little time to find the change and figure out if we can do anything about it.
Created attachment 16352 [details] yet another test I believe I understand what's happening now. Its not possible to reverse the previous commit which caused this change, as that would prevent printing more than 15 pages on an Adobe PostScript interpreter. I believe I have an answer but, obviously, it needs testing. I've attached the output of current code with my potential fix, edited to include the device-specific code from the original file. If you could check the result of that please ?
In the absence of any feedback, I've committed my fix for this, which I hope will turn out to be correct.
(In reply to Ken Sharp from comment #15) > In the absence of any feedback, I've committed my fix for this, which I hope > will turn out to be correct. I'm sorry Ken, but I am dependent on others for testing. I'll let you know asap about the new.ps test result. Anyhow, I'm glad you committed the fix. When is the next GS release (with fix) due?
(In reply to Rijk Ravestein from comment #16) > I'm sorry Ken, but I am dependent on others for testing. Understood, but I couldn't easily continue to sit on the fix any longer I'm afraid, I had other work to commit as well. > When is the next GS release (with fix) due? Ghostscript is normally released twice a year in March and September, though occasional problems turned up in QA can result in these slipping slightly. Serious problems (generally security issues) can result in 'out of band' releases at any time. Accordingly the next planned release will be in March 2019. You can of course pull the code from our Git repository and build Ghostscript yourself. You can pull the 9.25 release (which is tagged in our Git repository) and the patch referenced above should apply cleanly to that, though obviously you'll still have to build Ghostscript from source yourself.
(In reply to Rijk Ravestein from comment #16) > (In reply to Ken Sharp from comment #15) > > In the absence of any feedback, I've committed my fix for this, which I hope > > will turn out to be correct. > > I'll let you know asap about the new.ps test result. new.ps printed A5 duplex OK on a Xerox and HP device.
(In reply to Rijk Ravestein from comment #18) > (In reply to Rijk Ravestein from comment #16) > > (In reply to Ken Sharp from comment #15) > > > In the absence of any feedback, I've committed my fix for this, which I hope > > > will turn out to be correct. > > > > I'll let you know asap about the new.ps test result. > > new.ps printed A5 duplex OK on a Xerox and HP device. That's great, it was what I thought it was then :-) Commit 96c381cce28c27eac182549441a6c5025b0dcdd6 should solve the problem. Thanks for the report, and testing, we wouldn't have been able to resolve this without your help.
(In reply to Ken Sharp from comment #19) > Commit 96c381cce28c27eac182549441a6c5025b0dcdd6 should solve the problem. > Thanks for the report, and testing, we wouldn't have been able to resolve > this without your help. You're welcome. I wonder, can it be that this fix solves other non-A4 duplex problems as well? For instance, A3 duplex (booklets)?
(In reply to Rijk Ravestein from comment #20) > You're welcome. I wonder, can it be that this fix solves other non-A4 duplex > problems as well? For instance, A3 duplex (booklets)? It solves problems with Duplex, or any feature which relies upon persistence between pages, and is reset when setpagedevice is executed.