IPP> registered parameters

IPP> registered parameters

IPP> registered parameters

Mike Bartman bartman at process.com
Fri Nov 10 11:17:48 EST 2000

> From: Norbert Schade [mailto:norbertschade at oaktech.com]

> 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.

And what about HP-UX, Solaris, SunOS, OpenVMS (VAX and Alpha), BSD, UniCOS,
MVS, VM, BEOS, TOPS-10, TOPS-20, Q-DOS, MS-DOS, Coherent, and probably a few
dozen other OSs that are still in use in various places?  What about that
new OS that is going to be released next year (you know there will be one...
:^)?  What about variations in OS revision level that make for required
changes in driver code?

I'd say it's a lot better to specify the printer's capabilities in a
non-OS-specific way, then let the OS handle it any way it likes.  One of
these parameters could be a list of available driver codes that the OS's
client software could pick through to find one it is happy with, either
because it was written for that OS/version/platform, or because there is an
emulator present, or the driver is source code that can be built for any OS,
or whatever.

Trying to name every OS in existence is a losing proposition.

> 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.

...That the printer supports.  Describing the printer would seem to be the
most important thing.  Trying to predict what information an OS might be
able to handle, or want, is a lot harder.  The printer is closer to being a
"known entity" than the OS that will send to it is.

> 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.

There are OSs that don't have predefined media sizes.  In OpenVMS for
example, you can create a "form" that is specified by page length, page
width, upper, lower, right and left margins, and whether text that won't fit
is truncated or wrapped.  Width can be anything out to about 65,000 columns,
in single column increments.  Trying to name each possible combination is
possible, but not very wise!  These "forms" are separate from the media
types, which are arbitrary names (not sure what the name length limit
is...but it's at least a dozen ASCII characters), and any combination of
form and media type is legal as far as the printing subsystem is concerned.
This whole thing is oriented around line printers and operator-assisted form
changes, but this OS is also used to print to networked page printers too,
using the same printing sub-system.  LPD and Telnet protocols are the most
commonly used for printers not specifically designed for OpenVMS...which is
why IPP is of such great interest! :^)

-- Mike Bartman
   Process Software
   Principle Software Engineer

More information about the Ipp mailing list