SM> PWG Review of the IPP Color and Imaging Attributes version 0.1, T hur, 12/5/02, 1-2 PM EST

SM> PWG Review of the IPP Color and Imaging Attributes version 0.1, T hur, 12/5/02, 1-2 PM EST

Hastings, Tom N hastings at
Tue Dec 3 22:53:14 EST 2002

Here are some collected comments on the IPP Color and Imaging Attributes for
Thursday, 12/5/02 telecon (details below and previously sent).

Michael Sweet proposed adding two IPP Job Template attributes:
adjust-hue (integer(-180:180)) and image-subsample (type2 keyword).
The "image-subsample" proposed values: 
            "none"   = nearest-neighbor sampling
            "linear" = linear interpolation
            "cubic"  = cubic interpolation
He also suggested that we define conformance groups for the attributes in
order to get better interoperability.  See email embedded below.

I've attached a fleshed out specification for "image-subsample", which we
have reviewed at Xerox and called it "resample-method".  Delmar's Dictionary
of Digital Printing & Publishing had "resample", but not subsample.  The
attached proposal includes the following methods:
'nearest-neighbor', 'bi-linear', 'filtered', 'automatic', 'special'.  

We need to consider adding 'linear' and 'cubic' (or bicubic) with good
Here is Acrobat Distiller 5.0 help on downsampling:

downsample-method: (similar to resample-method but one directional)
                   {average, subsample, bicubic}
                   From acrobat help: 
                   'average' takes an average of pixels in sample region and

                   replaces the entire area with the average pixel color at

                   spec resolution
                   'bicubic' uses a weighted average, with better results 
                    than simple averaging
                   'subsample' chooses a pixel in the center of the sample
                    area and replaces the entire area with that pixel at the

                    specified resolution. Fastest but results in less 

Also Acrobat can apply resampling independently to color bit map images,
gray-scaled bit map images, and monochrome bit map images.

Here is Michael's email:

-----Original Message-----
From: Michael Sweet [mailto:mike at]
Sent: Wednesday, October 23, 2002 07:56
To: Hastings, Tom N
Cc: ipp at
Subject: Re: IPP> First draft IPP standard for Color and Imaging
Attributes availab le

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:

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 at
Printing Software for UNIX             

-----Original Message-----
From: Hastings, Tom N [mailto:hastings at]
Sent: Tuesday, December 03, 2002 13:04
To: Keeney, Rick; Podelnyk, Ted
Cc: sm at; digital_printing at; PPMLSpec_JobTickets
Listmanager; printing-jobticket at
Subject: [printing-jobticket] FW: SM> This week's SM teleconference
agenda and information

Rick and Ted (and other CIP4 Digital Printing WG members, PODi Job Ticketing
WG members, and FSG Job Ticket API members),

There is a one hour PWG (Printer Working Group) Semantic Model telecon this
Thursday, 10-11 AM PST (1-2 EST), to review two IPP documents:
IPP Document Object
IPP Color and Imaging Attributes
(See below how to obtain the documents)
See below for dial-in numbers and webex connections.

The attributes in the IPP Color and Imaging Attributes spec are the ones
just added to the CIP4/PODi/FSG IPP to JDF/1.1, CUPS, FSG JTAPI, PODi
mapping table.

If you want to send comments ahead of the meeting (much appreciated) join
the Semantic Model mailing list (which is needed in order to send email to
the list because of spam), subscribe using the usual Majordomo:

Send to majordomo at
with the following in the body of the message:

   subscribe sm

But you don't need to subscribe to join the teleconference (and your company
doesn't need to join the PWG either, though we welcome your company to do

I'll send out a proposal from Michael Sweet for two additional attributes:
"adjust-hue" (integer(-180:180))
"image-subsample" (type2 keyword)
and a "resample-method" (type2 keyword) counter proposal for the latter in a
separate mail message.


-----Original Message-----
From: Zehler, Peter [mailto:PZehler at]
Sent: Monday, December 02, 2002 11:35
To: PWG Semantic Model WG (E-mail)
Subject: SM> This week's SM teleconference agenda and information


This Thursday at 1pm EDT is the Semantic Model teleconference. The
teleconference is one hour long.  It will be run using both phone and Webex.
Anyone that does not yet have Webex installed should do that before
Thursday.  Information for the phone and Webex are included below.

The agenda for the Semantic Model teleconference is

1) Status on Semantic Model and associated schema
2) Discuss outstanding issues in the Document Object Specification
   The 4 outstanding issues are included below in an excerpt from a mail
note from Tom Hastings
    (The document has not been updated since our last conversation.  The 6
included issues have been resolved.)
   Note that this conversation is IPP specific.
3) Discuss "The Printer Working Group Standard for the Internet Printing
Protocol (IPP):
    Color and Imaging Attributes"
     Note that this conversation is IPP specific.
4) Next steps

				Peter Zehler
				Xerox Architecture Center
				Email: PZehler at
				Voice:    (585) 265-8755
				FAX:      (585) 265-8871 
				US Mail: Peter Zehler
				        Xerox Corp.
				        800 Phillips Rd.
				        M/S 128-30E
				        Webster NY, 14580-9701

