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 [media-margin- sizes (1setOf integer)]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Sep 27 2002 - 16:49:16 EDT

  • Next message: Michael Sweet: "IPP> Re: [printing-cap] Capabilities API: Device Object [media-margin- sizes (1setOf integer)]"


    I have three issues about the media-margin-sizes (1setOf integer) Printer
    Description attribute. I disagree with the idea that papiPrinterQuery
    defaults omitted job context attributes. I also think we can do better for
    the case of the back side having a different imageable area than the front

    Background for the sm and ipp DL: We are agreeing to add a
    media-margin-sizes (1setOf integer) Printer Description as a way for the
    driver to find out about the imagable area for IPP, PAPI, and the PWG
    Semantic model. In PAPI, the papiPrinterQuery function accepts job context
    attributes which narrow down the values of the returned attribute values
    supported for any cross-attribute constraints.

    ISSUE 1: How handle imageable areas that are different for the front and
    back side of a medium?

    Should the "media-margin-sizes" (1setOf integer) attribute:

    a. return two sets of 4 integers, if the back side has a different set of
    margins from the front side

    b. always return 8 integers for each different medium when "sides" is or
    could be 'two-sided-long' or 'two-sided-short'.

    c. always return 8 integers.

    d. only return the margins for the front side and don't worry about the back
    side, even if different.

    I suggest yes.

    ISSUE 2: If "xxx" job context is supplied, what is returned for

    Are all the values still returned, or only the supplied value for that

    If the idea is that the supplied attributes to papiPrinterQuery are
    providing constraints, then the supplied value is a constraint in itself and
    so other values are not supported. I think it is more consistent to return
    only what is supplied and return all values for other attributes, except
    values that are constrained.

    So if the caller supplies "sides" = 'one-sided' and also requests
    "sides-supported", then the papiPrinterQuery returns "sides-supported" =
    'one-sided', even if the Printer supports several values.

    ISSUE 3: Does papiPrinterQuery default omitted job context attributes or

    Does papiPrinterQuery:

    a. default omitted job context attributes and so apply any inter-attribute
    constraints that such defaults would imply OR
    b. not default omitted job context attributes, but rather return all values
    that are possible with any values of the unsupplied job context attributes,
    i.e., returned the unconstrained values independent of the Printer's job

    Michael said that "sides" would be defaulted by the papiPrinterQuery, if the
    caller didn't supply the "sides" attribute in the job context. Later,
    Michael said that when the client omits all job context, that the
    papiPrinterQuery will list all possible values. It would seem to me that
    defaulting omitted job context attributes contradicts returning all possible
    supported values when no context is supplied.

    Lets take a simple example, using just "sides" and "media" job attributes.
    Let's assume that a Printer supports "sides" = 'one-sided',
    'two-sided-long', and 'two-sided-short' and "media" = 'na-letter-white', and
    'na-letter-transparent'. Let's also assume that the policy is to consider
    that printing two-sided on transparencies is an error, i.e., would violate a
    cross-attribute constraint.

    So here are the different results for different papiPrinterQuery calls:

    Case supplied job context: papiPrinterQuery results:
    ---- --------------------- -------------------------
    a. <empty> "sides-supported" = 'one-sided',
                                    "media-supported" = 'a-white',

    b. "sides" = 'one-sided' "sides=supported" = 'one-sided'
                                    "media-supported" = 'a-white',

    c. "sides" = 'two-sided-long' "sides-supported" = 'two-sided-long'
                                    "media-supported" = 'a-white'

    d. "media" = 'a-white' "sides-supported" = 'one-sided',
                                    "media-supported" = 'a-white'

    e. "media" = 'a-transparency' "sides-supported" = 'one-sided'
                                    "media-supported" = 'a-transparency'

    f. "sides" = 'two-sided-long' returns constraint violation error
         "media" = 'a-transparency'

    Note: in writing this example, it occurred to me that any supplied job
    attribute should only return the supplied value in the "xxx-supported"
    response, since the caller was constraining that attribute to that choice.

    So I claim that any omitted job context attributes are NOT defaulted.
    Otherwise, there isn't any way to get back all the unconstrained supported
    values and the GUI couldn't put up all the unconstrained choices to the user
    before the user makes any choices.

    For example if the Printer did apply defaults, and the "sides" default was
    'two-sided-long', there wouldn't be any way to get back the 'a-transparency'

    Also, if you buy the idea that a supplied "xxx" attribute only returns that
    value for the "xxx-supported" value, then defaulting only returns the
    supplied values, rendering papiPrinterQuery useless.

    IPP Note:

    RFC 2911 Get-Printer-Attributes does have the idea of defaulting for the
    only job context attribute that the client MAY supply, namely,
    "document-format" (which with hind-sight, I think was unfortunate):

    If the client omits this "document-format" operation attribute, the Printer
    object MUST respond as if the attribute had been supplied with the value of
    the Printer object's "document-format-default" attribute. It is RECOMMENDED
    that the client always supply a value for "document-format", since the
    Printer object's "document-format-default" may be
    'application/octet-stream', in which case the returned attributes and values
    are for the union of the document formats that the Printer can automatically



    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Friday, September 27, 2002 05:42
    To: printing-cap@freestandards.org
    Cc: sm@pwg.org; ipp@pwg.org
    Subject: Re: [printing-cap] Capabilities API: Device Object [How about a
    M edia Object]

    Hastings, Tom N wrote:
    > ...
    > 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

    But the printer object has defaults for all printing attributes,
    which are used when the job object doesn't override them...

    > 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

    Again, "sides" is defaulted.

    However, in the case of many of the current HP inkjets with the
    auto-duplexer option, the top and bottom margins are swapped for
    the back page. In CUPS we have a PPD attribute for this, but in
    general I'd suspect the sane thing to do would be to report the
    same top and bottom margin (the larger of the two for safety, and
    the app/user can still try printing outside of those margins)

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

    If we use constraints, then the query operation without job attrs
    will list all possible values (+ the constraints); the addition of
    job attrs will only narrow the query results.

    Michael Sweet, Easy Software Products                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com

    _______________________________________________ printing-cap mailing list printing-cap@freestandards.org http://freestandards.org/mailman/listinfo/printing-cap

    This archive was generated by hypermail 2b29 : Fri Sep 27 2002 - 16:50:35 EDT