> From jkm at underscore.com Mon May 5 15:14:09 1997
>> Bob,
>> > So we are stuck if we want to support today's technology before IPP
> > output devices arrive.
>> If existing print drivers are considered "today's technology", then
> today's technology won't know anything about IPP, correct?
Correct, but I am thinking UNIX when I talk about print servers that
inject PostScript into document data. This might happen via a client
GUI, via a client command, or via the selection of a particular logical
printer which causes the server inject some PostScript into the
document (e.g. duplexing).
>> Perhaps I'm missing something, then. Does anyone think that IPP is
> being designed such that today's print drivers can submit jobs to
> an IPP Printer?
I am assuming that in the Window's world, there could be an IPP Print
Provider for IPP printers which would take the PostScript or PCL file
received from the driver and forward it to the Printer using IPP protocol.
I wouldn't expect job attributes to play any role in this case.
>> Maybe that's where I'm getting confused. I'm making the assumption
> that to drive an IPP Printer, you need an IPP-aware print driver.
> Is this assumption incorrect?
If the driver wants to make use of dynamic attribute information, then
the driver needs to be IPP aware. But a driver/GUI could works as it
does currently with static awareness. It can communicate with an IPP Printer
via a new IPP Print Provider, or use the existing one (e.g. lpr). In
the latter case, the IPP Printer would have an lpr-to-IPP gateway.
>> ...jay
>