IPP> registered parameters

IPP> registered parameters

Norbert Schade norbertschade at oaktech.com
Fri Nov 10 10:22:52 EST 2000


Some operating systems insist to be informed about certain features.
Print media sizes are a good sample.
A universal client/driver has to know about all predefined parameters for
all features any OS is interested in. There is no way around it!
There are two ways to go:
1. A universal description like UPDF lists all keywords for all OS (the list
is not too big) and offers the developer of the description a list of
predefined parameters.
For the sample print media size this could come out as a combo for
registered MS Windows parameters. There could be another combo for McIntosh
parameters and other combos, if Linux has new requirements.
2. We use a common reference and leave the conversion from the common
reference to the OS specific one to the client/driver. In this case the list
MUST be a superset of all registered parameters for all features in all OS.
2a. In the last UPDF conference we were talking about using registered IPP
values as a common reference.
The question is whether IPP wants to extend their lists to the required
amount.
For the sample print media sizes MS Windows is supporting about a good 100
predefined values, which of course then all must be supported.
2b. Theoretically there is the chance that the UPDF group makes up its own
list.
But we want to be very careful not to confuse developers with just another
list of parameters.

As far as I know the list includes the following features:
Print media size
Page orientation
Print media source
Duplex
Print media type

There some more when it comes to Print quality or Font handling like
download formats.

In Boston the UPDF group requested to find out how much IPP can and will
provide the necessary list. That would require to extend  some lists and
maybe create new ones in IPP.
It is to be discussed whether this would just be a merge of all known
predefined parameters or IPP tries to sort out doubles and minimize the list
as much as possible. This would leave some responsibility (and chances for
error) to the driver developer.
I need feedback on this during the upcoming week.

Selection 1 would leave that responsibility to the developer of the UPDF.
He'd have to do some more entries, but has more flexibility on the other
hand to specify a certain feature exactly as he wants.
It would be easier for driver developers. They'd just read the proper field
for their announcements.

We have to decide on this the next days. It is an important detail in the
UPDF spec.
So please provide your comments in the distributor.

Regards
Norbert Schade




More information about the Ipp mailing list