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

IOS 7 clients fail to send IPP jobs in duplex #4357

Closed
michaelrsweet opened this issue Jan 30, 2014 · 2 comments
Closed

IOS 7 clients fail to send IPP jobs in duplex #4357

michaelrsweet opened this issue Jan 30, 2014 · 2 comments
Labels
priority-low wontfix This will not be worked on
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

Version: 1.7.1
CUPS.org User: mbowie

We have been using IPP / AirPrint with IOS 6 clients for some time. With the adoption of IOS 7, we found that clients would see the printer and could print simplex, but if duplex was set on the client device, the job would not be sent to the CUPS spooler at all. (This was also reported on https://discussions.apple.com/message/23464216)

Testing with the IOS Simulator, the console logs ': [ipp-hostname]: Print-Job failed: Unsupported sides "two-sided-long-edge".' I compared PCAP's from this vs devices which were working, and bit for bit, the duplex IPP attributes matched, so I assumed the message is a bit of a misnomer or is generated in the context of a larger issue.

I setup an ipptool script to compare the values I was getting from a number of various hosts and after some tweaks to test/ippserver.c, ultimately came to the conclusion that having the urf-supported attribute returned by the spooler with "certain values" resulted in the job being submitted successfully. (I had hoped to include some form of logic around the URF values returned, but have not done terribly well at finding a reference which documents it.)

As a disclaimer, I've no familiarity with the CUPS source and I've done this with some degree of haste... but the attached patch (targeted for 1.7.1) is working for me here in testing.

Hope this is of some help to others. If anyone is interested in a similar hack for 1.5.x, I'll be putting that together for some of our systems also. If I manage to come across some reference for the URF values in question (or URF in general) I'll see about adding some selection logic to the patch.

Best,

Mike.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

CUPS does not support iOS. The two are not compatible,

@michaelrsweet
Copy link
Collaborator Author

"patch-scheduler_printers.c":

$NetBSD$
Enable the IPP urf-support attribute to keep IOS 7 duplexing possible

--- scheduler/printers.c.orig 2014-01-30 13:44:34.000000000 -0800
+++ scheduler/printers.c 2014-01-30 13:47:52.000000000 -0800
@@ -3464,6 +3464,29 @@
snprintf(mimetype, sizeof(mimetype), "%s/%s", type->super, type->type);

 attr->values[i].string.text = _cupsStrAlloc(mimetype);
  • /*
  • \* IOS 7 will throw 'Unsupported sides "two-sided-long-edge"' if it doesn't
    
  • \* get the "urf-supported" attribute returned, with something resembling
    
  • \* the following.
    
  • */
    
  • if ((_cups_strcasecmp(attr->values[i].string.text, "image/urf")) == 0)
  • {
  •    cupsdLogMessage(CUPSD_LOG_DEBUG2,
    
  •                    "Adding \"urf-supported\" to IPP printer attributes");
    
  •    static const char \* const urf_strings[] =
    
  •    {
    
  •      "CP1",
    
  •      "RS300-600",
    
  •      "SRGB24",
    
  •      "W8",
    
  •      "DM3"
    
  •    };
    
  •    ippAddStrings(p->attrs, IPP_TAG_PRINTER, IPP_TAG_KEYWORD,
    
  •                  "urf-supported", 5, NULL, urf_strings);
    
  • }
    }

#if defined(HAVE_DNSSD) || defined(HAVE_AVAHI)

@michaelrsweet michaelrsweet added priority-low wontfix This will not be worked on labels Mar 17, 2016
@michaelrsweet michaelrsweet added this to the Stable milestone Mar 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-low wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant