IPP Mail Archive: RE: IPP> Sketch of an idea: Define a Resou

IPP Mail Archive: RE: IPP> Sketch of an idea: Define a Resou

RE: IPP> Sketch of an idea: Define a Resource container object fo r Print Driver Extension and other sub-types

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed May 10 2000 - 22:30:34 EDT

  • Next message: Hastings, Tom N: "IPP> ADM - Draft Agenda and .zip for IEEE-ISTO IPP WG Meeting, 5/17-18 , New York City"

    Eric,
     
    I like the list of uses of the Resource object in your second paragraph:
    ICC Profiles, etc. Your list shows exactly why such a Resource object would
    be useful.
     
    As to the answer to your question about images and how they are positioned,
    the PDL takes care of that. The PDL has some mechanism to reference files.
    Postscript "include" I believe it is called. There is also an "Open
    Prepress Interchange (OPI) specification for PostScript comments that make
    references to high resolution images.

    Search the Adobe partners web site for OPI to locate these specifications
    (i.e. at http://partners.adobe.com <http://partners.adobe.com> )

    So images are just another example of a resource that could be down loaded
    into a printer so that various documents could make reference to them.

    Yes, we should look at what the PPML folks are doing for PODi as well. But
    this IPP Resource object and operations proposal is just to provide means to
    load, query, and get such images, not extending PDLs to make reference to
    them. So if PPML (like PostScript) has ways to make external references to
    other PPML files or other objects, then PPML would benefit from having the
    resource object and its operations defined as well.
     

    Tom

    -----Original Message-----
    From: Eric Random [mailto:ERandom@peerless.com]
    Sent: Wednesday, May 10, 2000 18:13
    To: hastings@cp10.es.xerox.com
    Cc: ipp@pwg.org
    Subject: Re: IPP> Sketch of an idea: Define a Resource container object for
    Print Driver Extension and other sub-types

    Tom -
     
    While the Resource object seems like a potentially useful discussion topic,
    I'm not sure that I see the relationship between several of the proposed
    sub-types and IPP. For example, how would a client use IPP to position an
    image stored in a library on the device correctly in a printed document?
    Aren't the PPML folks over at PODI working on a document schema based on XML
    to solve the general class of variable data printing problems? I know I
    would benefit from a more complete discussion of where you are headed with
    this, since at first glance it seems contrary to the principle of separating
    job submission, management, and monitoring protocol (IPP) from document
    content.
     
    I guess my real question is "Are you trying to define a general purpose
    printer resource selection mechanism by extending IPP syntax?" If you are,
    I'd suggest that you also consider additional resources typically associated
    with color printers, such as ICC profiles, Color Rendering Dictionaries, and
    other by-products of print engine characterization, including (but not
    limited to) halftone screens (possibly implemented as threshold arrays) and
    grey balance transforms (possibly implemented as 1-D lookup tables). Such
    resources can be downloaded into a printer, selected from a pre-existing
    store in the printer, or even uploaded from the printer for use by a host
    based RIP (there is existing standard PDL syntax to accomplish the first two
    operations, but I don't know of any standard method for accomplishing the
    latter).
     
    Eric Random
    Core Technology
    Peerless Systems
    (310) 297-3251
    (310) 727-5715 - Fax
    erandom@peerless.com <mailto:erandom@peerless.com>

    >>> "Hastings, Tom N" <hastings@cp10.es.xerox.com> 05/09/00 11:16AM >>>
    We have discussed several times on the IPP telecons about adding a new
    Resource object. This mail note is a sketch of the idea to see if there is
    support for developing an IPP spec along these lines. The reason to being
    this idea up now is because of the discussion of the Print Driver Extension.
    The Resource object approach would allow a way to install print drivers on
    the Printer and to Get Print Drivers from the Printer to install on a
    client. It would allow a Printer to have more than one print driver, say
    one for each of a number of different OS platforms and/or PDLs.

    Should the Resource object be an agenda topic for the New York City IPP WG
    Meeting, 5/17-18?

    Here is the sketch of the Resource object idea and its operations:

    The Resource object is a generic container object for a number of sub-typed
    objects. The Resource object would have a number of operations defined.
    Each operation would include an operation attribute that identifies the
    object sub-type in question. Then implementers could define new sub-types
    easily without having to invent new operations.

    There are some attributes common to all sub-types, such as the
    "resource-name", "resource-sub-type", "resource-owner",
    "resource-creation-date-time", etc., and a lot that are specific to a
    particular sub-type. Some sub-types will also have opaque data associated
    with each object instance (such as fonts, forms, images, and print drivers),
    and others will only have attributes (such as media).

    The initial list of sub-types include:

    media - Just attributes which define the media characteristics. So the
    client can query the media library and the administrator can add new media
    and define their characteristics
    fonts - attributes and the PDL data
    forms - attributes and the PDL data
    logos - attributes and the PDL data
    images - attributes and the PDL data. high resolution images can be put
    into a shared image library and called out from a number of documents
    print drivers - attributes and the opaque data is the executable code

    The operations would include:

    Create-Resource - the client specifies the resource type and a user-friendly
    name for it that is used in all subsequent operations, including Job
    Submission operations (Print-Job, Create-Job, Send-Document). A lease time
    is also requested (just like our Subscription objects) and the Printer
    returns the lease time granted (which may be infinite meaning no need to
    renew or finite, meaning that the client must renew the lease, else the
    resource will be deleted).

    Delete-Resource - delete the named resource of the indicated sub-type

    Renew-Resource - renews the lease, in case it wasn't infinite

    Get-Resource-Attributes - returns the requested (or all) attributes of a
    specified resource type and instance.

    Get-Resources - returns the requested (or all) attributes of a specified
    resource type that matches the supplied filter criteria consisting of any of
    the resource attributes. Here the filtering is more complex than we have
    for Get-Jobs or Get-Subscriptions operations, since the client could filter
    on any of the resource attribute values. For example, a client could
    request all of the media that has a "media-size" equal to particular pair of
    x and y dimensions and get back the other resource attributes of any matched
    media instances.

    Get-Resource-Data - returns the opaque data for those resources for which
    the data is not copyrighted, etc.

    These operations are very similar to the Subscription object operations that
    the IPP WG has nearly approved for notification. The only differences are:
    Subscription Ids are assigned by the Printer as numbers, while resource
    object instances have user friendly names assigned by the creator. Both
    have leases, but Subscription leases are expected to be much shorter
    (minutes, hours) and handled by the software, not the user, while Resource
    objects leases are much longer (days, weeks, months), though both can be
    infinite depending on SA policy, and the user or administrator explicitly
    creates the Resources. Also Resources are known to users and administrators
    and are managed by them. Also Subscriptions don't have any complex filtering
    in the query requests.

    [We don't want to merge Subscriptions into Resources, just illustrate their
    similarities]

    It will also allow the administrator to set up policy on who can create
    which kinds of resources and for how long.

    Comments?

    Thanks,
    Tom



    This archive was generated by hypermail 2b29 : Wed May 10 2000 - 22:37:49 EDT