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

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

RE: IPP> global media; comment on yesterday's proposal

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Apr 27 2001 - 21:15:24 EDT

  • Next message: don@lexmark.com: "Re: IPP> global media; comment on yesterday's proposal"

    Further thoughts on your proposal to have only one set of units for media
    size (1000th of mm).
    I did bring up at the meeting the scenario that you and Mark suggested of a
    job or document saved by one driver with media selected for a Printer that
    happened to use metric units for the media and that a second driver tries to
    print the saved job or document on another printer that happens to use
    English units for the same size media.
    Our conclusion at the meeting was that we didn't think that the names should
    be converted from one units to the other when saving jobs or documents, but
    should remain in the customary units wherever those media names were being
    interchanged between different pieces of software and/or hardware, such as
    protocols, data description files, and saved jobs and documents. Conversion
    should only be done internally within a program or hardware box once it gets
    the standardized media name. So far in our standard we don't have two media
    that are the same size, but use different units. We imagine that that is a
    property of media sizes. Therefore, the problem is caused by driver 1 in
    your scenario converting the media units to the other form before saving the
    job or document. The driver should save the job or document in the
    customary units that it got from the media name which should never be
    converted in the places where they are to be interchanged and interpreted by
    other software or hardware. Conversion should only be done internally
    within a program or box and can be to any units that the internal
    implementation chooses.
    So we shouldn't adopt a single set of units (as you propose) to solve your
    problem of saving jobs and documents and reprinting them on other printers
    that have other media of the same size but with different units. We should
    only agree on a single unit of measure (as you propose), because it
    simplifies interchange between programs and avoids the specter of additional
    systems of units in the future (as you fear).
     -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Friday, April 27, 2001 16:23
    To: Norbert Schade
    Cc: IPP Group
    Subject: RE: IPP> global media; comment on yesterday's proposal

    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
    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?

    -----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
    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
    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.
    Norbert Schade
    Principle Software Engineer
    Host Software Group
    Oak Technology, Inc.
    10 Presidential Way
    Woburn, MA 01801
    Phone: 1-781-638-7614
    Fax: 1-781-638-7555
    email: norbertschade@oaktech.com <mailto:norbertschade@oaktech.com>

    This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 21:16:45 EDT