IFX Mail Archive: IFX> UIF Conformance bugs around Reduction

IFX Mail Archive: IFX> UIF Conformance bugs around Reduction

IFX> UIF Conformance bugs around Reduction, Scaling, and mid-job Media switching

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Mon Jul 02 2001 - 19:00:55 EDT

  • Next message: Hastings, Tom N: "RE: IFX> Brief minutes of UIF review, Wed, 6/27/01"


    While writing up the minutes I discovered several problems with the
    conformance sections in the UIF document:

    1. Section 5.5 Image reduction supported talks about the Sender MAY query
    the Receiver to see whether or not the Receiver supports Reduction. I
    suggest that the Sender MUST query the Receiver, if the Sender is going to
    use Reduction, but NEED NOT query the Receiver if the Sender is not going to
    use Reduction.

    The Receiver MUST indicate whether or not it supports Reduction.

    Also the Sender MUST query the Sending User to use Reduction; the Sender
    MUST NOT request Reduction unless explicitly indicated by the Sending User.

    2. Section 6 is entitled "Sender requirements" and Section 7 is entitled
    "Conformance Requirements".

    But Section 6 is talking about BOTH Sender and Receiver requirements but
    only about regarding reduction (section 6.1) and media selection (section

    I suggest that section 6.1 Image Reduction be promoted to header1 (and the
    current Section 6 header1 "Sender requirements" disappear). It can start
    off by stating that Image Reduction is an OPTIONAL feature for Senders and

    We agreed on Friday that the Image Reduction that the Sender sends is
    "allowing the Receiver" to reduce, rather than tile, if the Receiver
    supports reduction. The Receiver MUST support tiling.

    3. Intra-job media selection

    Section 6.2 "Intra-job media selection" is strongly related to the issue of
    not losing data in section 6.1. Section 6.1 talks about saving data either
    by tiling (Receiver MUST support) or by Reduction (Receiver MAY support).
    Section 6.2 talks about a third way to avoid data loss because a Receiver
    could switch to a larger media size than the media that the Sender requests
    if there was more data on a page than would fit on the media selected by the

    Thus there are really three ways that a Receiver can avoid losing data from
    images sent by the Sender:

      a. The Receiver can tile the image onto a number of sheets (the Receiving
    User can tape the sheets together to get the actual result).
      b. The Receiver can reduce (but only if the Receiver supports Reduction
    AND the Sender grants permission to reduce).

      c. The Receiver can select a larger media sheet (if supported by the
    Receiver, but probably only if human intervention is not needed). I'm
    suggesting that a Receiver MAY support switching media, but NEED NOT. How
    does the Receiver indicate whether or not? Perhaps, by the "media-ready"
    having larger sizes? How a Sender queries for changing media needs to be
    added to UIF and IFX.

    4. Precedence of tiff tags versus IPPFAX "media" protocol attribute

    In the Friday IFX review (John was not present) we agreed that the tiff tags
    would switch media, i.e., take precedence over the "media" attribute in the
    IPPFAX protocol. There is the statement in UIF:

      "The ImageWidth and ImageLength TIFF tags MUST NOT select the media."

    However, I'm not certain which TIFF tags we were talking about on Friday?
    What is ImageWidth and ImageLength or some Media tags?

    5. Section 7 is a good summary of the overall Conformance Requirements for
    Sender and Receiver. However, we probably need separate tables or columns
    for what the Sender MUST query BEFORE sending a document versus what the
    Sender MUST send when submitting a document.

    For example, the last line: "image reduction supported" indicates MAY for
    the Sender and MUST for the Receiver. This is correct for queries, but is
    not correct for support. The Receiver NEED NOT support reduction. (In IFX
    a Receiver indicates that it doesn't support Reduction by not returning the
    "reduction-supported" attribute at all.

    6. The section numbers in the last column of the table in section 7 are
    wrong and/or aren't in the document.


    This archive was generated by hypermail 2b29 : Mon Jul 02 2001 - 19:01:03 EDT