Subject: Re: IPP> MOD - Suggestion: add RequiredResources call to Windows GDI to help drivers emit IPP job submission input parameters

From: Tom Hastings <[email-masked]>
Date: Sat, 3 May 1997 16:18:21 PDT

Harald,

Sorry, I missed this e-mail.

Tom

At 06:24 04/05/97 PST, [email-masked] 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

---

From: [email-masked]
Date: Mon, 05 May 1997 10:37:32 +0200

Frankly, I think that modifying the Windows GDI (and by extension
modifying every single application that prints through Windows)
is even more pie-in-the-sky than replacing every single printer
in the world. There are more of those beasties than there ever
were printers, and quite a few businesses that depend on software
that can't be modified for one reason or another.

So we've more or less settled that in the common case, there HAS
to be one link in the chain that can look at both ends of the job
at the same time, and understand enough about it to figure out
what its requirements are.

Print-by-URL is irrelevant to this discussion, since there
the distinction between parameters "before the URL" and "after the URL"
is pretty slim; they are both communicated to the printer before
the URL is dereferenced.

So - the spooler is there; just choose which side of the IPP-defined
interface you want it.

                      Harald A