IPP Mail Archive: RE: IPP> global media; comment on yesterda

RE: IPP> global media; comment on yesterday's proposal [put units field last]

From: Wagner,William (wwagner@netsilicon.com)
Date: Tue May 01 2001 - 19:46:01 EDT

  • Next message: pmoore@netreon.com: "RE: IPP> global media; comment on yesterday's proposal [put units field last]"

    Tom,

    I think you (and others) are suggesting an expansion to what was identified
    as the objective. If I recall correctly, the size was called
    self-describing, not the name. A major part of the time in Portland was
    spent arriving at the conclusion that the name was not intended to be
    presented to the user.

    I really am ambivalent on which scheme is used. But it is going to be hard
    to get consensus if the purpose is unstable. And suggesting that the name is
    intended for human consumption may bring up a whole set of other issues as
    to where the schemes fall short.

    Come to think of it, this is one reason why I prefer representing machine
    readable information as integers!

    William A. Wagner (Bill Wagner)
    Director of Technology
    Imaging Division
    NETsilicon, Inc.
    781-398-4588

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Tuesday, May 01, 2001 1:49 PM
    To: Bergman, Ron; 'Wagner,William'; 'Harry Lewis'; Don Wright (E-mail)
    Cc: IPP Group; Norbert Schade; Mark VanderWiele; 'RonBergman@aol.com'
    Subject: RE: IPP> global media; comment on yesterday's proposal [put
    units field last]

    Ron,

    A slight variation on your proposal to make the units an explicit field in
    order to make the names completely self describing, would be to move it from
    being the first field to being last field. Then it could be displayed by
    very simply by (dumb) clients that didn't localize the names and/or
    recognize a new name without any processing (or by simply replacing any
    underscores with a space):

    Examples: na-letter_8.5-11_in
               iso-a4_210-297_mm

    Bill sees the explicit units as redundant, which they certainly are and we
    don't want people to think that the following names are synonyms,
    respectively:

               na-letter_215.9-279.4_mm
     
    iso-a4_8.2677165354330708661417322834646-11.692913385826771653543307086614_i
    n

    On the other hand, this approach of explicitly passing the units in a
    separate field does allow us to add other units in the future without
    risking any confusion with existing implementations that only know about the
    in and mm field values.

    Tom

    -----Original Message-----
    From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
    Sent: Monday, April 30, 2001 17:25
    To: 'Wagner,William'; Bergman, Ron; 'Harry Lewis'; Hastings, Tom N; Don
    Wright (E-mail)
    Cc: IPP Group; Norbert Schade; Mark VanderWiele; 'RonBergman@aol.com'
    Subject: RE: IPP> global media; comment on yesterday's proposal

    Bill,

    Thank you for the explanation. I am sure this was extensively
    discussed at the meeting and I wish I could have attended.

    I have no problem with the concept of "class". It certainly is cleaner
    than my original proposal of "na indicates the dimensions are in inches
    and all others are metric." And I also agree that the concept of class
    allows possible future expansion.

    As long as we are adding the "class" part it should be very well
    defined as to the meaning of the classes. Since we really only have
    2 classes currently defined, I would suggest that they be called:

            'inch' or 'in' for the class that specifies inch dimensions.
          'millimeters' or 'mm' for the class that specifies mm dimensions.

    Examples: in_na-letter_8.5-11
               mm_iso-a4_210-297

    Although this results in a longer total name, I feel it is cleaner
    and does not require a parser in a simple printer to decode a large
    number of names for metric sizes. And I don't see how this breaks
    the ability to add additional sizes in the future. In fact, this
    allows a device to quickly recognize that it does not understand the
    class if another class is defined. And it may prevent problems, since
    under the Portland agreement the device may look for 'na' as inches
    and anything else as millimeters.

            Ron

    -----Original Message-----
    From: Wagner,William [mailto:wwagner@netsilicon.com]
    Sent: Monday, April 30, 2001 4:15 PM
    To: 'Bergman, Ron'; 'Harry Lewis'; Hastings, Tom N; Don Wright (E-mail)
    Cc: IPP Group; Norbert Schade; Mark VanderWiele; 'RonBergman@aol.com'
    Subject: RE: IPP> global media; comment on yesterday's proposal

    Ron,

    I think the point is that the "Class" is already required in most of the
    instances as part of the common name (NA, iso, jis, etc.) The units are
    implicit in the class, but are not the only reason for the class. This is
    what was done before. The only change was to make this relation more clear,
    consistent and expandable by representing class as a separate field and by
    defining classes for those few sizes that did not already have one
    associated. The reason that there are many classes identified are that
    there are many classes in common use. And yes, one of the objections made to
    the original proposal was that it did not allow for other units; allowing
    that is a by-product of the proposed approach; it is not the primary intent.

    Bill Wagner

    -----Original Message-----
    From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
    Sent: Monday, April 30, 2001 4:45 PM
    To: 'Harry Lewis'; Hastings, Tom N; Don Wright (E-mail)
    Cc: IPP Group; Norbert Schade; Mark VanderWiele; 'RonBergman@aol.com'
    Subject: RE: IPP> global media; comment on yesterday's proposal

    Harry,

    I thought that Norbert's proposal was cleaner than the complicated
    "class" proposal made in Portland. I have been trying to understand
    the purpose of "class", other than to define the size. Unless, there
    is another purpose, why do we need so many ways to indicate mm?
    The need for iso, jis, jpn, prc, asme, and etc etc seems to make a
    simple task vary complex.

    I still prefer the definition of all sizes in their native dimensions,
    rather than a conversion to a common base. But unless we can simplify
    the "class" to just inches and mm, I would favor Norbert's method.

    I like all the other suggestions from Portland, but this one does not
    appear correct.

        Ron

    -----Original Message-----
    From: Harry Lewis [mailto:harryl@us.ibm.com]
    Sent: Sunday, April 29, 2001 9:24 PM
    To: Hastings, Tom N
    Cc: IPP Group; Norbert Schade; Mark VanderWiele
    Subject: RE: IPP> global media; comment on yesterday's proposal

    This "shows to go ya" that we still don't (collectively) agree on the
    purpose of the "self describing name". Seems the folks who write drivers
    feel more natural operating in one set of units. (Norbets comments are
    similar to those I received from our driver folks).

    BUT....

    in Portland (at least) we spent quite some time hammering out the intent
    of this beast... which I would describe as...

    STANDARD media size "names" with distinct elements ("class", "size name"
    and "dimensions") in a (machine and developer-human) parsable syntax.

    The "class" is supposed to indicate the units (typically inches or mm...
    but hypothetically angstrom's or whatever if appropriate... which is
    unlikely).

    It would seem counter intuitive for "na_letter" to be represented in mm as
    it is well known in the industry as "English".

    Conversions are the realm of the application. If a driver wants to
    (convert the English) and store everything in mm... that's OK... but the
    STANDARD name should not change.
    ----------------------------------------------
    Harry Lewis
    IBM Printing Systems
    ----------------------------------------------

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

     
            To: Norbert Schade <norbertschade@oaktech.com>
            cc: IPP Group <ipp@pwg.org>
            Subject: RE: IPP> global media; comment on yesterday's
    proposal

     

    Norbert,
     
    So your proposal is to always use one set of units, namely 1000ths of a mm
    (i.e., a micrometer); never use inches for any media sizes. It certainly
    is simple.
     
    1000th of a mm is precise enough so that the English sizes can be
    represented in 1000ths of a mm without round off error (which would create
    differences in names, if some rounded and others truncated).
     
    We used the same strategy of using only a single unit system in the IPP
    Production Printing Attributes - Set1 extension, instead of having both
    metric and English. The only minor difference was that we used 100th of a
    mm, instead of 1000th of a mm for use in the "media-size" member attribute
    of the "media-col" attribute. We felt that was precise enough. See
    section 3.13.8 in:
    ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf, .doc, .rtf
     
    The 1000th of a mm is one of the two units used in the Printer MIB (the
    other being 10000th of an inch).
     
    We did agree at the meeting that the client shouldn't simply display the
    Media Size name to the user if it doesn't have it in its localization data
    base (thought there will always be simple minded clients that will). The
    client should do some parsing and possible converting of units to the one
    that the user prefers. So there is no real advantage to the client to
    have the units be in inches for English sizes and metric for metric sizes
    (except for the really simple clients that never convert units).
     
    What do others think of just always using micrometers for the size
    dimensions for our Media Size Self Describing Names?
     
    Tom
    -----Original Message-----
    From: Norbert Schade [mailto:norbertschade@oaktech.com]
    Sent: Thursday, April 26, 2001 13:50
    To: IPP Group
    Subject: IPP> global media; comment on yesterday's proposal

    I have my problems with the new proposal.
    I am going to rephrase my previous statements commenting that proposal.
     
    Splitting the media size name into three components (unit, name,
    dimensions) is a very new idea.
    My main problem with this proposal is the first component.
    In Ron's current version of the spec we have two units: inch/1000 and
    mm/10. We have implemented that version to learn about problems.
    With the new proposal there is the danger to have an even bigger number of
    units.
    Supporting more than one unit is a serious problem for any driver. Ask any
    driver developer. It's not about what unit I want to show in the UI. It's
    about necessary conversions when dealing with applications. Please study
    Mark's feedback from 4/20. I repeat it in easy words (I hope).
     
    Scenario excerpt
    1. Workstation 1 with driver 1
    Driver 1 is supporting a media size 'Letter.2159-2794' (the developer of
    the driver has chosen the metric way). You could do the sample with any
    other size.
    2. User 1 sitting at workstation 1 writes one page of text with
    application xyz and saves the document.
    this means that the size information 'Letter.2159-2794' is saved in the
    document file as well in many, many applications.
    3. User 1 sends his document to user 2.
    4. User 2 sitting at workstation 2 with driver 2 (different from driver 1)
    opens the document. This second the driver 2 is already involved.
    5. Imagine driver 2 is not supporting 'Letter.2159-2794', but
    'na-Letter.8500-1100' instead, which in fact is the same size with a
    different name.
    Now it's the question what is driver 2 doing.
    It could start some investigation to match or emulate the required size.
    -> bad performance.
    The same situation will happen again when printing. It will happen very
    often, repeatedly.
     
    So we already have a problem with two units. If we now open a gate to be
    able to define even more units, it will be aweful code and a terrible
    performance. Every driver developer should be able to prove that.
    However everything would be fine, if there'd be one and one only unit.
    Make it small enough that any rounding for a UI string or whatever is
    needed, can be done properly. Our proposal within UPDF was mm/1000, which
    is certainly small enough (and used in the industry anyhow).
     
    I treated strings like 'jis' or 'iso' just as parts of the name to make it
    more apparent. 'na' was the only exception so far.
     
    If all names are unique (I think they are in Ron's current concept), I
    don't have a problem splitting the name and the dimensions into two
    components. In that case we may even work with the name only and handle
    the dimensions with an include file.
    I thought the idea of combining the name and the dimensions is ok, as we
    need it for custom size anyhow.
    BTW: I am happy to have proper keywords, but my drivers certainly will
    never, never, never show them in the UI. Be also sure that in UPDF we are
    providing the chance to assign a proper human readable UI string to it.
     
    So from a driver's point of view the easiest case is to work with 1 unit
    (mm/1000), remove the prefix 'na-' and convert all the dimensions.
    This ensures a good performance, consistent routines and readability.
    Whatever the internal unit of a driver is, it most probably has all
    converting routines available to work with 1 unit, but not all necessary
    functions to match between different units.
     
    I would be very surprised if Mark does not feel very, very similarly,
    although I have been told differently today. Unfortunately I couldn't get
    hold of him on his trip today.
     
    I call this proposal '1unit mm/1000, unchanged naming', where unchanged
    naming means no separate components, but converted dimensions into that 1
    unit. I do not insist on unchanged naming, but I haven't seen the big
    advantage of it so far.
     
    Regards
    Norbert Schade
    Principle Software Engineer
    Host Software Group
    Oak Technology, Inc.
    10 Presidential Way
    Woburn, MA 01801
    USA
    Phone: 1-781-638-7614
    Fax: 1-781-638-7555
    email: norbertschade@oaktech.com



    This archive was generated by hypermail 2b29 : Tue May 01 2001 - 19:49:29 EDT