[Printing-architecture] [Printing-summit] OPS Preparationminutes (28 March 2012)

Mon Apr 2 15:57:49 UTC 2012

Wow!  I have a different scenario.

I see generation of a Print Job Ticket by a Print Client as a very simple process.   Using C-Code as an example; it is nothing more that a collection of canned “printf” statement were the argument are the Print Intent values expressed in the specific Print Job Ticket “language”.   The Print Client only wants to output one Print Job Ticket format, not one of several. 

I see parsing Print Job Ticket by a Print Service as an equally simple process; although there is a lot of content/data checking.   The Print Service only wants to accept one Print Job Ticket format, not one of several.

The difficult part is when the Print Client Print Job Ticket format does not match the Print Service Print Job Ticket format - an impedance mismatch; thus, JTAPI, provides the impedance matching or a transform service. 

What you are outlining implies that a Print Client or Print Service internally would need to use a set of data structures and definitions that supports JTAPI, where it may better for the Print Client or Print Service to support the Print Job Ticket more directly.   This does lead to the ever pending problem of “Common”; either a Common Print Client or even a Common Print Service.  For a Common Print Client it implies what “Label” or “Name” and what “values” should be displayed.   If JTAPI definitions, values and names are to be used; then, JTAPI become useful for converting any Print Job Ticket to a common internal format for every one to use.   I like this idea.

The same concept applies to capabilities information which is based Print Job Ticket formats/definitions. 

============

For the GSOC the time constraint, we may only get Print Job Ticket format Foo converted to an internal structure.   We can try to both read and write of that Print Job Ticket format. 

============

Since there may be an issue using or modifying MJT (copyright, etc), I will create a very simple MIT license Print Job Ticket format for JTAPI GSOC.   Again, the goal of JTAPI this year is end-to-end code with a very well documented set of code that will be used as illustration of implementing JTAPI.   The Print Job Ticket format is not important this year.  Next year or in a separate project, a standardized Print Job Ticket format can be instantiated. 

Glen

________________________________

From: Ira McDonald [mailto:blueroofmusic at gmail.com] 
Sent: Monday, April 02, 2012 8:12 AM
To: Petrie, Glen; Ira McDonald
Cc: Daniel Dressler; printing-architecture at lists.linux-foundation.org; printing-summit at lists.linux-foundation.org
Subject: Re: [Printing-architecture] [Printing-summit] OPS Preparationminutes (28 March 2012)

Hi Glen,

I agree with you that the *3rd* use case is a Client producing
JDF and and PrintService converting it to PJT w/ JTAPI.

But the other two use cases (I think the dominant ones)
don't involve ANY conversion:

(1) Client builds an abstract job ticket using JTAPI and says
write it out to a given format.

(2) PrintService accepts that concrete job ticket and parses
it w/ JTAPI and uses the JTAPI parsed attributes as input
to the Scheduler and Interpreter subunits to process the
job.

Your  3rd use case of conversion of formats can't be
demonstrated without at least 2 backends - it's harder,
not simpler.

For all I care there's a reference only backend that writes
out (and reads in/parses) only an internal C struct form
of a job ticket.  

Or writes out MJT, but it That intellectual property and
status issues - the spec is PWG copyrighted and it's
a whitepaper, not an approved PWG project (that is, we
CANNOT modify MJT w/out PWG permission).

WDYT?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic> 
http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc> 
mailto:blueroofmusic at gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

2012/4/2 Petrie, Glen <glen.petrie at eitc.epson.com>

Ira,

I must admit to being totally confused.   I always under the impression that JTAPI was a classic definition of a transform service and not just a job ticket interpreter for a Print Service.    I thought a transform service accepts one document format and product a different document format; which is what I thought JTAPI did.  Example, accept a JDF job ticket and produce a PWG job ticket.  

What you describe below is what I would call it an interpreter and, maybe, that you have considered JTAPI to be.    Then, at least to me, the existing JTAPI may not be what is needed.   What is needed is a generic JDF interpreter, a PWG:PJT interpreter, …; that is, what I called the front-end to JTAPI.

I always saw the use case as:  A Print Service accepts PWG:PJT but the Print Client produced JDF.   Thus, the either the Print Client or the Print Service uses the JTAPI Transform Service to transform JDF to PJT.    The Print Service would already have its own interpreter to parse PWG:PJT into what ever internal format the Print Service needed or used.   [ I had always hoped that someday we could have a defined a the internal format that everyone would use but I don’t think that will ever happen.]