PS to Bob Taylor:  Let me know if there is any problem with Webex for this

Dial in Info:
Phone Number: (877) 776-6306
(Phone Number for Xerox Employees: 8*594-0576)
webex info:
We will also use an on line tool called webex,
if you have not used this before, setup up by
following the First Time Users instructions.
Do this in advance of the meeting.

For fully interactive meetings, including the ability
to present your documents and applications, a one-time
setup takes less than 10 minutes. Click this URL to set up now:

Then click New User.

On Thursday use:

Then click join unlisted meeting.
Use the info below:
Name: PWG Semantic Model 
Date: 12/5/2002
Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time)
         10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time)
Meeting Number: 21366675
Meeting Password: pwg_sm
Bob Taylor (HP)

Document Object Issues:

I sent the original note to the SM DL on November 21.  Here is the revised
note dropping the suggestion to make Send-Document OPTIONAL.  Send-Document
should remain REQUIRED in the Document object spec for two reasons:

1. OPTIONAL operations aren't supported by clients.
2. If the client supplies "ipp-attribute-fidelity" = 'false' or omits it,
the client may as well use Send-Document since the Printer MUST accept it,
rather than the two operations: Create-Document and Send-Data.

Here is the original mail note with edits:

Peter has relayed some concerns raised at the Semantic Model WG meeting in
Orleans about low end (non-spooling) Printer support for the Document
object.  Those concerns included:

A. Create-Document and Send-Data operations being REQUIRED for a Printer to

B. A client can create "holes" in the document numbering space and send
documents in any order using the "document-number" operation attribute for
Create-Document, Send-Document, and Send-URI.  The suggestion was to remove
the "document-number" operation attribute from the specification for all
operations.  Then there can't be holes in the document numbers.  Make the
client create the documents in the order wanted in the output, so that the
Printer will number them as the client wants.  (Also need to deprecate the
"document-number" operation attribute for use with the Send-Document and
Send-URI operations in the PWG Document Overrides specification - IEEE-ISTO

Here is a rather long note that proposes to:
1. eliminate the REQUIRED Validate-Document operation altogether.
2. keep Create-Document and Send-Data REQUIRED (see reasoning below).  
3. Remove the "document-number" operation attribute because it isn't needed
since Create-Document would always be available (see reasoning below).
4. Consider deleting the Cancel-Current-Document, since its pretty funky if
"copies" is > 1.

I've discussed this mail note with Gail Songer before sending it.  She was
one of the people at the meeting who was concerned about low end Printers
that wanted to support the Document object.  She could not find any flaws in
the reasoning in this email note.

Goals and Requirements for the Document object spec:

Goal 1. In order to improve interoperability, we need to eliminate
operations and operation attributes that are OPTIONAL for a Printer to
support.  In fact, if an operation or operation attribute is OPTIONAL for a
Printer to support, it is highly unlikely that clients will bother to
support the feature.  Also we want to define as small a number of different
ways to submit a multi-document job as possible, as long as they cover the
important use cases.

Goal 2: The Document object should be supportable by a non-spooling low end
printer as well as a higher end spooling printer.

The non-spooling low end printer can't support making copies (except for
really short documents), except for "sheet-collate" = 'uncollated'.  Such a
Printer starts to mark document data as it is received.  So such a Printer
cannot support "multiple-document-handling" =

In principle, the spooling printer can support all values of "sheet-collate"
and "multiple-document-handling".

However, the non-spooling Printer MUST keep the Document object (but not the
data) for the lifetime of the Job.  The Printer cannot throw away the
Document object as soon as the Document has been printed, but MUST keep it
until the Job is completed.  This requirement means that there is no extra
burden on a non-spooling Printer to have to accept multiple Create-Document
requests for a given job before getting any data.  It has to keep all of the
Document objects for the life of the job anyway.

Goal 3. There are two client use cases that the spec needs to support: 

Use Case A. A client should be able to validate all the documents in a
multi-document job, before sending the data for any of them.  If the Printer
can't support a document or can't support it when combined with other
documents in the same job, the client can avoid sending any data, or decide
with the user which documents to actually submit in the Document Creation

Usage Case B. A client should be able to validate a document and send the
data, validate the next document and send its data, etc. 

Given the above, here are my suggestions for the spec with my reasons:

1. Validate-Document should be removed from the spec (even though Printer's
are REQUIRED to support it in the current version).  

If the client performs a Create-Document with "ipp-attribute-fidelity" =
'true', then it is practically the same as Validate-Document.  If any of the
supplied attributes or values are unsupported, the Printer rejects the
operation and its the same a Validate-Document.  Only if the Create-Document
succeeds, does the Printer actually create the Document object which is
probably what the client would want anyway (Use Case B).  (In the unlikely
case that the client didn't want to create the Document object, the client
can do a Cancel-Document operation).

