UPD Mail Archive: RE: UPD> Re: IPP> min/max custom size v

RE: UPD> Re: IPP> min/max custom size values

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Apr 03 2001 - 17:23:25 EDT

  • Next message: Hastings, Tom N: "UPD> RE: IPP> RE: Media Names, case sensitivity"

    Harry and Mark,

    To build on your idea (you turned me around), we could take the current IPP
    "media" attribute and define how to concatenate the keyword values in the
    Media Standard to make new IPP keywords, to make a "joined syntax".

    If we did that and put the concatenation rules into the Media standard
    itself, then we would be defining Media Names (something that the current
    draft says we aren't doing - see the Media Name definition in Section 2
    Terminology, but we can just change that statement).

    We can just put the rules for combining the keyword values together. We
    don't need to add any more tables.

    All we need to do is pick the order and the separator character.

    For order, how about in order of decreasing significance:

    Media Type Name
    Media Size Name
    Media Color Name
    Media Coating Name (we've agreed to add this fourth set of names)

    For a separator character, I suggest that we use the ".", which we are
    already using as a separator character in the MediaSize.

    Examples of Media Names:


    For the first three fields, they MUST all be present. But what about Media
    Coating. The values are: 'none', 'glossy', 'high-gloss', 'semi-gloss',
    'satin', 'matte'

    If this were the last field ever, then we could say if it is missing, then
    it means 'none'. But I suspect that we want to be able to keep adding
    fields in the future (or that implementers might want to be able to add
    fields). Do we need to introduce keywords for those fields that can be
    omitted, such as Media Coating?

    The equal sign (=) would be more natural to set off keywords from values.
    However, to be compatible with IPP, the only unassigned character in IPP
    keywords is "underscore" (_). So think of the "coating_" as a prefix on the

    So the above 5 examples would be:


    Only the third one has the keyword coating, since it is the only one that
    has a coating that isn't 'none'. We probably have to define a canonical
    order for keywords presence or absence, in order to eliminate different
    orderings being equivalent, correct?



    -----Original Message-----
    From: Harry Lewis [mailto:harryl@us.ibm.com]
    Sent: Tuesday, April 03, 2001 13:37
    To: Hastings, Tom N
    Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Mark VanderWiele; Norbert
    Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group
    Subject: RE: UPD> Re: IPP> min/max custom size values

    I think one of the things that might be encouraging Mark to recommend a
    "joined syntax" is the rate at which we keep inventing and/or applying new
    access protocols to this information (SNMP, IPP, uPnP etc.). If we were to
    define a joined syntax that concatenates the necessary information to
    "use" the media in the device (including Media Size, Media Type, Media
    Source, Media Name) there would be a greater chance of adoption across
    protocols (new and revised).
    Harry Lewis
    IBM Printing Systems

    "Hastings, Tom N" <hastings@cp10.es.xerox.com>
    Sent by: owner-ipp@pwg.org
    04/03/2001 01:30 PM

            To: Mark VanderWiele <markv@us.ibm.com>, Norbert Schade
            cc: UPD group <upd@pwg.org>, IPP Group <ipp@pwg.org>, Pete
    <pzaan@us.ibm.com>, Mark_Hamzy/Austin/IBM%IBMUS <hamzy@us.ibm.com>
            Subject: RE: UPD> Re: IPP> min/max custom size values



    I agree that real applications need to know about combinations of media
    attributes. However, each print protocol has different ways to deal with
    that. So I think it is wiser for the Media standard to just list the
    of the various characteristics and leave it to the various Print protocols
    do deal with combinations.


    For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing
    Extension, which does combine the media attributes into a collection, so
    that combinations can be configured by the administrator. However, even
    that spec does not have a way for the client to query the supported
    combinations. Last summer and fall, the IPP WG considered a proposal for
    Resource object that had a number of operations to create, delete, and
    Resource objects of a defined type. Media was a suggested type. Then the
    group agreed that IPP should really have distinct set of operations for
    object type, so that we need to write a spec for the Media object that has
    operations, like Create-Media, Delete-Media, Get-Media-Attributes,
    (with a filter).

    Are you interested in seeing such a spec and reviewing and/or contributing
    to it?

    An another example or a print protocol that deals with the combinations
    problem, the UPnP EnhancedLayoutPrint template defines a GetMargins
    operation in which the input parameters are MediaType and MediaSize and
    output parameter is the four margins. If the client supplies a
    of MediaType and MediaSize that is not supported, the Printer MUST return
    error code.


    -----Original Message-----
    From: Mark VanderWiele [mailto:markv@us.ibm.com]
    Sent: Friday, March 30, 2001 07:44
    To: Norbert Schade
    Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS
    Subject: Re: UPD> Re: IPP> min/max custom size values

    Careful, we may be making the same mistake we made in IPP where the form
    size, media type, and tray are returned separately causing user interface
    nightmare since all three of these really must be selected together and
    represent the actual configuration of the printer. Therefore, I would
    propose that when we have settled in on a syntax for the form size, media
    type, and tray we go one step further and define a way to join the fields
    so that the proper constraints can be represented. Perhaps a simple "+"
    character. Again, form size by itself is meaningless.

    Mark VanderWiele
    IBM, Linux Tecnology Center
    512-838-4779, t/l 678-4779
    email: markv@us.ibm.com

    This archive was generated by hypermail 2b29 : Tue Apr 03 2001 - 17:24:04 EDT