IPP Mail Archive: Re: IPP> First draft IPP standard for Colo

IPP Mail Archive: Re: IPP> First draft IPP standard for Colo

Re: IPP> First draft IPP standard for Color and Imaging Attributes availab le

From: Michael Sweet (mike@easysw.com)
Date: Wed Oct 23 2002 - 10:55:31 EDT

  • Next message: Zehler, Peter: "IPP> "-actual" multivalue types issue"

    Hastings, Tom N wrote:
    > I've down loaded a first draft for an IEEE-ISTO IPP Color and Imaging
    > Attributes standard to the PWG FTP site. Most of the attributes
    > control color and imaging that is prevalent in the industry following
    > industry standards. The files are available at:
    > ftp://ftp.pwg.org/pub/pwg/ipp/new_COLOR/pwg5100.8-D01-021018.pdf
    > ftp://ftp.pwg.org/pub/pwg/ipp/new_COLOR/pwg5100.8-D01-021018.doc

    OK, I've only had a chance to skim this draft, but some thoughts:

         1. There is no "adjust-hue (integer(-180:180))" attribute;
            this is something that CUPS has provided since day one,
            and it has some interesting (and sometimes even practical :)
            applications when printing images.

         2. There are no "image-subsampling" attributes, only the
            "anti-aliasing" attributes. Most images are subsampled
            when printed (since the printer resolution is typically
            != the image resolution), and it can be important to
            specify the default subsampling in documents. I would
            suggest the following pre-defined keyword values:

                "none" = nearest-neighbor sampling
                "linear" = linear interpolation
                "cubic" = cubic interpolation

            Other algorithms are also possible (some include sharpening
            effects, etc.), but these three cover the common algorithms.

         3. The current conformance requirements are pretty vague.
            It might be useful to summarize the basic conformance
            requirements of each group of attributes in section 6,
            or at the begining of each group, so that implementers
            can know immediately which attributes are REQUIRED and
            which are OPTIONAL. At the same time, this will allow
            clients to determine quickly if the destination device
            supports the group of attributes it needs.

            (I guess I'm saying we need to define that some groups
            of attributes are connected, and if you implement one
            you have to implement them all for consistency)

    Michael Sweet, Easy Software Products                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com

    This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 10:57:45 EDT