For the Validate-Document case when not supplying the "job-id", the client
can obtain the same functionality by using Validate-Job with each Document
separately, before sending any data (Use Case A).

Another reason to get rid of Validate-Document is because it doesn't
completely allow validation of all documents before sending any data (Use
Case A).  For example, if a Printer object represents a one-sided color
printer and a two-sided black and white printer, Validate-Document will not
correctly validate a two-document job consisting of a two-sided black and
white document and a one-sided color job.  This is because one of the
Document objects has to be created in order to validate the other Document
in combination.  Secondly, if we REQUIRE Create-Document, there is no need
for Validate-Document, since Create-Document creates the Document object and
validates it in the context of the job (without the client sending any

Also eliminating Validate-Document removes another REQUIRED operation
attribute for the Printer to support in Validate-Document, namely, the
"job-id".  So the Printer doesn't have to have two validate paths, one for a
document in the context of a job and the other for the document by itself,
thereby simplifying Printer implementation and eliminating another set of
cases to be tested.

I know that the PSI also has Validate-Document, so we'll need to try to
convince them to drop Validate-Document as well.

2. Remove the "document-number" OPTIONAL operation attribute from the spec
for Create-Document, Send-Document, and Send-URI (Goal 1 above).  The
"document-number" operation attribute was added to the Document Override
spec per request from Carl Kugler to support sending multiple document data
in parallel (on separate channels) for high end applications.  The client
can force the Printer to number the documents by ordering the
Create-Document operations in the desired order and then send the data in
parallel for the documents.  In order to meet the requirements of a
non-spooling printer, the client MUST issue the Send-Data request for each
document in order.  If the Printer gets a Send-Data out of order (and can't
spool), then the Printer rejects the Send-Data with an error code:
"client-error-documents-not-in-order".  If the client had a race between
different threads, then each thread will back off an try again when it gets
this error.  If the client is single threaded, then the error indicates a
bug in the client.

3. Keep Create-Document and Send-Data as REQUIRED for the Printer to
support.  Then these two operations are the preferred way for a client to
submit a multi-document job.  Keeping them REQUIRED means that clients will
bother to support them.  If they are OPTIONAL, most clients won't bother
supporting them.  Finally, keeping them REQUIRED means that we can remove
the "document-number" operation attribute all together (as in point number 2
above), since Clients that want to submit data in parallel can do so using
multiple Create-Document calls in serial followed by multiple Send-Data
operations in parallel (on separate channels).  

Having two operations, one to create the Document object and the other to
send the data, does REQUIRE the Printer to deal with the time-out problem.
But multi-document jobs already have to deal with the time-out problem,
after a Create-Job operation anyway, so timing out a Send-Data the didn't
happen soon enough after a Create-Document shouldn't be much of an extra
burden on the Printer.

After we did IPP/1.1, we wished that we had made Create-Job and
Send-Document REQUIRED, instead of Print-Job.  After operational experience,
even Paul Moore regretted that Microsoft had demanded that the IPP WG make
Print-Job be REQUIRED and Create-Job/Send-Document be OPTIONAL.  The problem
with Print-Job (and Send-Document) is that the client has to wait to get
back a failure status code in a Print-Job response until after the client
has wasted its time sending all of the data.   Lets learn from our
experience with IPP/1.1 on the Job object and not repeat the same mistakes
on the Document object.

However, when the client supplies the "ipp-attribute-fidelity" = 'false' or
omits it, the client can be more efficient by using Send-Document, instead
of Create-Document and Send-Data, since the Printer MUST accept such a
request no matter what attributes and values are supplied.  So keep
Send-Document REQUIRED as well.

Here is the list of operations:

Operation Name             Printer     Printer
                           support     support
                           V0.1        proposed 

Create-Document            REQUIRED    REQUIRED 
Send-Data                  REQUIRED    REQUIRED 
Send-Document *            REQUIRED    REQUIRED 
Send-URI *                 OPTIONAL    OPTIONAL 
Validate-Document          REQUIRED    delete 
Get-Document-Attributes    REQUIRED    REQUIRED 
Get-Documents              REQUIRED    REQUIRED 
Set-Document-Attributes    OPTIONAL    OPTIONAL 
Cancel-Document            REQUIRED    REQUIRED 
Cancel-Current-Document    OPTIONAL    delete **? 
Delete-Document            OPTIONAL    OPTIONAL 
* The existing IPP/1.1 operations defined in [RFC2911] with an extension so
the client can supply Document Template attributes in a new attribute Group
in the request. 
** Cancel-Current-Job is fine, but Cancel-Current-Document is pretty funky
if the job has multiple documents and  "copies" is greater than 1.  



printing-jobticket mailing list
printing-jobticket at

-------------- next part --------------
A non-text attachment was scrubbed...
Name: resample-method-proposal.pdf
Type: application/octet-stream
Size: 10919 bytes
Desc: not available
Url :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resample-method-proposal.doc
Type: application/msword
Size: 24576 bytes
Desc: not available
Url :

More information about the Sm mailing list