Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JobSheets printed even when none requested #1220

Closed
michaelrsweet opened this issue Jul 12, 2005 · 5 comments
Closed

JobSheets printed even when none requested #1220

michaelrsweet opened this issue Jul 12, 2005 · 5 comments
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

Version: 1.1.23
CUPS.org User: leeg

Print server is Mac OS X 10.4.1, running CUPS 1.1.23. This bug seems to be printer-independent, appearing when printing to Minolta, Kyocera and Fiery printers.

All of my printers in printers.conf have the line:
JobSheets none none
however, in certain circumstances they will print a jobsheet without fail. The circumstances are these: printing to the CUPS machine via LPD from a NeXT running NeXTSTEP 3.3. I have isolated the CUPS machine by printing to the same printers directly from the NeXT, no jobsheet is included. I have also shown that the problem is due to an interaction between the NeXT and the CUPS machine - printing to the same printers via the same CUPS machine when the client is a Mac (printing via LPD or IPP to the CUPS server) doesn't produce a jobsheet. I can see no reason why the jobsheet should appear in these circumstances, and it is annoying as I cannot print directly to the Fiery from the NeXT because they don't communicate well. Neither can I let go of the past and ditch the NeXT; roughly 130 critical documents are stored on it in a format only readable by a particular NeXT application.

This is a regression since CUPS v1.1.19 which I used when the print server was a Mac OS X 10.3.9 box, and didn't have this bug.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: jlovell

This is a MacOSX specific issue and doesn't apply to standard CUPS 1.1.x.

It's happening because NeXTSTEP is sending the 'L' - Print banner page command in the lpd control file. In MacOSX 10.3.x this would cause a queue's "job-sheets" value to be used which was usually "none,none". In 10.4 this was changed to add the "standard" banner if the queue's default was none.

To disable banners add these lines to /System/Library/LaunchDaemons/printer.plist:

diff -u -d -b -w -r1.1 printer.plist
--- printer.plist 2005/01/04 19:30:11 1.1
+++ printer.plist 2005/07/12 18:48:19
@@ -11,6 +11,8 @@
/usr/libexec/cups/daemon/cups-lpd
-o
document-format=application/octet-stream

  •   <string>-o</string>
    
  •   <string>job-sheets=none,none</string>
    
    Sockets

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: jlovell

Michael, the change we made was in response to:
rdar://3948262 cups-lpd jobs don't enforce cover page settings

Attached is a 1.2 diff for your consideration. As the comment in the code says, if a banner is requested and it's not overridden by a command line option and the destination's default is none then we add the standard banner.

Thoughts? Thanks.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

That sounds like a reasonable approach. We might also add an option for cups-lpd to define the default banner page to use instead of standard.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: leeg

jlovell.apple - that does indeed revert to the expected behaviour, thanks very much for your help. If you've write access to rdar for printing bugs, may wish to close 4177352 (I've outlined the info you gave me here in that report).

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Fixed in Subversion repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant