Printer Services Mail Archive: PS> Multiple filenames per Jo

PS> Multiple filenames per Job/Document

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Dec 03 2002 - 15:39:23 EST

  • Next message: McDonald, Ira: "PS> RE: URI GUID example"

    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