Bob really hit the nail on the head, though, with his discourse on the
fan-in problem:
> Let me illustrate where part of the problem lies. Fan-in has been a
> hot issue in email messages today. It exists for a world where the
> user cannot control feature selection directly through some client
> interface and instead controls feature selection via printer
> selection. Perhaps, we should assume that clients can select printer
> features directly. The requirements document is silent on this whole
> issue. Fan-in also exists to restrict access to some features by some
> users. But I wonder if this requirement is also too marginal to deal
> with for version 1.0.
>
> Fan-in is easy to address at the end-user level -- we just pretend they
> are separate printers. But at the administrative level, they will
> become a nightmare. For example, if an administrator changes the value
> of media in Printer A, does it also affect Printer B if both A and B
> fan-in to output device X. The answer should be yes because the paper
> is really in X and both A and B are really just views of X. But if B is
> intended to offer a restricted view of X, then perhaps the answer is no
> because B should not have access to whatever was changed.
After reading Bob's comments, I come away with the belief that if we
the PWG (representing the bulk of the printer and printing systems
industry) want to advance the state of printing in general, then we
should NOT support the existing "crutch" of "virtual printers" that
exist solely as a means of providing default job attributes.
I do, however, like the general concept of providing a "catalog" of
pre-formed "job tickets", similar to that found in NetWare. (Similar
approaches have been taken using the general "forms" concept.) However,
implementing such a capability via multiple "printer instances" results
in an absolute mess when you deal with the management and operational
aspects of the printing system.
I'd sure like to hear others' opinions on this subject.
...jay