STR 1795 broke remote IPP printing #1881
Comments
|
CUPS.org User: mike Try the attached patch and let me know if you still have problems... |
|
CUPS.org User: twaugh.redhat Reporter should be able to test this on Friday. |
|
CUPS.org User: twaugh.redhat There is apparently no change in behaviour with that patch applied. |
|
CUPS.org User: twaugh.redhat It turns out that remote_job gets set to 0 here: 2609 remote_job = printer->raw && job->num_files > 1 && At this point, printer->raw==0, job->num_files==1 -- the only condition that's true is the ipp:// prefix. I think the real problem is that STR #1795 was fixed wrongly. The FINAL_CONTENT_TYPE should be using the dst (not the src) of the last filter in the chain, as before, but if that ends up being "printer/*" then it should be replaced by "application/octet-stream" IMHO. |
|
CUPS.org User: mike Log files please (both client and server) with LogLevel set to "debug" on each... |
|
CUPS.org User: twaugh.redhat Attached. I'm also about to test a patch to replace printer/* with application/octet-stream in the appropriate place. |
|
CUPS.org User: twaugh.redhat cups-final-content-type.patch fixes the problem for me. |
|
CUPS.org User: mike No, that patch isn't correct either... I'm attaching a wider-reaching patch against both the IPP backend and scheduler which tracks whether a queue points to a remote printer/class and handles things accordingly. The mapping of printer/* to application/vnd.cups-raw is handled in the IPP backend, and it only falls back on application/octet-stream if the remote end doesn't handle application/vnd.cups-raw... Let me know how this works for you... |
|
CUPS.org User: twaugh.redhat It doesn't work. The problem is back now. |
|
CUPS.org User: twaugh.redhat In particular, for the configuration at issue (manually set-up IPP queue with PPD selected locally) the FINAL_CONTENT_TYPE given to the ipp backend is 'application/vnd.cups-postscript' (see job output from log, below). As you can see, ghostscript is run locally so there is no denying that this is now raw data -- but the ipp backend is told 'postscript'. I [22/Aug/2006:18:06:28 +0100] Job 25 queued on "raw" by "root". |
|
CUPS.org User: mike OK, third time's the charm; basically, this latest patch reverts the FINAL_CONTENT_TYPE change we made before (it is now set the the MIME type that the last filter produces, which can be printer/foo...), but now the IPP backend checks for printer/foo and reassigns it to application/vnd.cups-raw. If the server doesn't report support for application/vnd.cups-raw, then the IPP backend will fall back on application/octet-stream which is the right type to use with printers. I've tested this with both raw (hardwired client queue) and PCL (laserjet.ppd) drivers pointing to a PostScript LaserJet queue on another system and it seems to work properly with both configurations now. |
|
CUPS.org User: twaugh.redhat Yes, works fine here too. Thanks! |
|
"cups-test.patch": --- cups-1.2.2/scheduler/job.c.test 2006-08-03 15:17:05.000000000 +0100
|
|
"str1881.patch": Index: job.c--- job.c (revision 5801)
|
|
"cups-final-content-type.patch": --- cups-1.2.2/scheduler/job.c 2006-08-06 11:56:29.000000000 +0100
|
|
"str1881v2.patch": Index: backend/ipp.c--- backend/ipp.c (revision 5823)
/*
if (p->type & CUPS_PRINTER_REMOTE)
@@ -2556,17 +2555,10 @@ /*
- */
- !strncmp(printer->device_uri, "ipp://", 6);
cupsArrayDelete(filters);
|
|
"str1881v3.patch": Index: job.c--- job.c (revision 5872)
|
Version: 1.2.2
CUPS.org User: twaugh.redhat
Original bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201167
Manually creating an ipp://... queue for a remote CUPS printer no longer works. More detail:
Set up machine 'A' as CUPS server, with (say) HP printer attached. Create queue 'printer' and mark it shared. Uncomment application/octet stream lines in /etc/cups/mime.types and /etc/cups/mime.convs.
On machine 'B', also running CUPS, manually add a queue with an ipp://... URI to point to machine 'A's 'printer' queue. Print a test page to this queue.
Result: printer prints garbage
Attached is a patch that fixes this behaviour -- however, since it is just the patch from STR #1795 reversed, it will likely break that again.
The text was updated successfully, but these errors were encountered: