[cups-devel] [UNKN] STR #4494: FINAL_CONTENT_TYPE incorrectly always set to printer/*
noreply at cups.org
Tue Nov 18 06:38:25 PST 2014
-----BEGIN PGP SIGNED MESSAGE-----
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
So, the reason we'd been using that patch was to deal with the situation
where a client CUPS server (A) sends a job to a remote CUPS server (B), but
both A and B have the same PPD configured for their queues... and that's a
In this situation, the PPD has e.g.:
*cupsFilter: "application/vnd.cups-pdf 0 foomatic-rip"
and so FINAL_CONTENT_TYPE, the "MIME type associated with the printer", is
set to application/vnd.cups-pdf. Of course, that's not at all what the ipp
backend on A receives: it receives data ready for the printer.
However, it sends document-format="$FINAL_CONTENT_TYPE" to CUPS server B
which promptly fails the job as it is invalid PDF.
We no longer apply that patch in Fedora, and bug reports are coming in
about setups that have Foomatic PPDs configured on both ends of a remote
Pierre is quite right in stating the problem as:
"No environment variable contains the actual format, so right now backends
have to resort to trying to figure out the type from the content, which is
less than ideal."
Fix Version: Third-party
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: GPGTools - https://gpgtools.org
-----END PGP SIGNATURE-----
More information about the cups