Sergi,

Scaling and rotation could be applied to Print but at this time they are not included in any current IPP specification and therefore not included in the Print Service portion of the MFD specification.   Perhaps JPS3 can include them if there is a desire and people willing to work on it.

There are limited controls that cover how an impression is laid out on a media sheet (e.g., OrientationRequested, Resolution, NumberUp, the various [X|Y] Image [Shift|Position] elements).   If Scaling and Rotation are included then JPS3 will have to address the interactions of these IPP job Template attributes

The Transform Service is currently only a place holder.  The intent is for that service to be addressed after the services currently being actively worked.  It is incomplete and can be ignored for now.  There is no intent for simple services (e.g., copy, print, scan) to require a workflow to produce output.  The transformation service was intended primarily as an “Impedance matcher” between the output of one service and the input of another.  The transform service could also function independently to extend the capabilities of an MFD.

Pete

Hi there,

I have noticed that in the Semantic Model v2, the job/document processing ticket only has scaling and rotation elements for image output services but not for impression output services. This seems to be inconsistent, since printers are also able to scale and rotate documents when ripping.

On a related note, rotation and scaling is available in the TransformService, but this service has no operations defined in ServicesOperations.xsd. Should rotation & scaling for printing be ordered by setting a workflow with the TransformService feeding into the PrintService ? if so, how ?  why is this different for the ScanService ?

Thanks,

Sergi Casas

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

The last call period for the proposed WIMS project charters has ended. We thank those who reviewed these proposed charters and submitted comments. However, the response was not sufficient to meet the minimum response to PWG last call. In addition, several of the comments received did reflect on several basic problems with two of the charters, the CMMI and the CIMPrinterProfile; not the least of these problems was the lack of identified personnel to perform the project. Therefore, rather than extent last call, the WIMS decided to withdraw the charter proposals for these two projects. Updated charter proposals may be submitted in the future if and when there is more interest on the part of PWG membership and more people willing to be editors, contributors and WIMS officers. In the meantime, members of the WIMS may continue to consider, brainstorm on and do preliminary work on these projects, in keeping with the provisions of the documented PWG Process.

Such preliminary activity has been proceeding with regard to the MFD Alerts project, which is actually a resumption of a project that had been suspended several years ago. Considering that significant work has been done on this MFD Alerts project, that we have  a volunteer editor, and that there has been interest expressed in the project, the WIMS has elected to use the more conventional project charter approval path of requesting  Steering Committee approval of an MFD Alerts Charter draft, after it has been updated to reflect the comments that have been received.

The WIMS members thank you for your consideration. Please feel free to express your thoughts on these decisions on the WIMS mailing list.

Bill Wagner, WIMS Chairman

All,

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

All,

The newly approved PWG Candidate Standard "Copy Service Semantic Model and Service Interface v1.0" [PWG 5108.04-2011] is posted on the PWG server at:

<ftp://ftp.pwg.org/pub/pwg/candidates/cs-sm20-copy10-20110610-5108.04.pdf>

it's also listed on the PWG standards web page with the Abstract at:

< http://www.pwg.org/standards.html>

The MFD Working group page has been updated with the approved specification and includes links to the associated schema and the official namespace.  Note that no new namespace is required.  This specification uses the same namespace as PWG 5108.01.  The MFD page is available at:

<http://www.pwg.org/mfd>

Peter Zehler

Chair of PWG’s MFD Working Group

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler <at> Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

All,

The Last Call period for the FaxOut specification has been extended until 6/24/11.  We currently have less than half the responses required to move this specification forward.  Please take some time and respond even if you have no comments so that quorum can be reached.

Pete

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler <at> Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Considering the Cloud Imaging scenario discussion  of June 6 and the IPP scenario discussion of June 13, as well as face to face discussions, perhaps I have just missed the point but it seems we have wandered about in circles  (which is to say that we apparently have concluded that our first approach was correct, which it may be). Dealing with the “Best Practices” document, we have concluded that there need be just one scenario for each of the imaging functions: print, scan and fax.  This “Scenario” becomes basically just a very general statement of what is involved in printing, or faxing, or whatever;  I suggest that although it may be a useful starting point, it does not provide the usefulness of a more detailed  scenario.

Further, it seems that two different approaches have been proposed  about how the “use cases”  will be extracted from this single “scenario”.  One is a sort of horizontal approach by which  each of the basic steps of the scenario refers to a set of use cases; for example, “Selecting a Printer” , “Submitting a Print Job”, etc.   The other, perhaps best described as vertical approach, would be to outline sequences of how a user in a particular situation would print, sort of a narrow scenario something like the use cases that were first submitted.

Granted that we can use whatever terms we wish, provided that we properly define them,  I do think that in using common engineering development terms we should not deviate too much from accepted usage. I suggest looking at

http://en.wikipedia.org/wiki/Scenario_%28computing%29 and http://en.wikipedia.org/wiki/Use_case, or perhaps the more formal documents referenced by these articles.

But calling it scenario or use case, I do think that one of the main benefits of outlining a realistic start-to-end sequence (from “I want to print something” to “I know  that that  something was printed and where it was output”) is that one sees (and reviewers see) interactions that might be lost in a purely horizontal approach . What is more, people can follow a realistic sequence and the use cases can become, as Randy suggested they must be, more “compelling”.

In short,  I suggest:

1.     Our terminology be not inconsistent with typical design terminology

2.     We define our approach and terminology in the “Best Practices” document

3.     We be consistent in terminology and level within the “Best  Practices” document and among the various projects (It would be very confusing to have a Use Case in one document become a Scenario in another.)

4.     We not lose the “story” aspect and the  sequence of what the user does and what the “system” must do… Joe is on vacation at Yellowstone and needs to print out the map to a lost gold mine in Wyoming that his friend in New York City just found. Perhaps the story is farfetched, but it includes many aspects of the general problem that must be considered.

Thanks,

Bill Wagner