IPP Mail Archive: IPP> RE: [printing-cap] Capabilities API:

IPP Mail Archive: IPP> RE: [printing-cap] Capabilities API:

IPP> RE: [printing-cap] Capabilities API: Device Object [How about a M edia Object]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Thu Sep 26 2002 - 11:57:33 EDT

  • Next message: Carl: "IPP> FW: IPP"

    In addition to supporting the idea of adding a Media object,
    which we should add as a future to PAPI, IPP, and the PWG Semantic model,
    Michael wrote:

    " > ...
    > How about adding a member attribute to the "media-col":
    > "media-margin-sizes" (1setOf integer)

    I'm not sure adding it to the media-col attribute is the right
    solution, for the reasons I specified earlier (other attributes
    affect margins, too). It would probably be better to make it
    an attribute of its own, independent of the media-col/media/
    resolution/quality/etc. attributes."

    Good suggestion. So don't add margin sizes to the "media-col" Job Template

    So we'd add a media-margin-sizes (1setOf integer) Printer Description
    attribute that contains the 4 margin sizes.

    When the client supplies the job context in the papiPrinterQuery (or
    extended IPP Get-Printer-Attributes operation), the values returned reflect
    what is possible given the supplied job attributes.

    The only problem left is what to return when the job context supplied
    doesn't specify enough to return a single set of margins? For example, if
    the margins depend on the media size, but the job context didn't have a
    media size. Or as another example, suppose the margins depend on whether
    one-sided or two-sided printing is to be done, but the job context doesn't
    supply the "sides" attribute. How about just returning sets of 4 integers?
    Each set of 4 represents a possible set or margins depending on what is
    supplied with the job? So for example if the margin size is different for
    na-letter versus iso-a4, there would be 8 integers returned.

    Comment on papiPrinterQuery:
    I assume that when the caller omits most or all of the job context, that
    what is returned is more like all possible things supported, rather than
    assuming the defaults for each of the job context attributes. That should
    be clarified (along with the union versus intersection issue).


    This archive was generated by hypermail 2b29 : Thu Sep 26 2002 - 11:59:52 EDT