Harald,
Sorry, I missed this e-mail.
Tom
At 06:24 04/05/97 PST, Harald.T.Alvestrand at uninett.no wrote:
>Tom,
>naive question:
>Does the IPP print model have to include the possibility of the first
>portion of the document being printed before the request is completely
>sent to the printer?
We want to allow IPP to be implemented in a printer that doesn't have to
spool the data before starting to print. In other words, we want to allow
IPP to be used by simple desktop printers. Unfortunately, this does require
that resources be declared up front, not at the end. In fact we now
have a lot of experience with job submission protocols that allow the
job parameters to be at the end:
LPD - the control file is usually written after the data file, so that
desktop printers have already printed most of the data before
getting the control file and discovering that it was supposed to
be two-sided, or was supposed to use the transparencies medium.
That is one major reason that we cannot use LPD in this effort.
PostScript - PostScript as an AtEnd feature which is used for declaring
fonts and media. A Windows Print driver has no choice but to use
this AtEnd feature, since the windows print driver is fed GDI
a page at a time and has to produce the PDL as it goes. Hence the
suggestion in the original mail message to allow the application
(which know all the resources that will be needed before starting
to make the GDI calls to print the document) to pass on this valuable
information to the Print Driver in a new GDI call.
We need to put some kind of architecture assumptions into IPP along the
lines that IPP requires resource and job level parameters to be specified
first in the protocol, so that the recipient can act upon them for getting
all of the data. This does put a minor burden on clients, but is not too
difficult if the requirement is known to the client implementors.
NOTE- This requirement that the job parameters be first before the document
data is not just for desktop printers that don't spool.
As IPP gets used for "print-by-reference", where the document data is
only a reference to a document, such as a URL, the job parameters have
to be specified separately from the document data anyway.
A Printer (object) that controls multiple output devices may want to know
ahead of time about the job parameters. Perhaps the output device is going
to pull the actual data. Also many systems support multiple document
formats (PDLs), so that having the job parameters be separate and in a
PDL-independent representation will help such systems that would like to
avoid having to parse the PDL data twice: once looking for resources and
a second time to produce the hardcopy.
Tom
>>If not, why not design the protocol so that resource requirements can
>be attached to the *end* of the print request?
Been there, done that. Don't want to repeat such mistakes.
>>OTOH, I personally think that it would probably be better in version
>1.0 to take the "do or die approach": let the human or driver negotiate
>some resources (like A4 paper) up front, and then the job either prints
>or crashes. Just make sure the error report is right..... There's no
>way I can think of where one can negotiate on *every* resource one
>can think of - for instance, some *ancient* PostScript printers allowed
>you to put 68000 machine code into PostScript files; do you want to
>include negotiation on the CPU type in the printer?
Certainly not.
>>KISS.....
We agree. The hard part is deciding for which party to make it simple:
the client or the server/printer. Requiring job parameters to be first is a
little harder for the client (than allowing the client to put them last),
but make a hugh simplication for the server/printer. So the net is much
simpler to require job parameters to precede document data.
>> Harald A
>>