IFX Mail Archive: IFX> FW: IPP> preliminary UPDF agenda f

IFX Mail Archive: IFX> FW: IPP> preliminary UPDF agenda f

IFX> FW: IPP> preliminary UPDF agenda for Boston

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Mon Oct 09 2000 - 02:58:38 EDT

  • Next message: BestFriend@twcny.rr.com: "IFX> WHAT CAN YOU GET FOR $20???"

    Its the IPP FAX group that is meeting the day before the UPDF meeting in
    Boston, not the IPP WG group. While most of the members of the IPP FAX
    group are also members of the IPP WG, not all are, so it is important to
    send the agenda to the IPP FAX DL. In particular some of the Internet FAX
    folks have joined the IPP FAX DL, but are not members of the IPP FAX WG.
    The Internet FAX folks have been working on constraints for a number of
    years, called CONNEG (for content negotiation) and now some of them (Graham
    Klyne) are taking up the subject in the W3C.

    Tom

    -----Original Message-----
    From: Norbert Schade [mailto:norbertschade@oaktech.com]
    Sent: Thursday, September 28, 2000 08:56
    To: UPD group; IPP Group
    Subject: IPP> preliminary UPDF agenda for Boston

    Preliminary agenda for the UPDF meeting in Boston on Friday, Sep 27th 2000.

    After having finished the printer resident fonts (mainly in San Francisco)
    and even constraints (mainly in Chicago) it is time to come back to the
    bigger picture again with a hopefully larger group to discuss satisfaction
    with the current level of the spec, open requirements and scenarios of
    implementation.

    1. So I will most likely start with a wrap-up of the current overall level
    of the spec.

    2. The main item of the day will be paper handling with the current spec on
    constraints in mind.
    I will send this spec out within the next one or two days and I would very
    much appreciate that all attendees have a clear understanding of it at the
    meeting, as the constraints are one of the strong columns this concept is
    based on.
    It is only quite a small section. So the study will not be very time
    consuming. I will prepare more samples to easy understanding. I expect you
    to ask me questions concerning the constraints spec via email, if there are
    any.
    We will review the paper handling section the next weeks to prepare the
    meeting. I will share the status with the whole UPDF group.

    3. Event handlers
    If there is time to prepare it more in detail and time in the meeting, Event
    handlers will be another item.
    Event handlers are considered another strong column of the concept. They are
    designed to describe the assembly of a print file.
    There will be a number of global events like JobStart, JobEnd, PageStart,
    PageEnd plus some specific events, where it might be important to define the
    exact order of commands to be sent (I could imagine that font download is a
    sample for such a section).
    The UPDF developer is supposed to be able to create something like an
    ordered list. Each element of the list can be selected out of all fields of
    any feature, which have to do with printer commands.
    Each Event handler will have a section for PreConditions, Actions and
    PostConditions.
    The idea is to be able to tell that certain settings are to be ensured
    before the event, then do the defined actions (work on the ordered list) and
    eventually knowing what settings have been changed by sending all these
    commands, if this is important.

    I would appreciate some feedback before the conference to get a feeling, how
    important you consider a flexible code-independent description of the print
    file structure.
    If this is considered a minor target, we can drop it. But expect me to fight
    for it.

    4. Predefined variable names
    The Parameter Converter is already specified on the current level as the
    first of the three strong columns (a forth one may be added). To specify
    printer command sequences you need some predefined variable names, which you
    will use in your formulas. The driver will set them to certain values and it
    will basically be the input parameters of the function.
    Example: You need a parameter COPIES to specify any useful formula for copy
    handling.
    We have to define a list of those variable names, which any driver/client
    has to know about.

    5. Overall architecture
    We have to make some decisions on file naming, file structure and other
    things.
    We also will review the overall UPDF structure in this session to check for
    consistency and wholes.

    Concerning the overall driver/client architecture I still see UPDF taking
    over where IPP stops. Although UPDF is not exclusively designed to work with
    IPP, it is leaning heavily towards it to ensure the best possible
    cooperation between these two concepts.
    So we like to get some more input from the IPP group, where they see
    requirements.
    We consider Boston a major event for the UPDF group and think the spec has
    grown to a certain level, which provides a much better base for a
    sophisticated validation than at the beginning of the year. This will and
    shall affect the way the spec will go heavily.

    It would be nice to get a head count, who from the group of UPDF attendees
    in Boston will be available on Thursday and/or Friday night AFTER work.
    Simple email will do.

    Regards
    Norbert Schade

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





    This archive was generated by hypermail 2b29 : Mon Oct 09 2000 - 03:08:48 EDT