Tom, Babak:
We had better not be defining a NEW page description language (PS,
PCL, etc.)! I do not see it being done and I hope this is NOT being done.
However, there is a need to tell the print service (IPP for one) about
some of the information that had to date been opaque (not there or only
embedded in the PDL.) In IPP, this info is all of the job attributes:
document format, sides, copies, media requested, finishing requested,
compression algorithm used, etc.
Scott I.
>>> Babak Jahromi <babakj at MICROSOFT.com> 04/03/97 12:46pm >>>
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