One of my original concepts was to overload the resource objects and
have the values represent the requested value prior to the printer
processing the job and the actual value after. The primary reason
was to minimize the number of objects. When these objects were
deleted and replaced with the resource table, this idea had no
advantages and was abandon. The Resource Enums were to be unique
for "requested" and "actual" values. In reviewing the current
specification I notice that in some cases this is not true. For
example, sides(9) can be either requested or used. This should be
changed to be consistent. I will review the current set of enums
and correct where necessary.
I agree that in most cases the only values presented will be the
"actuals". (This is why I originally proposed overloading the
objects.) However, with the Resource Table, the printer can
present only those values desired and the number of objects will
be a minimum. In the rare case of a DPA printer, the entire set
of resource enums can be returned.
The more I look at the resource table, the more I agree with Tom
that it is a "win-win" situation. A DPA printer can present every
possible parameter and a real-world printer can present only the
useful values it can access. All of this without a large number
of objects in the MIB.
Ron Bergman
Dataproducts Corp.
rbergma at dpc.com
(805) 578-4421