UPD Mail Archive: UPD> Fwd: RE: min and max size and the cre

UPD> Fwd: RE: min and max size and the creeping scope of the media standard [all-in-one names]

From: RonBergman@aol.com
Date: Wed Apr 04 2001 - 11:15:19 EDT

  • Next message: Carl Kugler: "Re: PWG> Fwd: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded"

    attached mail follows:


    Tom,

    Based upon the IPP restriction, the period is acceptable.

    As far as having some parameters optional in the string, my preference
    is no. Every parameter must have a value. This keeps processing the
    string simple and additional parameters can be added without breaking
    any old applications.

        Ron

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Tuesday, April 03, 2001 7:13 PM
    To: Bergman, Ron
    Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade
    (E-mail); Michael Sweet
    Subject: RE: min and max size and the creeping scope of the media
    standard [all-in-one names]

    Ron,

    While slash is kind of clear, the problem is that it can't be used as an IPP
    keyword for the "media" attribute. IPP 'keyword' values can only be all
    lower case letters, digits, ".", "-", and "_". We wouldn't want to have IPP
    encode these all in one names using the 'name' attribute syntax, since IPP
    RECOMMENDs case insensitivity (upper case allowed and equivalent to lower
    case) for the 'name' attribute syntax values. I don't see any problem with
    using the "." to separate fields in the all-in-one names, since the media
    size field must have a "." within it as well. With ".", the names are like:

       stationery.na-letter.8500-11000.white.none

    which really reads pretty well. The fact that the Media Size Self
    Describing Name field is made up of two fields: Media Size Name and
    Dimensions, doesn't both me and still fits our syntax.

    But if there is objection to this dual use of ".", the underscore ("_")
    character is also available in the IPP 'keyword' syntax. Using the
    underscore character the names would look like:

       stationery_na-letter.8500-11000_white_none

    But if we use underscore to separate the fields, what will we use if we want
    to make fields optional, such as the Media Coating, which will usually want
    to be 'none'? There aren't any more IPP 'keyword' characters left.

    I had suggested that we might want to put the name of the field as a prefix
    separated by "_", if the field can be left out. Then we could have:

       stationery.na-letter.8500-11000.white -- meaning no coating

    and:

       stationery.na-letter.8500-11000.white.coating_matte

    when a coating other than none was wanted.

    Or we could just bite the bullet and always carry coating 'none' along in
    the names, since these names are intended for program to program
    communication and have no optional field mechanism. We could leave the idea
    of optional fields to the future (as long as we don't use up "_" now).

    Tom

    -----Original Message-----
    From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
    Sent: Tuesday, April 03, 2001 18:39
    To: 'Hastings, Tom N'; Bergman, Ron
    Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade
    (E-mail); Michael Sweet
    Subject: RE: min and max size and the creeping scope of the media
    standard [new subject]

    Tom,

    The all-in-one could be postponed. I was thinking it should be an
    appendix in the Media Names standard as the recommended method of
    concatenating the defined media names to create a single media
    definition. Even so, it could be first published as an addendum
    and then later integrated into the standard in next years update.

    If we are close to having an agreement, it could be added now.
    I have no problem with your proposal. One thought I had was
    replacing the period as a separator between names with a slash(/).
    This might be easier on a parser, since the period is now the
    separator in the size name. So your example would be:

        stationery/na-letter.8500-11000/white/none

    Or, would a different character be better?

        Ron

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Tuesday, April 03, 2001 5:51 PM
    To: Bergman, Ron
    Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade
    (E-mail); Michael Sweet
    Subject: Re: min and max size and the creeping scope of the media
    standard [new subject]

    Looks good to me for the min and max. I agree that it fits within the scope
    of the standard.

    About the creeping scope of the media standard, I agree that UPnP doesn't
    need the all-in-one, but IPP could really use it. But if everyone keeps
    adding requirements, we'll never get what we seem to have good agreement on
    done. How about stopping the current version with:

      Media Type Names
      Media Color Names
      Media Finish Names
      Media Size Self Describing Names

    and then add the all-in-one as a companion PWG standard which augments this
    standard and which also has any other fields needed as well? Much as I'd
    like to see the all-in-one for IPP for use with the existing "media" Job
    Template attribute, I think that it can wait a few months. Also I suspect
    that it will take more debate and design.

    Tom

    -----Original Message-----
    From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
    Sent: Tuesday, April 03, 2001 17:31
    To: 'Hastings, Tom N'; Michael Sweet; Bergman, Ron
    Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade
    (E-mail)
    Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4
    down- loaded

    Tom,

    I have added the following:

    5.2.5 The size-name "max" shall be reserved to indicate an upper
      size limit of either a device or application. Also, the size-name
      "min" shall be reserved to indicate a lower size limit. Example:
      For a device that can process forms as small as 2 x 3 inches to
      18 x 36 inches:
         na-custom-max.18000-36000 and na-custom-min.2000-3000

    This is part of the custom size section (5.2). My original concern
    was how this was to be presented. This paragraph keeps within my
    guidelines as more applicable to media and not a device.

    I am quite sensitive to the issue of expansion of the scope of this
    project. Keep in mind that this started out as a simple compilation
    of all known media sizes. We have since added color, type, finish,
    and now there is a proposal for an all-in-one format. There also
    have been rejected proposals for media feed direction, printing
    orientation, and others that I have already forgotten.

    Not that what has been added is bad, we just have to be somewhat
    selective as to what is included. On the one hand, I am hearing
    that the UPnP project needs this completed before the meeting
    this month and then I see all the additions everyone wants. When
    sonething is added, it may add a nice feature, but it also pushes
    out the completion date.

        Ron

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Tuesday, April 03, 2001 5:05 PM
    To: Michael Sweet; Bergman, Ron
    Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade
    (E-mail)
    Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4
    down- loaded

    I agree with Michael that we should add the maximum and minimum size name
    pattern for custom media. I don't share Ron's concern that adding the name
    pattern for custom minimum and maximum size will lead to anything further
    being needed in the Media Standard (if it did, then I might change my mind).

    I also believe that we have to add the min and max custom size if we want
    the UPnP WG to reference our standard from the UPnP BasicPrint Template for
    syntax and names for use in their MediaSize variables. Their current
    Template, which we hope to replace for Media Size and Media Type already
    have the custom min and max syntax. Satisfying the UPnP WG BasicPrint
    Template was one of the reasons to get this PWG Media standard done in the
    first place.

    I wrote on 3/28 as the syntax for adding custom max and minimum size names:

    3. Request to represent minimum and maximum size for use with the custom
    mechanism. Interestingly, UPnP Print template has a way to represent the
    minimum and maximum sizes that a Printer supports using the custom syntax.
    Translating the UPnP syntax to our ABNF would become:

       custom-media-size-max-self-describing-name =
             [prefix] "custom-max" "." short-dim "-" long-dim

       custom-media-size-min-self-describing-name =
             [prefix] "custom-min" "." short-dim "-" long-dim

    A Printer that supports a minimum custom size of, say, 3 inches by 5 inches,
    and a maximum of, say, 8.5 inches by 14, would have the following two
    values:

      na-custom-max.8500-1400
      na-custom-min.300-500

    Any disagreements?

    I also believe that this meets Michael's needs for custom sizes, whether for
    the 'roll' Media Type or any of the other Media Type values.

    Tom

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Thursday, March 29, 2001 12:09
    To: Bergman, Ron
    Cc: 'Hastings, Tom N'; ipp (E-mail); UPDF WG (E-mail);
    'RonBergman@aol.com'; Norbert Schade (E-mail)
    Subject: Re: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4
    down-loaded

    "Bergman, Ron" wrote:
    > ...
    > I disagee with your proposal for adding printer size restrictions
    > to the document. So far this specification has only involved
    > attributes related to media. Now you are proposing that we add
    > an attribute that is related to printers. This belongs in the
    > appropriate UPnP or IPP or other document that defines how to
    > describe a printer. If we add this then it will be necessary
    > ...

    I'm not sure I agree with this (or maybe I just not understanding
    your objection right); the purpose of this standard/spec is to
    define the names used for media sizes, types, finishes, etc. so
    that other protocols can then use those names uniformly.

    From an implementation standpoint, it may be desireable to have
    media size names that are reserved for representing 1) whether
    custom media sizes are supported, and 2) what the size limits are
    for the device being queried. This allows all protocols to use
    a common method for conveying the custom media size information,
    while the exact values used in the custom size names are determined
    by the device and not the protocols or this spec.

    IPP contains no explicit support for custom media sizes; CUPS
    works around this limitation by supporting a "custom" media size
    keyword and relies on the to know that they can request a custom
    media size using the name "custom.WWWxLLL", where "WWW" and "LLL"
    are the width and length of the media in points (works well for
    a PS-based printing system... :) This only works for CUPS, and
    I have no idea what Microsoft does, for example, with their
    media support under Windows 2000...

    So, I guess what I'm saying is this:

        1. Describe "custom-min" and "custom-max" media size names
           and the format they use. Specify that these names will
           only be present for devices that support custom sizes, and
           that both must appear if they are used at all.

        2. Explicitly state that the values used in the custom-min/max
           names are defined by the device and not the spec.

        3. Explicitly state that the units for media sizes in the
           size names are set by the media spec and not by the
           protocol spec. Units outside the size name can obviously
           be anything the protocol wants...

    #1 will make sure that any client can determine if a device supports
    custom sizes, no matter what protocol is being used.

    #2 will remove any requirement for additional info in the media spec
    on how to manage custom sizes.

    #3 will ensure that the dimensions in size names are consistent no
    matter what protocol is being used.

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



    This archive was generated by hypermail 2b29 : Wed Apr 04 2001 - 11:15:37 EDT