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

From: Babak Jahromi <[email-masked]>
Date: Thu, 3 Apr 1997 11:46:19 -0800

Tom,

Could you elaborate more on what kind of data the printer driver
(running on the client machine) would report to GDI via such new call?
What I am not clear is whether IPP is attempting to define a new printer
data format?

Today, either the raw data (PS, PCL, etc.) is produced by the resident
driver and then sent across the wire, or a Windows Meta file is created,
and shipped across. Now if the driver wanted to embed IPP-centric
network-based resources in the data stream that is sent over the wire,
we would need to define a new IPP printer data language. Is this being
done??

Babak

> -----Original Message-----
> From:	Tom Hastings [SMTP:[email-masked]]
> Sent:	Tuesday, April 01, 1997 2:03 PM
> To:	Babak Jahromi
> Cc:	[email-masked]
> Subject:	IPP> MOD - Suggestion: add RequiredResources call to
> Windows GDI to help drivers emit IPP job submission input parameters
> 
> Babak,
> 
> The last IPP meeting was an opportunity for all parties in the
> printing
> food chain to get together and discuss problems.  As we discussed, IPP
> is attempting to (1) continue to cater to the current predominant
> printing
> paradigm of an application generating GDI calls to the operating
> system
> which either produces a print data stream to a printer or video to a
> screen transparently to the application program and (2) enable a new
> printing paradigm of printing pre-formatted documents that need not be
> resident on the desktop machine any time during the process 
> (print-by-reference using URLs to the documents).
> 
> In so doing, IPP seeks to separate the print job instructions from the
> document data.  Such a separation causes a problem for print drivers
> in that they are not aware of all the resources that a document needs
> until the last GDI call.  By document resources, I'm including: media,
> fonts,
> color, etc.  Therefore, the print driver has a problem outputting the
> print 
> job instructions, including resource requirements, up front in the IPP
> 
> protocol.  While spooling the document on the client allows a second
> pass
> (the unspool) to copy the document resources that the Printer driver 
> recordrf at the end of the document to the front of the IPP
> stream on its way to the IPP printer, we'd like to evolve towards not
> requiring client spooling to support IPP.
> 
> When I discussed this problem with you at the IPP meeting, you
> suggested that
> I write an Email note to you suggesting a new function call be added
> to the
> GDI in which an application could declare up front all the resources
> that
> the document needs.  Then an IPP print driver could convert such a
> call to
> the proper IPP job level instructions when printing.  This new GDI
> call
> would also be useful for other printing protocols as well.
> 
> So here is that Email, belately.
> 
> Also the above discussion may want to be added to the IPP Model up
> front
> under 2. Simplified Printing Model.
> 
> Thanks,
> Tom

---

From: Tom Hastings <[email-masked]>
Date: Thu, 17 Apr 1997 11:04:20 PDT

Bacak,

Sorry not to reply sooner.  I hope that we can engage other IPP members
in this discussion as well.

Tom

>What I am not clear is whether IPP is attempting to define a new printer

IPP is attempting to define a job submission protocol that can be
used with ANY printer data format, so IPP is at a higher level than a
printer data format.  Furthermore, IPP is not defining a new printer
data format, becuase IPP must be used with some current (or new) printer
data format, such as PS, PCL, etc.  

However, the distinction between a job submission
protocol and a printer data format becomes fuzzy as printer data formats
add more job control.  But the simple test is that IPP is intended to
be used with ANY current or future printer data format.  One way of thinking
about IPP is that it will be a wrapper around the current printer data
formats and that the wrapper can be easily added at the sending end and
removed at the receiving end.

>we would need to define a new IPP printer data language. Is this being

We all agree that the current drivers should be able to work with an
IPP Printer or server.  In this scenario, it would be the port redirector
/print monitor that would add the IPP wrapper around the printer data.
In this case the IPP attributes would be ones that would be the same
for all jobs, such as the job-owner and the document-name.

However, what is not clear is how to introduce more IPP attributes into
the data stream.  It would be nice if the impact on existing printer
drivers was minimal.  That somehow the GDI calls would accept information,
such as resources required or embeded, that would get into the IPP wrapper 
without the drivers having to be modified.  Is that possible?

Tom