>> = FDW
> = RT
>>
>> 2) Printing to a remote printer from an application on the
>> client (eg Word, Lotus 123, etc.) requires something
>> I'll call an IPP driver to be installed on the client. Perhaps
>> this is downloaded from the Web or comes as a part of
>> a new operating system but there's got to be some type
>> of "redirector" installed. "Push" and "Pull" printing can be
>> accomplished from a properly written WEB page and
>> an unassisted WEB browser, but transparent printing
>> from an application to a WEB printer requires additional
>> software.
>
>The above sentence with regards to "properly written WEB page"
>is not germain to IPP. We don't want content architected to be
>compliant with IPP. WEB authors should feel free to do whatever
>they want and not constrained by having to know how to have their
>content printed.
What I meant here was the WEB page for the print server. That
page must be written so as to provide a place to type in a URL
if the print server is expected to go out and retrieve the URL and
then print it ("pull model") and if it is written so the user can type in
a local file name and have it "pushed" to the server. This has
nothing to do with a vanilla page off the WEB.
>>
>> This is consistant with the directions I have seen from
>> several vendors working on solutions in this area. I
>> don't think any solution (HTTP, TCP Stream, etc.) can
>> solve the problems you mentioned without a new
>> "IPP Driver" being installed on the client.
>I think this statement is true as well, and if we want to rely
>on HTTP and browsers to deploy IPP, it complicates things
>dramatically. The user now has to know (or someone has to
>know) what type of browser (and platform the browser is running
>on) in order to properly provide the appropriate "driver" which
>I'm not sure if the term even applies to anything except the
>windows printing environment.
>
>I think the best technical solution for this would be to ask
>browser vendors to rethink their logic when the "Print"
>button is selected in their respective user interfaces. We need
>a hook into this process (maybe some sort of java applet) that
>handles printing over IPP. If the applet is loaded, it tries
>IPP, and if not loaded, it defaults to whatever platform
>printing environment is in use. Of course, this would render the
>existing installed base of browsers incapable of doing IPP.
This is all well and good if you can get the Browser developers
to do anything for printing other than call the OS specific print
APIs.
>The driver solution is going to be complicated and frought with
>issues (possibly licensing), and platform-dependence questions.
>I'm not saying it's impossible, it just severely gets in the
>way with our focus on designing a simple IPP.
It's our job to find a way to make this as painless as possible.
>Some of the issues with driver installation might include:
>
> 1. What browser is the user using?
Available from the browser
> 2. What OS platform is the browser installed on?
Available from the browser
> 3. Where do I get the driver?
Possible solutions including "Ask the printer?" "Administrator
configuration", others
> 4. Who will write the drivers and are there
> licensing issues involved?
All printer manufacturers love to give away their drivers through
as many sources as possible. It means they are selling more
hardware and using up supplies.
> 5. Will each IPP server have to have all possible
> platform/browser combinations of drivers loaded to
> support the widest possible audience?
All the ones they are interested in supporting.
> 6. Will driver installation require administrator
> intervention?
Only if administrators set-up the machines that way. Tough
luck if they do without including some generic drivers.
> 7. Will the user have to restart the OS or browser
> or both after installation? (and this varies depending
> upon the OS/print driver environment).
Usually not but if so I suspect the OS vendor will find a
work around to meet customer requirements.
Don