Concerning the desire for the creation of a Universal Print Driver, I
share
Jay's enthusiasm that such an effort might be a worthwhile task. We have
been discussing possibility within our group for awhile. From an
engineering perspective it would be really powerful to develop such a
driver, and I think the benefits are pretty obvious (as compared with
deploying, managing, and maintaining so many different kinds of drivers
for every kind of printer).
However (don't ya hate this word) I have been running up against the
problem wherein most corporate marketing (with engineering cooperation)
are always looking for ways to differentiate their product from the rest
of "the pack". Continually striving to give their product a competitive
advantage with regards to features and/or other market factors.
I'm not sure if we could design a flexible enough protocol or method
whereby we could automagically provide universal access for print
clients to a particular printer's features; and if you miss the mark
with
this goal, then you might have to have a very small "attachment" that
covers a particular products' feature that we didn't somehow think of
in architecting our driver.
We might be able to make our driver model so abstract as to cover
quite alot, but I'm not sure how hard this would be. My point is, if
manufacturer's end up producing even the smallest component that
is product-specific and takes into account something that the universal
driver didn't, then (to me) it takes away alot of the rationale from
spending the effort to create the univeral driver.
This drive to differentiate products and achieve competitive advantage
is quite strong. There is also ample experience with this type of effort
failing in the past. The Printer MIB was a perfect example of an effort
to "standardize" printer vendors and achieve interoperability with
regards
to printer management applications.
What did vendors do? They implemented the MIB because it has become
(more or less) a "check-off item" on purchase agents RFPs, but
unfortunately their printer management applications do NOT work with
any other vendor's MIB implementations (at least in the last round of
Printer MIB-capable host apps I evaluated). The host applications do
utilize the printer MIB in their respective products, but their
applications
screen out printers that originate from a different vendor. The killer
app
that we used to talk about in meetings 3 or 4 years ago has yet to be
written.
Understand that I still think the MIB effort was worthwhile, but the
goals
for its creation have yet to be realized. And like I stated previously,
the
Printer MIB does capture just about everything you probably want to
configure in a printer, but their still exist vendor-specific MIBs to
fill the
gap.
In summary, I do think the idea of a Universal Print Driver would be an
interesting engineering exercise, but we need sufficient rationale for
its
development and I'm not sure we'll ever come up with it. Most of the
features you stated in your feature set could be accomplished with
varying levels of effort to vendors' existing suite of drivers. Where I
agree with you most as far as rationale goes, is that I would love to
unload all the tons of printer drivers I have on my Win95 box and just
have to learn to work with a single printer driver. I'm just not sure if
this is possible.
I think Don Wright suggested in the past a potential standardization
effort for a standard hardware "extension interface" for printers, kinda
like what most printer vendors use for their external network interface
attachment. This was not received very well by some vendors because
it struck at the heart of what one or more companies may have
perceived as a core technology; something that gives them possibly a
competitive advantage over other vendors' products. I guess what I'm
saying is there the possibility that a Universal Printer Driver could
expose
the same type of constraint. In any case, should such an effort get
started,
I would think constraints such as these would have to be explicitly
dealt with in the charter of such a standards group.
(But like I said to begin with, its a neat idea and I wish we could
figure out
a way to do it...)
Randy
(Falling off my soapbox...)
JK Martin wrote:
> During the Model subgroup telecon today, the participants briefly
> touched on the concept of the "Universal Print Driver".
>> Unanimous consensus was quickly reached whereby the group believes
> print driver technology should move in a direction that is both
> simpler
> and more powerful in terms of integration and feature support.
>> Printer vendors have long realized that developing and supporting
> printer drivers is an expensive necessity that rarely helps--and
> usually inhibits--the business potential for printer products.
>> The telecon participants wanted to immediately commence an open
> discussion on the features and design of the "Universal Print
> Driver"
> that provides (among other things) these kinds of capabilities:
>> 1. Clear separation of job/document attributes and print data;
> that is, the driver should submit the print job in a
> declarative
> manner rather than the current procedural manner.
>> 2. Driver-level query of printer capabilities; when the user
> brings
> up a typical "Print" dialog box, the underlying driver should
> be
> able to quickly and *easily* acquire the target printer's
> current
> set of capabilities over the network, rather than relying on
> the
> existing method of "PPD" files and related static
> configuration data.
>> 3. The basic back-end of the driver should be absolutely platform
>> independent; only the front-end need be platform specific so
> as
> to better integrate with the underlying system user interface
> (whether it be graphical or textual).
>> These items represent the proverbial tip of the iceberg. What can
> you
> add to this list? (Either pro or con, by the way.) Do you think a
> universal print driver is an achievable reality?
>> IPP clearly holds the best chance for promoting and advancing such
> driver technology within the printer industry and marketplace.
> Let's
> get this discussion started as quickly as possible as the design of
> a
> Universal Print Driver may impact key decisions for the IPP Model.
>> ...jay
>> ----------------------------------------------------------------------
>> -- JK Martin | Email: jkm at underscore.com> --
> -- Underscore, Inc. | Voice: (603) 889-7000
> --
> -- 41C Sagamore Park Road | Fax: (603) 889-2699
> --
> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com> --
> ----------------------------------------------------------------------