IPP Mail Archive: RE: IPP> PPE - Issue about adding "me

RE: IPP> PPE - Issue about adding "media-size" by name in additio n to "media-size" by dimensions

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Sep 19 2000 - 13:08:43 EDT

  • Next message: ElliottBradshaw@oaktech.com: "IPP> FW: IPP Bake-Off Location?"

    It wasn't clear to me who the "you" was in your scenario?

    Remember, IPP is the network wire protocol between the client and the
    printer, not what is displayed between the client and the user (in both
    submission and query).

    So a good client will display to a user both the standard media size names
    and the associated dimensions. One client I tried puts the dimensions in
    parentheses and another echoes back the dimensions when the user selects the
    media size name. Both client allow the user to type in custom media
    dimensions as well (and doesn't display any media name with them). For
    either client implementation, only the dimensions are needed in the network
    protocol sent between the client and the Printer (in job submission and
    capability query).

    Having two ways in the protocol to specify media size: by name and by a pair
    of numbers, we run into interoperability problems. Worse, if a Printer
    vendor or an administrator wants to define new media names, clients would
    have to update their localization tables for those new names (or not be able
    to display them in the language of the user). Its much better to have just
    numbers.

    Having just dimension numbers (x and y) in the protocol in no way limits the
    client as to what user friendly display it wants to present to users that
    uses both names and dimension numbers.

    If we remove specifying media size by name in the protocol and go back to
    having only media-size by dimensions: when a user types in his own
    dimensions for a custom size, the client will send those values in the
    protocol. If those values happen to agree with a standard media sizes, then
    the Printer won't be able to tell the difference, but so what? If the user
    specifies additional attributes to the client, then those additional values
    will be passed to the Printer in the "media-coll" collection. If the user
    hasn't specified any additional media characteristics, then the Printer will
    use the standard medium.

    So does it make more sense as to why I want to remove the media by size name
    member attribute that we added last week at the meeting and keep only media
    by dimensions for the media-coll Job Template attribute?

    To make it clearer from the member attribute names, should we call the
    member attribute "media-dimensions", instead of "media-size", that has only
    the pair of numbers as a value?

    Tom

    -----Original Message-----
    From: Roelof Hamberg [mailto:rham@oce.nl]
    Sent: Monday, September 18, 2000 23:48
    To: Hastings, Tom N
    Cc: ipp (E-mail)
    Subject: Re: IPP> PPE - Issue about adding "media-size" by name in
    addition to "media-size" by dimensions

    "Hastings, Tom N" wrote:
    >
    >
    > OK to go back to the original specification with just
    > "media-size" (collection) in which only the dimensions in
    > hundredths of a millimeter (equivalent to 1/2540 th of an inch
    > resolution)?

    Tom,

    I agree with you that having the single pair of numbers is sufficient to
    specify size. The only thing is, if you replace a custom size (specified
    by the user) in the client by a named size, the user might not recognize
    his own settings. With numbers only, there is no way to avoid this.

    So, I'm not in favour of rewinding the decision.

    Roelof Hamberg
    _______________________________________________________________________

    Océ-Technologies B.V. P.O. Box 101 phoneto:+31 77 359 5869
    Research & Development / DVS 5900 MA Venlo faxto:+31 77 359 5337
    internal location 3N-40 The Netherlands mailto:rham@oce.nl
    _______________________________________________________________________



    This archive was generated by hypermail 2b29 : Tue Sep 19 2000 - 13:18:15 EDT