Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On Tue 12 May 2015 at 02:53:44 +0200, Vincent Lefevre wrote: On 2015-05-11 23:12:35 +0100, Brian Potkin wrote: Today, while examining the way Ghostscript and pdftops operate I came (completely unexpectedly) across this: http://bugs.ghostscript.com/show_bug.cgi?id=694852 Your problem appears to be exactly described in the bug title. Indeed. My previous efforts were focussed on exploring the reported behaviour in your environment. Printing babel-bib.pdf to a queue on a Jessie machine gives a duplexed output on my printer, which didn't happen before when the renderer was also gs. This outcome inclines me to suggest a closing of this report. I haven't found a trace of the fix of the above bug in the Debian package. Only, ps2write - only execute setpagedevice if /PageSize changes Bug #692691 (November 2011) in History9.htm, which seems to be a bit related (perhaps an incomplete fix, completed by GS bug #694852). But this is a version from 2012, while the fix was done in December 2013. Do you have more information? Perhaps it's best to forget about my printing test; after all, it is a different printer from yours and, to some extent, I've lost track of what worked and didn't work before. You appear to be correct in thinking the bug has not been attended to in ghostscript 9.06~dfsg-2. Experimental has ghostscript 9.15~rc1~dfsg-1 and it has the Ghostscript commit which fixes the bug. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
Control: tags -1 upstream fixed-upstream fixed-in-experimental Control: found -1 9.05~dfsg-6.3+deb7u1 Control: found -1 9.06~dfsg-2 Control: fixed -1 9.15~rc1~dfsg-1 On 2015-05-12 11:10:36 +0100, Brian Potkin wrote: You appear to be correct in thinking the bug has not been attended to in ghostscript 9.06~dfsg-2. Experimental has ghostscript 9.15~rc1~dfsg-1 and it has the Ghostscript commit which fixes the bug. OK. So, I've reflected this with the above commands. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
reassign 781253 ghostscript thanks On Thu 30 Apr 2015 at 16:15:45 +0100, Brian Potkin wrote: On Thu 30 Apr 2015 at 12:54:09 +0200, Vincent Lefevre wrote: On 2015-04-30 10:32:33 +0100, Brian Potkin wrote: Having to switch renderer to get a satisfactory printout is usually an indication of a problem with the printer not dealing with valid PostScript rather than the filtering system. Or could this be a bug with the default renderer (Ghostscript?)? Or some incompatibility like the following one? http://comments.gmane.org/gmane.comp.printing.cups.bugs/9407 That link leads to http://bugs.ghostscript.com/show_bug.cgi?id=693652 , which is a pretty comprehensive discussion of the issues with buggy interpreters. So indeed, this does seem like the problem here. The contrast between gs and pdftops in Comment 26 is interesting. Ultimately, I'd go with the simplest explanation; especially when the outcome is successful printing. Someone with more PostScript knowledge than I have might look deeper. They have already looked, I think. Today, while examining the way Ghostscript and pdftops operate I came (completely unexpectedly) across this: http://bugs.ghostscript.com/show_bug.cgi?id=694852 Your problem appears to be exactly described in the bug title. My previous efforts were focussed on exploring the reported behaviour in your environment. Printing babel-bib.pdf to a queue on a Jessie machine gives a duplexed output on my printer, which didn't happen before when the renderer was also gs. This outcome inclines me to suggest a closing of this report. Your way of testing could involve cupsfilter (the Debian wiki has a page on this) and sending a file with -oraw. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On 2015-05-11 23:12:35 +0100, Brian Potkin wrote: Today, while examining the way Ghostscript and pdftops operate I came (completely unexpectedly) across this: http://bugs.ghostscript.com/show_bug.cgi?id=694852 Your problem appears to be exactly described in the bug title. Indeed. My previous efforts were focussed on exploring the reported behaviour in your environment. Printing babel-bib.pdf to a queue on a Jessie machine gives a duplexed output on my printer, which didn't happen before when the renderer was also gs. This outcome inclines me to suggest a closing of this report. I haven't found a trace of the fix of the above bug in the Debian package. Only, ps2write - only execute setpagedevice if /PageSize changes Bug #692691 (November 2011) in History9.htm, which seems to be a bit related (perhaps an incomplete fix, completed by GS bug #694852). But this is a version from 2012, while the fix was done in December 2013. Do you have more information? -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On 2015-04-30 10:32:33 +0100, Brian Potkin wrote: Having to switch renderer to get a satisfactory printout is usually an indication of a problem with the printer not dealing with valid PostScript rather than the filtering system. Or could this be a bug with the default renderer (Ghostscript?)? Or some incompatibility like the following one? http://comments.gmane.org/gmane.comp.printing.cups.bugs/9407 -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On 2015-04-30 10:32:33 +0100, Brian Potkin wrote: Having to switch renderer to get a satisfactory printout is usually an indication of a problem with the printer not dealing with valid PostScript rather than the filtering system. Is there a way to send unfiltered PostScript to the printer in order to confirm this? -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On 2015-04-30 10:32:33 +0100, Brian Potkin wrote: On Wed 29 Apr 2015 at 17:27:38 +0200, Vincent Lefevre wrote: On 2015-04-29 15:27:17 +0100, Brian Potkin wrote: One way I got my printer to work with a foomatic driver was to set up a queue with -o pdftops-renderer-default=pdftops. That option isn't open to you but how does lp -d queue -o pdftops-renderer=pdftops babel-bib.pdf turn out? It prints on A4 in duplex. Having to switch renderer to get a satisfactory printout is usually an indication of a problem with the printer not dealing with valid PostScript rather than the filtering system. Could the different renderer generate slightly different Postscript parameters so that the printer think that the page size is A4, and no longer letter? Some additional information. As it seems very strange that the page size has an influence on the duplex mode, I was wondering whether the printing was actually in duplex but with blank pages. Indeed the letter format is a bit wider than A4, so that the additional space would be printed on the next page (a bit like when I print a .ps file in letter format, the printing is done in duplex but on A3 paper, as mentioned above in the thread). I've tried: lpr -o sides=one-sided babel-bib.pdf and it doesn't print additional blank pages, but I don't think that this proves anything because the generation of blank pages may occur late internally in the printer processing. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On Wed 29 Apr 2015 at 17:27:38 +0200, Vincent Lefevre wrote: On 2015-04-29 15:27:17 +0100, Brian Potkin wrote: One way I got my printer to work with a foomatic driver was to set up a queue with -o pdftops-renderer-default=pdftops. That option isn't open to you but how does lp -d queue -o pdftops-renderer=pdftops babel-bib.pdf turn out? It prints on A4 in duplex. Having to switch renderer to get a satisfactory printout is usually an indication of a problem with the printer not dealing with valid PostScript rather than the filtering system. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On Thu 30 Apr 2015 at 12:54:09 +0200, Vincent Lefevre wrote: On 2015-04-30 10:32:33 +0100, Brian Potkin wrote: Having to switch renderer to get a satisfactory printout is usually an indication of a problem with the printer not dealing with valid PostScript rather than the filtering system. Or could this be a bug with the default renderer (Ghostscript?)? Or some incompatibility like the following one? http://comments.gmane.org/gmane.comp.printing.cups.bugs/9407 That link leads to http://bugs.ghostscript.com/show_bug.cgi?id=693652 , which is a pretty comprehensive discussion of the issues with buggy interpreters. So indeed, this does seem like the problem here. The contrast between gs and pdftops in Comment 26 is interesting. Ultimately, I'd go with the simplest explanation; especially when the outcome is successful printing. Someone with more PostScript knowledge than I have might look deeper. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
tags 781253 - unreproducible thanks On Mon 27 Apr 2015 at 16:36:18 +0200, Vincent Lefevre wrote: Control: reopen -1 Control: retitle -1 no duplex printing (two-sided) with lp or lpr of a letter PDF file on A4 paper Sorry for the late reply. In the mean time, I talked to the sysadmin and we did more tests. I'm reopening the bug since I have more information that could be useful to get a client-based solution (just like what evince does). I also have an option that works, but undocumented. How does babel-bib.pdf print when Page Scaling is set to none in Evince? The printer has A3 and A4 paper. With lp and lpr, A4 PDF files are printed in duplex mode as expected. The problem actually occurs with files having the letter page size. For such files (such as the one attached as an example), lp and lpr print them on A4 paper but one-sided; and xpdf using the lpr command (with no options) prints them two-sided, but on A3 paper. For xpdf, I had reported the bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781251 My understanding is that xpdf does nothing more than send the PDF to a queue with lp/lpr. Consideration could be given to merging #78125 with this report. but I now wonder whether this is related and whether there may be a server problem too. Same problem if I convert the PDF file to PS with pdftops, then print the .ps file with lp: A3 paper, two-sided. Not having your printer makes testing this not easy. However, I did print directly to my Laserjet 2200. How seriously any conclusions drawn from my observations should be taken is debatable. My original tests in printing with the C3003 were done with the PPD default of PageSize=Letter. Repeating them with babel-bib.pdf gives me duplex output, as before. When a print queue on the Wheezy server is set up with -o PageSize=A4 (which your server has as the default) duplexing is attempted with the first sheet (it is pulled back in) but the printer stops when it emerges a second time. Another piece of paper is jammed in the printer, looking like the job was being non-duplexed. The job gets printed in duplex with: lp -d lj2200 -o fit-to-page babel-bib.pdf I've just had a thought! My printer has a foomatic PPD. I used it for a queue and the previous observations were replicated. This looks like a problem with a filter on the server and not with cups-client. Possibly foomatic. But I am not familiar with that software so am loathe to be specific. I've googled a bit, and found a solution given here: http://www.unix.com/302870967-post7.html Here, lp -o fitplot -o pdf-page=A4 babel-bib.pdf prints on A4 paper, two-sided. However: * These options are undocumented. I don't know what they are supposed to do and how they have been found. * I wonder whether lp could do the right thing automatically. fitplot has been replaced by fit-to-page but at present it still works, The second option is unknown to me and is not found in the cups or cups-filters sources. Searching gives pdf-page as only being found in your post and the unix.com one. The filtering system should do the right thing automatically. The server is a standard Debian/wheezy machine, with: foomatic-db 20120523-1 foomatic-db-engine 4.0.8-3 foomatic-filters 4.0.17-1 cups 1.5.3-5+deb7u5 Thanks. This helped with the testing. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
Control: tags 781253 - unreproducible On 2015-04-29 09:23:05 +0100, Brian Potkin wrote: tags 781253 - unreproducible thanks wasn't taken into account. On Mon 27 Apr 2015 at 16:36:18 +0200, Vincent Lefevre wrote: Sorry for the late reply. In the mean time, I talked to the sysadmin and we did more tests. I'm reopening the bug since I have more information that could be useful to get a client-based solution (just like what evince does). I also have an option that works, but undocumented. How does babel-bib.pdf print when Page Scaling is set to none in Evince? It sill prints in duplex. Ditto if I unselect Auto Rotate and Center. But if I select Select page size using document page size, then it no longer prints in duplex. The printer has A3 and A4 paper. With lp and lpr, A4 PDF files are printed in duplex mode as expected. The problem actually occurs with files having the letter page size. For such files (such as the one attached as an example), lp and lpr print them on A4 paper but one-sided; and xpdf using the lpr command (with no options) prints them two-sided, but on A3 paper. For xpdf, I had reported the bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781251 My understanding is that xpdf does nothing more than send the PDF to a queue with lp/lpr. Consideration could be given to merging #78125 with this report. Actually xpdf seems to convert the PDF file to PS, since I have the same problem after a pdftops. This is confirmed by the xpdf(1) man page if correct: print button Bring up a dialog for generating a PostScript file. The dialog has options to set the pages to be printed and the PostScript file name. The file name can be '-' for stdout or '|command' to pipe the PostScript through a command, e.g., '|lpr'. So, this would not be a bug in xpdf. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
reassign 781253 cups-filters-core-drivers thanks On Wed 29 Apr 2015 at 11:31:52 +0200, Vincent Lefevre wrote: On 2015-04-29 09:23:05 +0100, Brian Potkin wrote: How does babel-bib.pdf print when Page Scaling is set to none in Evince? It sill prints in duplex. Ditto if I unselect Auto Rotate and Center. But if I select Select page size using document page size, then it no longer prints in duplex. A different printer here but more or less the same outcome. It appears necessary with both Evince and lp to have some sort of fit-to-page. Why not having it breaks duplex I do not know. Anyway, it is solution which makes lp/lpr behave, One way I got my printer to work with a foomatic driver was to set up a queue with -o pdftops-renderer-default=pdftops. That option isn't open to you but how does lp -d queue -o pdftops-renderer=pdftops babel-bib.pdf turn out? I think I'm running out of ideas (and paper) to pursue this with. Reassigning because cups-client doesn't seem the right place for this bug to be. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On 2015-04-29 15:27:17 +0100, Brian Potkin wrote: One way I got my printer to work with a foomatic driver was to set up a queue with -o pdftops-renderer-default=pdftops. That option isn't open to you but how does lp -d queue -o pdftops-renderer=pdftops babel-bib.pdf turn out? It prints on A4 in duplex. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
Control: reopen -1 Control: retitle -1 no duplex printing (two-sided) with lp or lpr of a letter PDF file on A4 paper Sorry for the late reply. In the mean time, I talked to the sysadmin and we did more tests. I'm reopening the bug since I have more information that could be useful to get a client-based solution (just like what evince does). I also have an option that works, but undocumented. The printer has A3 and A4 paper. With lp and lpr, A4 PDF files are printed in duplex mode as expected. The problem actually occurs with files having the letter page size. For such files (such as the one attached as an example), lp and lpr print them on A4 paper but one-sided; and xpdf using the lpr command (with no options) prints them two-sided, but on A3 paper. For xpdf, I had reported the bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781251 but I now wonder whether this is related and whether there may be a server problem too. Same problem if I convert the PDF file to PS with pdftops, then print the .ps file with lp: A3 paper, two-sided. On 2015-03-30 14:03:23 +0100, Brian Potkin wrote: On Mon 30 Mar 2015 at 11:30:26 +0200, Vincent Lefevre wrote: On 2015-03-27 19:12:13 +, Brian Potkin wrote: With a print queue set up for the Ricoh MP C3003 PS on a Wheezy machine (cups 1.5.3-5+deb7u4) and printing from Evince on an up-to-date Jessie machine using client.conf we get this for argv[5]: InputSlot=1Tray RPSRGBcorrect=DetailBright RPSDitherType=Auto RIwmSize=36 RIBannerPageMediaType=Auto LockedPrintPassword=None RIWMText=Confidential Rcmyksimulation=Off RIwmAngle=45Deg Booklet=None RPSColorRendDict=Auto RIPaperPolicy=PromptUser RPSBlackMode=gray noRPSColorUniversalDesign PageSize=A4 JobType=Normal noRIBannerPagePrint RIPrintMode=0rhit MediaType=Auto RIRotateBy180=Off RIwmTextStyle=Gray RIBannerPageInputSlot=Auto ColorModel=CMYK Rimagesm=Off number-up=1 noRPSBlackOverPrint RIOrientOvr=Off Resolution=600dpi RPSColorSep=None DocServerPassword=None UserCode=None Duplex=DuplexNoTumble RIwmFont=HelveticaB RIWatermark=Off OutputBin=Default RPSBitsPerPixel=1BitsPerPixel job-uuid=urn:uuid:56b63b42-349d-3379-4399-f9ae15d99b13 job-originating-host-name=192.168.7.212 time-at-creation=1427480204 time-at-processing=1427480204 For 'lp -p test -o sides=two-sided-long-edge file.pdf' it is: finishings=3 number-up=1 sides=two-sided-long-edge job-uuid=urn:uuid:a9eacec3-3b00-30c4-799f-677abbbdb0d3 job-originating-host-name=192.168.7.212 time-at-creation=1427480636 time-at-processing=1427480636 Duplex=DuplexNoTumble If I use lp -o InputSlot=1Tray -o RPSRGBcorrect=DetailBright -o RPSDitherType=Auto -o RIwmSize=36 -o RIBannerPageMediaType=Auto -o LockedPrintPassword=None -o RIWMText=Confidential -o Rcmyksimulation=Off -o RIwmAngle=45Deg -o Booklet=None -o RPSColorRendDict=Auto -o RIPaperPolicy=PromptUser -o RPSBlackMode=gray -o noRPSColorUniversalDesign -o PageSize=A4 -o JobType=Normal -o noRIBannerPagePrint -o RIPrintMode=0rhit -o MediaType=Auto -o RIRotateBy180=Off -o RIwmTextStyle=Gray -o RIBannerPageInputSlot=Auto -o ColorModel=CMYK -o Rimagesm=Off -o number-up=1 -o noRPSBlackOverPrint -o RIOrientOvr=Off -o Resolution=600dpi -o RPSColorSep=None -o DocServerPassword=None -o UserCode=None -o Duplex=DuplexNoTumble -o RIwmFont=HelveticaB -o RIWatermark=Off -o OutputBin=Default -o RPSBitsPerPixel=1BitsPerPixel babel-bib.pdf or -o media=a4, I still get one-sided printing. So, it seems that these options do not matter, or different ones are used on my machine (but I don't know which ones). I've googled a bit, and found a solution given here: http://www.unix.com/302870967-post7.html Here, lp -o fitplot -o pdf-page=A4 babel-bib.pdf prints on A4 paper, two-sided. However: * These options are undocumented. I don't know what they are supposed to do and how they have been found. * I wonder whether lp could do the right thing automatically. In both cases the client has sent the PDF and the correct options. At this stage cups-client appears to have done its job correctly. Is there a way to know that it is also the case on my machine with the client.conf I'm using? As root here: ngrep port 631 cupsfile Unfortunately I have to use 443, and this is encrypted. The versions for cups and foomatic related packages would be useful to know. The versions on the print server? Yes. The processing of the job takes place there. The server is a standard Debian/wheezy machine, with: foomatic-db 20120523-1 foomatic-db-engine 4.0.8-3 foomatic-filters 4.0.17-1 cups 1.5.3-5+deb7u5 On 2015-04-19 20:13:32 +0100, Brian Potkin wrote: On Wed 01 Apr 2015 at 15:01:14 +0100, Brian Potkin wrote: /usr/share/doc/shared-mime-info/shared-mime-info-spec.pdf should be on your system. Pages 18 and 19 of it were printed here. I captured the PostScript
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On 2015-03-27 19:12:13 +, Brian Potkin wrote: On Fri 27 Mar 2015 at 11:27:41 +0100, Vincent Lefevre wrote: On 2015-03-27 09:46:55 +, Brian Potkin wrote: Evince is very likely using 'Duplex=DuplexNoTumble' when the file gets to the server. How does 'lp -o Duplex=DuplexNoTumble file.pdf' fare? Same problem. With a print queue set up for the Ricoh MP C3003 PS on a Wheezy machine (cups 1.5.3-5+deb7u4) and printing from Evince on an up-to-date Jessie machine using client.conf we get this for argv[5]: InputSlot=1Tray RPSRGBcorrect=DetailBright RPSDitherType=Auto RIwmSize=36 RIBannerPageMediaType=Auto LockedPrintPassword=None RIWMText=Confidential Rcmyksimulation=Off RIwmAngle=45Deg Booklet=None RPSColorRendDict=Auto RIPaperPolicy=PromptUser RPSBlackMode=gray noRPSColorUniversalDesign PageSize=A4 JobType=Normal noRIBannerPagePrint RIPrintMode=0rhit MediaType=Auto RIRotateBy180=Off RIwmTextStyle=Gray RIBannerPageInputSlot=Auto ColorModel=CMYK Rimagesm=Off number-up=1 noRPSBlackOverPrint RIOrientOvr=Off Resolution=600dpi RPSColorSep=None DocServerPassword=None UserCode=None Duplex=DuplexNoTumble RIwmFont=HelveticaB RIWatermark=Off OutputBin=Default RPSBitsPerPixel=1BitsPerPixel job-uuid=urn:uuid:56b63b42-349d-3379-4399-f9ae15d99b13 job-originating-host-name=192.168.7.212 time-at-creation=1427480204 time-at-processing=1427480204 For 'lp -p test -o sides=two-sided-long-edge file.pdf' it is: finishings=3 number-up=1 sides=two-sided-long-edge job-uuid=urn:uuid:a9eacec3-3b00-30c4-799f-677abbbdb0d3 job-originating-host-name=192.168.7.212 time-at-creation=1427480636 time-at-processing=1427480636 Duplex=DuplexNoTumble In both cases the client has sent the PDF and the correct options. At this stage cups-client appears to have done its job correctly. Is there a way to know that it is also the case on my machine with the client.conf I'm using? The duplex options also appear to have been injected into PS stream and the PS file produced ihere after traversing the filtering system on the server seems to reflect this correctly. %%Requirements: duplex %%BeginFeature: *Duplex DuplexNoTumble /Duplex true /Tumble falsesetpagedevice %%EndFeature Do we assume you do not have access to the server logs? I don't, but I can ask the sysadmin. The versions for cups and foomatic related packages would be useful to know. The versions on the print server? -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On Mon 30 Mar 2015 at 11:30:26 +0200, Vincent Lefevre wrote: On 2015-03-27 19:12:13 +, Brian Potkin wrote: With a print queue set up for the Ricoh MP C3003 PS on a Wheezy machine (cups 1.5.3-5+deb7u4) and printing from Evince on an up-to-date Jessie machine using client.conf we get this for argv[5]: InputSlot=1Tray RPSRGBcorrect=DetailBright RPSDitherType=Auto RIwmSize=36 RIBannerPageMediaType=Auto LockedPrintPassword=None RIWMText=Confidential Rcmyksimulation=Off RIwmAngle=45Deg Booklet=None RPSColorRendDict=Auto RIPaperPolicy=PromptUser RPSBlackMode=gray noRPSColorUniversalDesign PageSize=A4 JobType=Normal noRIBannerPagePrint RIPrintMode=0rhit MediaType=Auto RIRotateBy180=Off RIwmTextStyle=Gray RIBannerPageInputSlot=Auto ColorModel=CMYK Rimagesm=Off number-up=1 noRPSBlackOverPrint RIOrientOvr=Off Resolution=600dpi RPSColorSep=None DocServerPassword=None UserCode=None Duplex=DuplexNoTumble RIwmFont=HelveticaB RIWatermark=Off OutputBin=Default RPSBitsPerPixel=1BitsPerPixel job-uuid=urn:uuid:56b63b42-349d-3379-4399-f9ae15d99b13 job-originating-host-name=192.168.7.212 time-at-creation=1427480204 time-at-processing=1427480204 For 'lp -p test -o sides=two-sided-long-edge file.pdf' it is: finishings=3 number-up=1 sides=two-sided-long-edge job-uuid=urn:uuid:a9eacec3-3b00-30c4-799f-677abbbdb0d3 job-originating-host-name=192.168.7.212 time-at-creation=1427480636 time-at-processing=1427480636 Duplex=DuplexNoTumble In both cases the client has sent the PDF and the correct options. At this stage cups-client appears to have done its job correctly. Is there a way to know that it is also the case on my machine with the client.conf I'm using? As root here: ngrep port 631 cupsfile The duplex options also appear to have been injected into PS stream and the PS file produced ihere after traversing the filtering system on the server seems to reflect this correctly. %%Requirements: duplex %%BeginFeature: *Duplex DuplexNoTumble /Duplex true /Tumble falsesetpagedevice %%EndFeature The versions for cups and foomatic related packages would be useful to know. The versions on the print server? Yes. The processing of the job takes place there. Cheers, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On 2015-03-27 09:46:55 +, Brian Potkin wrote: Evince is very likely using 'Duplex=DuplexNoTumble' when the file gets to the server. How does 'lp -o Duplex=DuplexNoTumble file.pdf' fare? Same problem. Do we assume you do not have access to the server logs? I don't, but I can ask the sysadmin. What is the make and model of the printer? Ricoh MP C3003 PS -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On Thu 26 Mar 2015 at 19:21:01 +0100, Vincent Lefevre wrote: On 2015-03-26 16:41:53 +, Brian Potkin wrote: Please post what you get for 'lpoptions -l'. The following line indicates that 'sides=...' should be acceptable as an option used with lp/lpr and the default print queue. Mystifying. Duplex/Duplex: None *DuplexNoTumble DuplexTumble Evince is very likely using 'Duplex=DuplexNoTumble' when the file gets to the server. How does 'lp -o Duplex=DuplexNoTumble file.pdf' fare? Do we assume you do not have access to the server logs? What is the make and model of the printer? Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On Fri 27 Mar 2015 at 11:27:41 +0100, Vincent Lefevre wrote: On 2015-03-27 09:46:55 +, Brian Potkin wrote: Evince is very likely using 'Duplex=DuplexNoTumble' when the file gets to the server. How does 'lp -o Duplex=DuplexNoTumble file.pdf' fare? Same problem. With a print queue set up for the Ricoh MP C3003 PS on a Wheezy machine (cups 1.5.3-5+deb7u4) and printing from Evince on an up-to-date Jessie machine using client.conf we get this for argv[5]: InputSlot=1Tray RPSRGBcorrect=DetailBright RPSDitherType=Auto RIwmSize=36 RIBannerPageMediaType=Auto LockedPrintPassword=None RIWMText=Confidential Rcmyksimulation=Off RIwmAngle=45Deg Booklet=None RPSColorRendDict=Auto RIPaperPolicy=PromptUser RPSBlackMode=gray noRPSColorUniversalDesign PageSize=A4 JobType=Normal noRIBannerPagePrint RIPrintMode=0rhit MediaType=Auto RIRotateBy180=Off RIwmTextStyle=Gray RIBannerPageInputSlot=Auto ColorModel=CMYK Rimagesm=Off number-up=1 noRPSBlackOverPrint RIOrientOvr=Off Resolution=600dpi RPSColorSep=None DocServerPassword=None UserCode=None Duplex=DuplexNoTumble RIwmFont=HelveticaB RIWatermark=Off OutputBin=Default RPSBitsPerPixel=1BitsPerPixel job-uuid=urn:uuid:56b63b42-349d-3379-4399-f9ae15d99b13 job-originating-host-name=192.168.7.212 time-at-creation=1427480204 time-at-processing=1427480204 For 'lp -p test -o sides=two-sided-long-edge file.pdf' it is: finishings=3 number-up=1 sides=two-sided-long-edge job-uuid=urn:uuid:a9eacec3-3b00-30c4-799f-677abbbdb0d3 job-originating-host-name=192.168.7.212 time-at-creation=1427480636 time-at-processing=1427480636 Duplex=DuplexNoTumble In both cases the client has sent the PDF and the correct options. At this stage cups-client appears to have done its job correctly. The duplex options also appear to have been injected into PS stream and the PS file produced ihere after traversing the filtering system on the server seems to reflect this correctly. %%Requirements: duplex %%BeginFeature: *Duplex DuplexNoTumble /Duplex true /Tumble falsesetpagedevice %%EndFeature Do we assume you do not have access to the server logs? I don't, but I can ask the sysadmin. The versions for cups and foomatic related packages would be useful to know. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On Thu 26 Mar 2015 at 15:12:25 +0100, Vincent Lefevre wrote: On 2015-03-26 15:00:02 +0100, Vincent Lefevre wrote: When I print a PDF file with just lpr file.pdf or explicitly two-sided with lpr -o sides=two-sided-long-edge file.pdf, the output is done only on one side of the paper. There's no such problem with Evince (same machine, same printer). Same problem with lp from cups-client. Since cups-bsd depends on cups-client, I'm reassigning the bug to cups-client. And raising to important since there seems to be no way to get duplex printing from the command line, which is a major problem for big documents. Hello Vincent. Thank you for your report. Please post what you get for 'lpoptions -l'. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
On 2015-03-26 16:41:53 +, Brian Potkin wrote: Please post what you get for 'lpoptions -l'. OptionTray/Option Tray: NotInstalled 1Cassette LCT *2Cassette LargeCapacityTray/Large Capacity Tray: *NotInstalled Installed InnerTray2/Internal Tray 2: *NotInstalled Installed ShiftTray/Internal Shift Tray: *NotInstalled Installed ExternalTray/External Tray: *NotInstalled Installed Finisher/Finisher: NotInstalled FinRUBICONB FinAMURBK *FinAMUR RIPaperPolicy/Fit to Paper: PromptUser *NearestSizeAdjust NearestSizeNoAdjust PageSize/Media Size: A3 *A4 A5 A6 B4 B5 B6 Legal GovernmentLG EngQuatro Letter Statement F Folio FanFoldGermanLegal Tabloid 12x18 11x15 10x14 SRA3 SRA4 Executive Env10 EnvMonarch EnvC5 EnvC6 DLEnv 8Kai 16Kai A3.FullBleed A4.FullBleed A5.FullBleed A6.FullBleed B4.FullBleed B5.FullBleed B6.FullBleed Legal.FullBleed GovernmentLG.FullBleed EngQuatro.FullBleed Letter.FullBleed Statement.FullBleed F.FullBleed Folio.FullBleed FanFoldGermanLegal.FullBleed Tabloid.FullBleed 12x18.FullBleed 11x15.FullBleed 10x14.FullBleed SRA3.FullBleed SRA4.FullBleed Executive.FullBleed Env10.FullBleed EnvMonarch.FullBleed EnvC5.FullBleed EnvC6.FullBleed DLEnv.FullBleed 8Kai.FullBleed 16Kai.FullBleed Custom.WIDTHxHEIGHT InputSlot/Media Source: MultiTray 1Tray 2Tray 3Tray 4Tray 5Tray *Auto Duplex/Duplex: None *DuplexNoTumble DuplexTumble Resolution/Resolution: 600dpi *1200dpi Collate/Collate: *False True RIPrintMode/Print Mode: *0rhit 3rhit Rimagesm/Image Smoothing: *Off On Auto 90ppi 150ppi 200ppi 300ppi ColorModel/Color Mode: CMYK *Gray RPSBitsPerPixel/Gradation: 2BitsPerPixel *1BitsPerPixel 4BitsPerPixel RPSRGBcorrect/Color Setting: None DetailNormal *DetailBright RPSColorRendDict/Color Profile: *Auto Photograph Business Colorimetric POP User Clpsimulation1 Clpsimulation2 Clpsimulation4 Clpsimulation RPSColorUniversalDesign/Barrier-free Color Management: *False True RPSDitherType/Dithering: *Auto Photo Letter User Dispersion RPSBlackMode/Gray Reproduction (Text/Line Art): *gray 1Color 4Color grayText 1ColorText RPSBlackOverPrint/Black Over Print: *False True RPSColorSep/Separate into CMYK: *None Cyan Magenta Yellow Black Red Green Blue KCyan KMagenta KYellow Rcmyksimulation/CMYK Simulation Profile: *Off USOffsetPrint Euroscale JapanColor PANTONE MediaType/Paper Type: *Auto Plain1 Recycled Special1 Special2 Special3 Colored Letterhead Preprinted Labels Coated Bond Cardstock OHP Thick1 Thick2 Thick3 Thick4 Thin Middlethick Glossy Envelope None OutputBin/Destination: *Default Standard Bin1 Shift External FinRUBICONBShift FinAMURBKUpper FinAMURBKShift FinAMURBKLower FinAMURUpper FinAMURShift StapleLocation/Staple: *None UpperLeft UpperRight LeftW RightW UpperW CenterW RIPunch/Punch: *None Left2 Left3 Left4 Right2 Right3 Right4 Upper2 Upper3 Upper4 RIFoldType/Fold Type: *None OutsideTwofold RIRotateBy180/Rotate by 180 degrees: *Off On RIOrientOvr/Orientation Override: *Off Landscape Portrait RIWatermark/Watermark: *Off On RIWMText/Watermark Text: *Confidential Copy Copyright Final FileCopy Proof TopSecret RIwmFont/Watermark Font: CourierB TimesB *HelveticaB RIwmSize/Watermark Size: 24 *36 48 60 72 RIwmAngle/Watermark Angle: 180Deg 135Deg 90Deg *45Deg 0Deg M45Deg M90Deg M135Deg M180Deg RIwmTextStyle/Watermark Style: *Gray Outline RIBannerPagePrint/Banner Page: *False True RIBannerPageInputSlot/Banner Page Input Tray: *Auto MultiTray 1Tray 2Tray 3Tray 4Tray 5Tray RIBannerPageMediaType/Banner Page Paper Type: *Auto Plain1 Recycled Special1 Special2 Special3 Colored Letterhead Preprinted Labels Coated Bond Cardstock OHP Thick1 Thick2 Thick3 Thick4 Thin Middlethick Glossy Envelope Booklet/Booklet: *None OpenToLeft OpenToRight JobType/JobType: *Normal SamplePrint LockedPrint DocServer LockedPrintPassword/Locked Print Password (4-8 digits): *None 4001 4002 4003 Custom.PASSWORD DocServerPassword/Document Server Password (4-8 digits): *None 3001 3002 3003 Custom.PASSWORD UserCode/User Code (up to 8 digits): *None 1001 1002 1003 Custom.PASSWORD -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781253: cups: no duplex printing (two-sided) with lp or lpr
Control: reassign -1 cups-client 1.7.5-11 Control: retitle -1 cups: no duplex printing (two-sided) with lp or lpr Control: severity -1 important On 2015-03-26 15:00:02 +0100, Vincent Lefevre wrote: When I print a PDF file with just lpr file.pdf or explicitly two-sided with lpr -o sides=two-sided-long-edge file.pdf, the output is done only on one side of the paper. There's no such problem with Evince (same machine, same printer). Same problem with lp from cups-client. Since cups-bsd depends on cups-client, I'm reassigning the bug to cups-client. And raising to important since there seems to be no way to get duplex printing from the command line, which is a major problem for big documents. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
