IPP Mail Archive: RE: IPP> registered parameters

RE: IPP> registered parameters

From: Mike Bartman (bartman@process.com)
Date: Fri Nov 10 2000 - 11:17:48 EST

  • Next message: Michael Sweet: "Re: IPP> registered parameters"

    > From: Norbert Schade [mailto:norbertschade@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



    This archive was generated by hypermail 2b29 : Fri Nov 10 2000 - 11:27:54 EST