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
definitions.
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
smoothness.
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@easysw.com]
Sent: Wednesday, October 23, 2002 07:56
To: Hastings, Tom N
Cc: ipp@pwg.org
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:
>
> 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-----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, December 03, 2002 13:04 To: Keeney, Rick; Podelnyk, Ted Cc: sm@pwg.org; digital_printing@cip4.org; PPMLSpec_JobTickets Listmanager; printing-jobticket@freestandards.org 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@pwg.org with the following in the body of the message:
subscribe sm end
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 so).
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.
Tom
-----Original Message----- From: Zehler, Peter [mailto:PZehler@crt.xerox.com] Sent: Monday, December 02, 2002 11:35 To: PWG Semantic Model WG (E-mail) Subject: SM> This week's SM teleconference agenda and information
All,
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. "ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf" 3) Discuss "The Printer Working Group Standard for the Internet Printing Protocol (IPP): Color and Imaging Attributes" "ftp://ftp.pwg.org/pub/pwg/ipp/new_COLOR/pwg5100.8-D01-021018.pdf" Note that this conversation is IPP specific. 4) Next steps
Pete Peter Zehler XEROX Xerox Architecture Center Email: PZehler@crt.xerox.com 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 week. ________________________________________________________
Dial in Info: Phone Number: (877) 776-6306 (Phone Number for Xerox Employees: 8*594-0576) PARTICIPANT PASSCODE: 437874# ________________________________________________ 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.
------------------------- FIRST TIME USERS ------------------------- 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: https://hp.webex.com/join/
Then click join unlisted meeting. Use the info below: ------------------------- Webex MEETING SUMMARY ------------------------- 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 Host: Bob Taylor (HP) ___________________________________________________
_________________________________________________________________________ Document Object Issues: Pete,
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 New 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 support.
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 5100.4).
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" = 'separate-document-collated-copies'.
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 operations.
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 data).
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.
Comments?
Thanks, Tom _________________________________________________________________________
_______________________________________________ printing-jobticket mailing list printing-jobticket@freestandards.org http://freestandards.org/mailman/listinfo/printing-jobticket
This archive was generated by hypermail 2b29 : Tue Dec 03 2002 - 22:58:47 EST