From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <54345EF9.5010405@thax.hardliners.org> Date: Tue, 07 Oct 2014 23:45:29 +0200 From: Tobias Hoffmann MIME-Version: 1.0 References: <5B66FA40-ED1E-461E-B00F-D5CD6C7DBC30@apple.com> <34701921-5F04-411C-B35C-78CED619AAC3@apple.com> <5432910A.4030500@gmail.com> <54344707.4080604@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050202060902010400040302" Subject: Re: [Printing-architecture] Number of copies in pure PDF workflow List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Korobkin Cc: "printing-architecture@lists.linux-foundation.org" , Till Kamppeter This is a multi-part message in MIME format. --------------050202060902010400040302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/10/14 23:18, Alex Korobkin wrote: > 2014-10-07 16:03 GMT-04:00 Till Kamppeter >: > > pdftopdf uses cupsManualCopies. If cupsManualCopies is set in the PPD > software copies are done, otherwise hardware copies. If the printer > supports PJL, an appropriate command to generate the copies is > added to > the PJL header. > > > Till, I've just tested it again on my PDF printer and PJL-based PPD, > and pdftopdf creates software copies regardless of the value of > cupsManualCopies. Shouldn't it insert PJL SET COPIES=X when > cupsManualCopies is False or not present? > I'm not sure what exactly is happening in your setup. Maybe your PPD is missing something (- and I'm not an expert for PPD/PJL)? Maybe you don't have a recent cups-filters (>= 1.0.34)? Maybe you're hitting some edge-cases that are not handled correctly in the current code? AFAIK no-one else has reported a problem with PJL in a pure pdf workflow, and I can't find an obvious flaw in the code which deals with PJL in pdftopdf. The code is also basically copied over from the old pdftopdf implementation (cups-filters <=1.0.20); if your PPD does hw copy with the old implementation, but not with >=1.0.34, I will probably be able to fix that. Tobias --------------050202060902010400040302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/10/14 23:18, Alex Korobkin wrote:
2014-10-07 16:03 GMT-04:00 Till Kamppeter <till.kamppeter@gmail.com>:
pdftopdf uses cupsManualCopies. If cupsManualCopies is set in the PPD
software copies are done, otherwise hardware copies. If the printer
supports PJL, an appropriate command to generate the copies is added to
the PJL header.

Till, I've just tested it again on my PDF printer and PJL-based PPD, and pdftopdf creates software copies regardless of the value of cupsManualCopies. Shouldn't it insert PJL SET COPIES=X when cupsManualCopies is False or not present?


I'm not sure what exactly is happening in your setup.
Maybe your PPD is missing something (- and I'm not an expert for PPD/PJL)?
Maybe you don't have a recent cups-filters (>= 1.0.34)?
Maybe you're hitting some edge-cases that are not handled correctly in the current code?

AFAIK no-one else has reported a problem with PJL in a pure pdf workflow, and I can't find an obvious flaw in the code which deals with PJL in pdftopdf. The code is also basically copied over from the old pdftopdf implementation (cups-filters <=1.0.20); if your PPD does hw copy with the old implementation, but not with >=1.0.34, I will probably be able to fix that.

  Tobias

--------------050202060902010400040302--