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:hastings at cp10.es.xerox.com]
> Sent: Tuesday, April 01, 1997 2:03 PM
> To: Babak Jahromi
> Cc: ipp at pwg.org> 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