Bug 1010580 killed FINAL_CONTENT_TYPE and forced every CUPS backend into raw mode. The patch added by that bug is horribly wrong and needs to be dropped ASAP. The original bug is something else with CUPS re-running a filter even though the data is already in the desired format. Possibly a bug in the relevant PPD.
Can you explain in a little more detail what's not working for you, and what your configuration is?
In short, we have a custom backend with a PPD with this in it: *cupsFilter: "application/pdf 0 -" With a normal CUPS, the backend will be called with FINAL_CONTENT_TYPE set to "application/pdf" if it is actually getting a PDF, and application/vnd.cups-raw or similar if it gets a raw print job. Your patch breaks this mechanism and forces FINAL_CONTENT_TYPE to always be "printer/<queue name>". There is absolutely no way for the backend to reliably determine the format of the input data when you patch is applied. The only reason your patch happens to work most of the time is because most printers don't give a rat's ass about the mime type and will treat everything as opaque data (which is what the ipp backend will flag everything printer/* as). Our backend happens to actually trust CUPS and gets wildly confused by your changes.
Have you had time to look at this? It causes quite a bit of problems for us.
I think FINAL_CONTENT_TYPE is the intended MIME type for the printer, not for the input file. Doesn't CONTENT_TYPE have the right value for you?
(In reply to Tim Waugh from comment #4) > I think FINAL_CONTENT_TYPE is the intended MIME type for the printer, not > for the input file. > Correct. But your patch forces it to be something else. The printer here _wants_ PDF. That's its native format. The problem is that it has multiple native formats and your patch makes it impossible to tell the difference. > Doesn't CONTENT_TYPE have the right value for you? It is, but it states the source file format, which is completely irrelevant to the backend.
I had a go at reproducing bug #1010580 (which caused us to revert the upstream patch in the first place) with a local build without final-content-type.patch applied, and I no longer can so hopefully we can drop the revert.
cups-2.0.0-4.fc22 cups-1.7.5-8.fc21 cups-1.7.5-7.fc20
cups-1.7.5-10.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/cups-1.7.5-10.fc21
cups-1.7.5-8.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/cups-1.7.5-8.fc20
Package cups-1.7.5-10.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cups-1.7.5-10.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-13104/cups-1.7.5-10.fc21 then log in and leave karma (feedback).
cups-1.7.5-11.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
cups-1.7.5-13.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.