> >What about other files (.doc, .prz, .ppt, .xls, .mov, .avi, .pdf,
> >etc.)? Does the printer have to have code to handle all of these?
>> Not unless you can watch movies on a piece of paper :)
> Seriously, there are some data types that shouldn't HAVE to be printed.
> That's the whole point of a PDF file (which should be handled).
Hmmm... Interesting thought. (Not about movies on the printer, but
being able to handle a wide variety of data types.. ;-)
Say I am an IPP client and I tell my friendly IPP server to print a file.
In that request I declare the incoming data type to be "crap-from-mars".
Of course, the IPP server (only recognizing "crap-from-earth") would
reject the request out of hand.
In the case of Print-by-Reference, why wouldn't the printer just reject
the client request once it has realized that the target URL contains
data of an unsupported type? Granted, this assumes the entire printing
process is lock-step-sequential, whereby the client remains connected
to the server during the print processing, or at least long enough for
the server to know whether it can actually print the requested job.
If, on the other hand, the IPP server queues the Print-by-Reference
request, then wouldn't it seem reasonable for the server implementation
to simply print an "error page" in place of the actual print data?
In either case the job status information would reflect the actual
final outcome.
Doesn't seem like that big of a deal. Of course, I don't develop
printers for a living... ;-)
Just some thoughts.
...jay