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 [put units field last]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed May 02 2001 - 12:26:14 EDT

  • Next message: Mark VanderWiele: "RE: IPP> global media; comment on yesterday's proposal [put units field last]"

    Paul,

    The reasons to include the dimensions in the Media Name (for UPnP MediaSize
    parameter, IPP/1.1 "media" Job Template attribute, ...):

    For Printer to client communication:

    a. If the client software receives a size name that it doesn't recognize, it
    can still deal with it, because the units are there.

    b. If the client software receives a size name that it doesn't recognize, it
    can still display something meaningful to the user (and the user can see
    what the size is).

    c. For UPnP (which REQUIRES support for XHTML-Print+xml) and any Printer
    that supports XHTML-Print+xml, there doesn't have to be a driver that cares
    about the size in the client. With XHTML-Print+xml, only the human user and
    the Printer have to deal with the size, not the client software. The client
    software just passes the token to the Printer that the user selected from
    the Printer's supported list (which the client got either by querying the
    Printer or from the UPDF/GPD/PPD file for that printer).

    d. The Printer can use the same syntax to indicate that it supports a range
    of custom sizes, that the client can make up.

    For Client to Printer communication:

    a. If the Printer receives a size that it doesn't recognize, it can find out
    what the dimensions are from the string it gets from the client. This can
    be useful for the Printer that wants to support custom sizes from the client
    or that doesn't want to bother the user with configuring the Printer with
    supported sizes.

    Tom

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

    I know I havent contributed much lately and apologize if I am rehashing
    arguments that have already been covered.

    Why does the name have to include the size - my name doesnt include my
    telephone
    number, if somebody needs my phone number they look it up using my name as a
    'key'. Surely the correct solution is to allow a device to assign any name
    it
    likes to media (probably choosing well known ones for its market, B3,
    Letter,
    ....). If the client app /driver needs to know the physical size then all
    that
    is needed is an operation to query the paper size, the response must include
    the
    units. Likewise the app more than likely needs to know the markable area -
    it
    should be provided with a mechanism for asking for that information.
    Similarly
    if you need to know the color, thickness, manufacturer, weight,
    permiability,
    date of purchase, etc. there should be queriable attributes to read these
    things; lest we end up with don's

    na_toilet_paper.continous.landscape.ruffled.4_4in.offpink.clockwise

    Which tells you everything except the markable area and the manufacturer

    If a device has more that one A4 available (say), then it can invent names
    for
    them (or even be operator assigned). To support this case there should also
    be a
    'standard name' attribute that can be queried - this would return A4, legal,
    ASMEY14,...



    This archive was generated by hypermail 2b29 : Wed May 02 2001 - 12:27:55 EDT