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

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

From: don@lexmark.com
Date: Sat Apr 28 2001 - 01:24:15 EDT

  • Next message: don@lexmark.com: "Re: IPP> MED - Definition of 'stationery-coated' Media Type for use by ink jet and bubble jet printers"

    This WHOLE argument goes away because Letter.2159-2794 is NOT one of the
    standardized names. Nor is om_letter_2159-2794 nor any other variation. A
    driver can do whatever it wants INTERNALLY but the actual paper size is and will
    always be forever more na_letter_8.5-11. Any time a reference is made to this
    paper size and stored away for exchange with another system it MUST be referred
    to my the standardized name .... na_letter_8.5-11

    **********************************************
    * Don Wright don@lexmark.com *
    * Chair, Printer Working Group *
    * Chair, IEEE MSC *
    * *
    * Director, Strategic & Technical Alliances *
    * Lexmark International *
    * 740 New Circle Rd *
    * Lexington, Ky 40550 *
    * 859-232-4808 (phone) 859-232-6740 (fax) *
    **********************************************

    "Norbert Schade" <norbertschade%oaktech.com@interlock.lexmark.com> on 04/26/2001
    04:49:42 PM

    To: "IPP Group" <ipp%pwg.org@interlock.lexmark.com>
    cc: (bcc: Don Wright/Lex/Lexmark)
    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 : Sat Apr 28 2001 - 01:45:57 EDT