Don Wright wrote:
> Jay Martin said:
> >If existing print drivers are considered "today's technology", then
>> >today's technology won't know anything about IPP, correct?
> >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?
> >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?
>> I hope we are all balled up in terminology not technology. From
> printer manufacturer's perspective, a printer driver creates the
> datastream for a printer. A "redirector" or "port driver" pushes
> datastream out the desired physical connection (parallel port,
> port, IPX/SPX ethernet, etc.)
>> My assumption is that IPP will work with today's drivers but
> new "redirector" or "port driver" software.
IPP should work fine with today's drivers, if, as you suggest, an IPP
is instrumented at a layer beneath the driver. However, existing drivers
be able to take advantage of any IPP-specific attribute specifications
capabilities. Existing drivers take user-specified job attributes and
into whatever PDL is going out; unfortunately, this would all be opaque
IPP port driver beneath the printer driver, so in this model, existing
drivers would just be using IPP as a transport.
In the IPP-aware driver situation, it would be possible for the GUI to
IPP, as well as, printer-specific attributes, that could be included in
outgoing data stream. It is unlikely in this scenario that a port driver
used underneath the IPP-aware printer driver. But it might be the case
HTTP-aware port driver could sit underneath the IPP-aware driver and
transport the IPP datastream coming from the driver.
I guess what I'm saying is there's going to be alot of ways to deploy
and existing print drivers can (and should) be supported.