Hi folks, Tuesday (3 December 2002)
At today's PSI Telecon, we proposed that both simple Jobs (in the Free
Software Group's PAPI/1.0) and Documents (in future PWG Semantic Model
and FSG Job Ticket API/2.0) should support an attribute that's a list of
filenames that "comprise the _single_ document (when concatenated), for
purposes of page exceptions".
Note that PAPI says the printer should do page breaks and separator
sheets between the files. That's not faithful to the model we agreed
upon in FSG Job Ticket API telecons: the running input text is simply
contatenated and subsequently repaginated in the output document format
(input filenames could have MS Word, PostScript, PDF, etc. extensions).
FSG PAPI reference implementation is CUPS over IPP/1.1 with extensions.
This semantic ambiguity should be resolved or the CUPS implementation
of the (future) IPP Job creation operation attribute "file-names" may
become broken.
Pete and Tom:
In FSG PAPI v0.9, this attribute is called "file_names", which would
become "file-names" for Job/Doc in IPP/1.x and "jobFileNames" and
"documentFileNames" in PWG Semantic Model, right? Or just always (on
Job or Document object) "document-file-names" in PWG SM and IPP?
Note that "document-file-names" is then orthogonal to the single-valued
"document-format" (because given document formats are _implied_ by the
filename extensions by universal convention).
Opinions?
Cheers,
- Ira McDonald
High North Inc
------------------------------------------------------------------------
ftp://ftp.pwg.org/pub/pwg/fsg/spool/papi-v0.9.pdf (18 November 2002)
[Extracted from section 7.2 "papiJobSubmitByReference" of PAPI/0.9, the
description of the input operation parameter "file_names"]
file_names
NULL terminated list of pointers to names of files to print. If more
than one file is specified, the files will be treated by the print
system as separate "documents" for things like page breaks and separator
sheets, but they will be scheduled and printed together as one job and
the specified attributes will apply to all the files.
These file names may contain absolute path names, relative path names or
URIs ([RFC1738], [RFC2396]). The implementation SHOULD NOT copy the
referenced data unless (or until) it is no longer feasible to maintain
the reference. Feasibility limitations may arise out of security
issues, namespace issues, and/or protocol or printer limitations.
Implementations MUST support the absolute path, relative path, and
"file:" URI scheme. Use of other URI schemes could result in a
PAPI_URI_SCHEME error, depending on the implementation.
The semantics explained in the preceding paragraphs allows for
flexibility in the PAPI implementation. For example:
(1) PAPI on top of a local service to maintain the reference for the
life of the job, if the local service supports it.
(2) PAPI on top of IPP to send a reference when the server can access
the referenced data and copy it when it is not accessible to the server.
(3) PAPI on top of network printing protocols that don't support
references to copy the data on the way out to the remote server.
This archive was generated by hypermail 2b29 : Tue Dec 03 2002 - 15:39:57 EST