UPD Mail Archive: UPD> registered parameters

UPD> registered parameters

From: Norbert Schade (norbertschade@oaktech.com)
Date: Wed Nov 22 2000 - 11:33:05 EST

  • Next message: Jim Lo: "Re: UPD> completeness: commands generation (xpdo)"

    We have waited for comments on registered parameters until last Friday.
    The common tenor was to go with technical classifications based on numbers
    and attributes and not try map that to a global list.

    The decision is to go with that approach. I hope we'll be able to solve all
    problems coming up by that.

    I like to keep the format as clear as possible and not overloaded with nice,
    but redundant information. I want driver developers to expect a clear and
    transparent format to work with. So we will not save IPP or other keywords
    for paper sizes after this decision.

    We do not want to stop with the pure specification of the UPDF format. We
    already agreed that we will provide documentation on how to use the
    different fields and values best.
    Additionally the group is tending to give more help to driver developers.
    For now I do not promise sample source code.
    But things like Jim Lo's list of paper sizes is exactly what I mean by
    additional help. Putting together such overviews will be the exact help a
    driver developer is looking for. We may add this list to our documentation
    on our web site. Perhaps we'll create a special directory like "Driver
    developement recommendations".
    I will contact Jim today to find out, whether he is willing to accompany the
    format as a kind of print media expert. Maintaining that list would be one
    of the tasks.
    I'd like to see the list being unique. An Executive paper size should have
    exactly one value in our list. If a device has a different implementation
    with other values it will not be detected as the standard Executive paper
    size, although it could be considered a predefined custom paper size with
    the same name by drivers.
    If in doubt I like clear and unique information more than ambivalent
    documentation, which will not provide the quick orientation people are
    looking for. I do not like but I'm willing to buy some disadvantages for

    To stay with this sample we will reflect all necessary attributes in the
    UPDF format.
    I would like to add some recommendations how to round paper sizes to
    standard sizes in drivers (define an error range). BTW: This would be a nice
    area for some sample code, which likely exists already at a number of
    places. Just keep a number of #define outside the code like
    StandardSizeErrorRange and UnitRelatedErrorRange (perhaps even per typical
    unit like inch, mm, etc). Input parameters may be just a pointer to a value
    (relative to mm/1000, which will be the UPDF unit) and perhaps a unit const
    (relative to mm/1000; a sample value for mm would be 1000). The return value
    would be a driver and therefore OS specific standard size or NULL. A driver
    would refer to his list of standard sizes (structure with OS_ID, width and
    height in mm/1000). The value may be reset, if discovered as a standard
    size, as the OS standard size is assuming a slightly different value, or
    recalculated because of unit related rounding. If anybody will contribute
    such a small piece of code, we would add it to the recommendations.

    Norbert Schade

    Oak Technology, Inc.
    Imaging Group
    10 Presidential Way
    Woburn, MA 01801-1041
    phone: 1-781-638-7614
    fax: 1-781-638-7555
    email: norbertschade@oaktech.com

    This archive was generated by hypermail 2b29 : Wed Nov 22 2000 - 11:36:46 EST