CA2346215C - Fast reprint file format that utilizes private tags to provide reprintable jobs that can be viewed and edited using standard tools - Google Patents
Fast reprint file format that utilizes private tags to provide reprintable jobs that can be viewed and edited using standard tools Download PDFInfo
- Publication number
- CA2346215C CA2346215C CA002346215A CA2346215A CA2346215C CA 2346215 C CA2346215 C CA 2346215C CA 002346215 A CA002346215 A CA 002346215A CA 2346215 A CA2346215 A CA 2346215A CA 2346215 C CA2346215 C CA 2346215C
- Authority
- CA
- Canada
- Prior art keywords
- file
- job
- wrapper
- image data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Accessory Devices And Overall Control Thereof (AREA)
Abstract
The invention involves the use of a PDF file, augmented with Private PDF tags that conform to the Adobe PDF 1.3 specification. This file, termed a wrapper, serves to organize the various elements of the saved job, namely the display resolution image data, print resolution image data, and the job programming file, as well as provides the infrastructure to manipulate the saved job independent of the operating and file system of the host computer.
Description
FAST REPRINT FILE FORMAT THAT UTILIZES PRIVATE TAGS TO
PROVIDE REPRINTABLE JOBS THAT CAN BE VIEWED AND EDITED
USING STANDARD TOOLS
Background of the Invention The present invention relates to the document processing arts. It finds particular application in conjunction with a method and apparatus for structuring a Portable Document Format (PDF) file utilizing private PDF
tags to provide a reprintable job that can be viewed and edited using standard PDF tools, and will be described with particular reference thereto.
The capacity to create a saved print job on which subsequent operations such as viewing thumbnails of the images of the job; re-order, deletion, and _ns~rtion of pages; and submission for fast reprint without requiring re-RIPping (raster image processing) is currently provided by various vendors only at the digital front end (DFE) of a document processing apparatus such as a digital copier. The saved print job and image formats are proprietary and the software to carry out the above operations is developed for and provided at the DFE only. There are two disadvantages of this approach, from the customer perspective, the user who submits a job for save will most likely be doing it from a networked platform whose operating system (OS) and file system are not identical to the DFE. Rather than being able to carry out any of the above operations from the same platform, the user must either go to the DFE, or provide
PROVIDE REPRINTABLE JOBS THAT CAN BE VIEWED AND EDITED
USING STANDARD TOOLS
Background of the Invention The present invention relates to the document processing arts. It finds particular application in conjunction with a method and apparatus for structuring a Portable Document Format (PDF) file utilizing private PDF
tags to provide a reprintable job that can be viewed and edited using standard PDF tools, and will be described with particular reference thereto.
The capacity to create a saved print job on which subsequent operations such as viewing thumbnails of the images of the job; re-order, deletion, and _ns~rtion of pages; and submission for fast reprint without requiring re-RIPping (raster image processing) is currently provided by various vendors only at the digital front end (DFE) of a document processing apparatus such as a digital copier. The saved print job and image formats are proprietary and the software to carry out the above operations is developed for and provided at the DFE only. There are two disadvantages of this approach, from the customer perspective, the user who submits a job for save will most likely be doing it from a networked platform whose operating system (OS) and file system are not identical to the DFE. Rather than being able to carry out any of the above operations from the same platform, the user must either go to the DFE, or provide
2 instructions to the DFE operator, which has a negative impact on customer workflow productivity. This is especially a problem if the end-user is submitting a job using a web-based submission client that is physically situated at a considerable distance from the DFE.
From the vendor perspective, this solution has a negative impact on reduction to practice since the proprietary job and image formats must be designed, documented and maintained along with the design, development and testing of the software that provides all of the above-described capabilities. Further, if the vendors chose to provide this capability at platforms other than the DFE, additional enhancements to the job and image formats would be likely required along with a port of the software to other platforms.
Accordingly, it has been considered desirable to provide a new and improved method for structuring a Portable Document Format (PDF) file utilizing private PDF
tags to provide a reprintable job that can be viewed and edited using standard PDF tools that meets the above-stated needs and overcomes the foregoing difficulties and others while providing better and more advantageous results.
Summary of the Invention In accordance with an aspect of the present invention, there is provided a method for generating a print job comprising the steps of:
a) decomposing the print job into print resolution image data and display resolution image data for each page of the print job, wherein said print resolution image data is in a post-raster-image-processed (postRIPed) format and said display resolution image data is a lower resolution replica of the print resolution image data;
b) generating a wrapper file and a job ticket file;
c) embedding the display resolution image data
From the vendor perspective, this solution has a negative impact on reduction to practice since the proprietary job and image formats must be designed, documented and maintained along with the design, development and testing of the software that provides all of the above-described capabilities. Further, if the vendors chose to provide this capability at platforms other than the DFE, additional enhancements to the job and image formats would be likely required along with a port of the software to other platforms.
Accordingly, it has been considered desirable to provide a new and improved method for structuring a Portable Document Format (PDF) file utilizing private PDF
tags to provide a reprintable job that can be viewed and edited using standard PDF tools that meets the above-stated needs and overcomes the foregoing difficulties and others while providing better and more advantageous results.
Summary of the Invention In accordance with an aspect of the present invention, there is provided a method for generating a print job comprising the steps of:
a) decomposing the print job into print resolution image data and display resolution image data for each page of the print job, wherein said print resolution image data is in a post-raster-image-processed (postRIPed) format and said display resolution image data is a lower resolution replica of the print resolution image data;
b) generating a wrapper file and a job ticket file;
c) embedding the display resolution image data
3 in the wrapper file;
d) embedding in the wrapper file pointers to the location of the print resolution image data;
e) storing attribute data for the print job in the job ticket file;
f) embedding pointers to the location of the job ticket file in the wrapper file; and g) storing the wrapper file, the job ticket file, and the print resolution image data on a save repository.
One advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file wrapper so that when printing a saved job, submission of the PDF file wrapper through existing submission mechanisms results in a digital front end associated with a document processing apparatus recognizing Private PDF tags embedded in the PDF wrapper, acting upon job programming instructions in an associated job ticket file, and printing associated print resolution images of the saved job.
Another advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file wrapper so that when viewing a saved job, any existing application (such as Adobe Acrobat ReaderT"') may be used to view the display resolution images that are embedded within the PDF file wrapper on any networked platform, including a digital front end associated with a document processing device.
Yet another advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file wrapper so that when editing a saved job, any existing application (such as Adobe Acrobat Exchanger"") may be used to re-order or delete pages of a job, or insert pages from one job into another on any networked platform, including a digital front end associated with a document processing device.
3a A further advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file wrapper so that when the edited job is submitted for print, the print resolution image files associated with the PDF file wrapper will print in the same order as the display resolution images that are embedded within the PDF file wrapper.
__g__ A further advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file wrapper so that the PDF
wrapper file may be submitted to a alternate printer resulting in a draft-mode print of the display resolution images that are embedded within the PDF file wrapper.
A still further advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file wrapper that provides the capability to access page and image data on demand and in any order.
Still further advantages of the present invention will become apparent to those of ordinary skill in the art upon reading and understanding the following detailed description of the preferred embodiments.
Brief Description of the Drawings The invention may take form in various components and arrangements of components, and in various steps and arrangements of steps. The drawings are only for purposes of illustrating a preferred embodiments) and are not to be construed as limiting the invention.
Figure 1 is a simplified block diagram of an exemplary network document processing system that incorporates the features of the present invention therein;
Figure 2 is a schematic representation of the Fast Reprint Format (FRF) logical job stru~~ture according to the present invention;
Figure 3 is a schematic representation of the Fast Reprint Format (FRF) physical job structure according to the present invention;
Figure 4 is a schematic representation of an exemplary PDF file that has not been updated;
__5-_ Figure 5 is a schematic representation of the logical document structure and salient objects of a PDF saved job file wrapper according to the present invention;
Figure 6 is a schematic representation for workflows for job view and edit at the digital front end of a document processing apparatus according to the present invention; and Figure 7 is a schematic representation for possible workflows for job view and edit at a client workstation that is in communication with digital front end of a document processing apparatus according to the present invention.
Detailed Description of the Invention With reference now to Figure 1, there is shown an exemplary network document processing system 10 comprising a plurality of document processing units. In particular, document processing system 10 comprises one or more clients such as workstations 12-1, 12-2, 12-3, . . . 12-n, which may be on-site (e. g. LAN) and/or remote (e. g. WAN), and at least one document processing apparatus 14 that communicates with the workstations 12 through a network or communication channels 16. As will be appreciated, while only a limited number of document processing units are shown in Figure 1, the preferred embodiment contemplates the use of as many document processing units as are required to meet the demands of the users of the system.
Clients 12 provide the electronic documents that are the source of the print jobs and, for this purpose, individual ones or all of clients 12 may have a document scanner, disk input, keyboard, fax, etc. for generating the electronic documents that comprise the job to be printed.
Clients 12 each have a User Interface (UI) with interactive screen (not shown) enabling programming selections for documents or jobs to be made.
--6__ The document processing apparatus 14 can take the form of a multi-functional document processing device, for example, a color digital copier that includes an Image Input Terminal (IIT) 18 such as a document scanner, an Image Output Terminal (IOT) 20 such as a printer/marker, a digital front end (DFE) or controller 22 with a User Interface (UI) module 24. As described in detail with respect to a further embodiment of the present invention, the DFE 22 can include an HTTP/Print server 26. As is known in the art, the multi-functional document processing apparatus 14 can also include a facsimile module 28, if desired. The multi-functional document processing apparatus 14 is conventionally connected to the network 16 through a network port associated with the DFE 22.
As described in detail below, the DFE 22 is configured or otherwise programmed to facilitate i) reprinting a saved print job at the engine speed of the IOT
(i.e. reprint a saved job without requiring re-RIPping), ii) viewing thumbnails of the images of a saved print job, 20 and iii) re-ordering, deleting and/or inserting pages of a saved print job, at any of the client workstations 12 and/or the UI 24 associated with the DFE 22.
It should be appreciated that, given the limitations of currently available processing power, it is not possible to save raster image data in an industry standard format yet provide reprinting at engine speed. Fast reprint essentially requires no re-RIPping of a saved job, and further requires that the compressed image data be saved in such a manner that it can be consumed directly by hardware decompressor boards without any (potentially time-consuming and productivity degrading) conversion or manipulation of the image data.
Besides reprint performance, preserving the image quality of the saved print job is an equally important consideration in choosing a scheme that does not involve re-RIPping the job and using a compression format that preserves control information. Preserving this information ensures that reprints of the saved job will print identically within system tolerance. Conversion to an industry-standard format that does not support the encoding of all of the image and control data that are present in the proprietary format will result in loss of information that will manifest in poorer image quality of the reprints.
Briefly, in order to create images that can reprint at the engine speed of the IOT 20 with good image quality, a compressed image format, termed the print resolution image (PRI) format, is necessary. To construct a display image from the compressed image data (i.e. the PRI image data) at the point of demand (e.g. at any one of the workstations 12) is too time-consuming to be of any practical value. Thus, according to the present invention, display image data, termed a Display Resolution Image (DRI) data, is generated at the same time that the PRI data is generated. Generally, the size of the DRI data is considerably less than the corresponding PRI data (less than about. 1~). As used herein, the term ADisplay Resolution Image- or simply ADRI- refers to an image that is a lower resolution replica of a printer resolution image that is typically used for display on a monitor. Further, as used herein, the term APrint Resolution Image- or simply APRI- refers to an image file in which the image data are in a postRIP compressed format.
A schematic view of a print job that is saved according to the Fast Reprint Format (FRF) of present invention is shown in Figure 2, and the physical structure of the saved print job is shown in Figure 3. As used herein, the term AFast Reprint Format- or simply AFRF= refers to a __g__ format that specifies the encoding of job and image attributes in which the image data are in postRIP compressed form that may be consumed directly by the video path to the IOT. Further, the Fast Reprint Format also refers to a format that permits the use of existing third-party tools to perform various operations of saved print jobs and their contents, and to encapsulate the details of a saved print job file and image formats.
The saved print job is not a single file but a collection of files that is stored in a single container directory. The saved print job is not referenced by its components but by the name of the container directory 30.
There are four distinct components of a saved print job according to the present invention: i) a job ticket file 32 that describes the job programming of the saved print job (a job ticket file conventionally encodes those job attributes that are required to enable the reprint of a saved print job); ii) a set of images composed of print-ready (i.e.
postRIPed) compressed raster data (i.e. the PRIs) 34; iii) a corresponding set of display resolution images (DRI) 36; and iv) a saved job Afile wrapper- 38 that sequences the set of print-ready PRIs and DRIB and encodes their attributes. As described in detail below, the DRIB are embedded within the file wrapper, but each PRI, as well as the job ticket file, is stored separately and accessed indirectly through a file reference within the wrapper.
Job tickets generally include information relating to attributes that characterize a document job.
Specifically, the job ticket 32 encodes those job attributes that are required to enable the reprint. of a saved print job.
The attributes typically include job :Level attributes (e. g.
set quantity, copy count, finishing requirements and plex) and page level attributes (e.g. stock information). The present invention uses the Adobe Portable Document Format (PDF) 1.3 specification to create a PDF file (i.e. the saved __g__ job file wrapper 38) that organizes the various elements of a saved print job, namely the job programming (i..e. the job ticket 32), the display resolution images (DRI) 36 and the print resolution images (PRI) 34. As described in detail below, the PDF wrapper 38 includes a number of private PDF
tags which are primarily used to locate the job programming file 32 and the PRIs 34 that are stored at the DFE 22 and external to the PDF wrapper 38. On the other hand, the DRIs 36 are embedded within the PDF wrapper. 38 and conform to the PDF 1.3 specification. The PDF wrapper 38 is embedded with private data through the use of second-class name extensions ( i . a . the private PDF tags ) that have been registered with the Adobe PDF Name Registry. Second-class names are prefix strings to keys that are assigned to individual companies .
The present assignee of the present invention has registered the second-class prefix string AXERX~ with Adobe. All PDF
readers that support PDF versions beyond 1.0, will ignore such private data.
There are a number of advantages associated with referencing the PRIs 34 within the PDF wrapper 38, such as i) large PRI files are not accessed when the PDF wrapper 38 is either viewed or edited at the UI 24 of the DFE 22, and ii) the PRI files are not transmitted through the network 16 if the saved print job is viewed at a workstation 12. The cost associated with referencing the PRI files in the PDF wrapper 38 is that a relationship must be e:>tablished between the location of the PDF wrapper 38 and the PRI images 34 to prevent lost or stale references. This is a concern where archival to and retrieval from removable media and page insertion capabilities are required.
Likewise, there are a number of advantages associated with embedding the DRIs 36 within the PDF wrapper 38, such as when viewing the saved print job remotely (i.e.
at a workstation 12), only the PDF wrapper 38 with the embedded DRIs 36 must be uploaded. Otherwise, the PDF
wrapper 38 and potentially tens or hundreds of DRIs would need to be uploaded individually making remote viewing inconvenient. In addition, there are no lost or stale file references with embedded DRIB. A cost associated with embedding DRIs in the file wrapper 38 is that the PDF wrapper along with the embedded DRIs may potentially become large.
It is contemplated that a fairly <aggressive compression scheme can be employed to reduce the size of the DRI. Since the wrapper is a PDF file, it is necessary to employ a compression scheme for the DRIB that is supported by PDF.
When a print job is to be saved, the job is submitted to the DFE 22 with a disposition of Save. The job typically consists of a Page Description Language PDL file along with the associated job programming. The DFE 22 is programmed to decompose the PDL file and create a PR:L and DRI for each page of the print job. Concurrently, the DFE 22 r_reates and updates the PDF wrapper 38 as each page of the print job is decomposed. The PDF wrapper 38 is embedded with t:he DRIs and with Private PDF tags (i.e. pointers) that indicate the location of the PRI files. Once the last page of the print job is decomposed, the job programming will be stored in a job ticket file 32 and the PDF wrapper 38 updated with Private PDF tags to point to the job ticket file 32. Once constructed, the PDF wrapper 38 conforms to the Adobe PDF 1.3 specification. Since the PRIs 34 are stored external to the PDF wrapper 38, the PDF wrapper 38 is compact relative to the size of the PRIs.
Thus, any third-party viewer that conforms to the Adobe PDF 1.3 specification (such as Adobe Acrobat Reader) will be capable of viewing the DRIB 36 embedded in the PDF
wrapper 38. The viewer may reside on any platform that has access to the PDF wrapper 38. This includes i) the UI 24 associated with the DFE 22, ii) a workstation platform 12 with a network connection to the DFE 22 using a communication protocol such as Network File Syst=em (NFS), FTP (File Transfer Protocol), Hyper Text Transfer Protocol (HTTP), etc, or iii) a platform connected to a portable media (for instance, a CD) to which the PDF wrapper 38 was copied to when previously mounted on the DFE 22. Note that in (ii) and (iii) above, access to the large PRI files 34 is not required. The PDF wrapper that is constructed with Xerox Private PDF tags (i.e. second-class names with the prefix "XERX") includes a small distinguishing stamp image superimposed on each DRI image at a non-intrusive location (i.e. in a corner of the displayed image). Upon viewing such a stamp image, the PDF wrapper 28 will be identifiable as a PDF wrapper file.
Further, any third-party editor that conforms to the Adobe PDF 1.3 specification (such as Adobe Acrobat Exchanger"') will be capable of re-ordering the DRIB, deleting the DRIB, and/or inserting DRIB from another job. The editor may reside on any platform listed above and, once again, direct access to the PRTs is not necessary_ Although it is the DRIs that are being rearranged by the editor, the PDF
specific tags associated with the DRIs that point to the corresponding PRI move with the DRIB. This is in accordance with the Adobe PDF 1.3 specifications. In particular, an editor is required to move tags it does not understand along with the page. Thus when an edited PDF wrapper 38 is submitted to the DFE 22 through the normal submission mechanisms, the PRIs 34 will print in the same order as the newly ordered DRIs 36. In addition to editing the DRIB 36 of the saved job, a PDF plug-in described below provides the capability of editing the job programming file 32 of the saved job.
The previously saved job may be submitted for a reprint at some later time using any of the usual submission mechanisms. The DFE 22 will recognize the Private PDF tags in the PDF wrapper 38 and, rather than decomposing the DRIB
36 within the PDF wrapper 38, it will locate the PRI 34 associated with each DRI 36 and submit it to the marking engine 20. Since no decomposition is required, it will result in a fast reprint at the engine speed of the IOT 20.
Further, the DFE 22 also locates the associated job programming file (i.e. job ticket file 32) and applies the programming to the job.
As is well known in the art, the Portable Document Format (PDF) provides a file structure that represents a document. The current PDF specification by Adobe Systems Incorporated is entitled Portable Document Format Reference Manual, Version 1.3, March 11, 1999 (IBSN 0-201-62628-4).
The PDF file structure provides a way to rapidly access any part of a document, and a mechanism for updating it. With reference now to Figure 4, a standard PDF file 40 consists of four sections: a one-line header 42, a body 44, a cross-reference table 46, and a trailer 48. A PDF document can be described as a hierarchy of objects contained in the body section 44 of the PDF file 40. Most objects in this hierarchy are dictionaries.
Parents, child, and sibling relationships are represented by key-value pairs whose values are indirect references to parent, child, or siuii:~g objeci.s. Fog example, the Catalog object, which is the root of the hierarchy, contains a Pages key whose value is an indirect reference to the object that is the root of the Pages tree. Comments can appear anywhere in the body section of a PDF file. Comments have the same syntax as those in the PostScript language; they begin with a A~= character and may start at any point on a line.
With continued reference to Figure 4, the one-line header section 42 of a PDF file specifies the version number of the PDF specification to which the file adheres. The Body section 44 of a PDF file consists of a sequence of PDF
objects that collectively represent a PDF document. More particularly, the objects represent components of the document such as fonts, pages, and sampled images. The Cross-reference section (i.e. table) _46 contains information that permits random access to indirect objects in the file, so that the entire file need not be read to locate any particular object. For each indirect object in the file, the table contains a one-line entry describing the location of the object in the file. A PDF file contains one cross-reference table, consisting of one or more sections. If no updates have been appended to the file, the cross-reference table contains a single section. One section is added each time updates are appended to the fila_. The Cross-reference section is the only part of a PDF file with a fixed format.
This permits random access to entries in the cross-reference table. The Cross-reference section begins with a line containing the keyword xref, followed by one or more cross reference subsections.
The Trailer section 48 of a PDF document enables an application reading a PDF file to quickly find the Cross-reference table and certain special objects. Applications typically read a PDF file from its end. The last line of a PDF file contains only the end-of-file marker, ~~EOF. The two preceding lines contain the keyword startxref and the byte offset from the beginning of the file to the beginning of the word xref in the last Cross-reference section in the file. The Trailer dictionary precedes this line. The Trailer dictionary, consists of the keyword trailer followed by a set of key-value pairs enclosed in double angle brackets. The trailer keyword specifies the location of the Catalog object as the value of the trailer=s Root key. In addition, the trailer specifies t:he location of the document=s Info dictionary, a structure that contains general information about the document, as the value of the trailer=s Info key .
The Catalog object is a diet=ionary that is the root node of the document. It contains a reference to the tree of pages contained in the document, a reference to the tree of objects representing the document=s outline, a reference to the document=s article threads, and the list of named destinations. In addition, the Catalog indicates whether the document=s outline or thumbnail page images should be displayed automatically when the document is viewed and whether some location other than the first page should be shown when the document is opened.
Figure 5 shows the logical document structure of a PDF file that may be used as a saved FRF j ob wrapper 3 8 .
Also, an exemplary PDF saved job wrapper is shown in the Appendix A that illustrates the construction and organization of the PDF objects described below. At the root of the FRF
job wrapper 38 is an object of type/Catalog 50 that includes an indirect reference to the root of the Pages Tree 52 as well as a reference to a file that contains the saved job programming (i.e. the job ticket 32). The Pages Tree 52 is not an object per se but represents either a single object or an hierarchical tree of objects of type/Pages. Objects of the type/Page 54a, 54n form the leaf nodes of the /Pages objects.
Page attributes that are not specified in the /Page object are inherited from the parent/Pages objer_t. On the other hand, if the same attribute is specified in both the /Pages and /Page objects, the value of the attribute in the /Page object overrides the value in the parent/Pages object.
This inheritance property is useful in organizing the pages according to the attributes they share through their ancestral /Pages objects.
Each /Page object contains an indirect reference to an object of type/Contents 56 that describes the imaging content of that page. The /Contents object typically requires resource objects in order to successfully image the page. For the fast reprint format (FRF) of the present __15__ invention, there are primarily two resource objects that will be used, namely an object of type /XObject and subtype/Image 58, and a Private PDF object of type /XERX XObject and subtype /XERX_PrintImage 60. The object /XObject 58 describes the attributes of the DRI 36 and includes the DRI
data as well. The object /XERX XObject 60 is equivalent to the object /XObject but encodes private data and references the PRI image data 34 in an external file through a dictionary /XERX FileAttr (discussed below).
Finally, there is an object of type /Info 62 that provides information about the document. This object is not part of the hierarchy outlined above but along with the /Catalog object 50 is accessed through a trailer dictionary located at the trailing end of the PDF file.
What follows is a discussion of the contents of key PDF objects that are required for the FRF file wrapper 58 of the present invention. The /Info object 62 contains a dictionary of the key-value pairs set forth in Table 1.
Table 1: Key-Value pairs for the /Info object in the trailer dictionary Key Type Value /Author Text Set to name of job submitter /CreationDate Date Date (and time) of creation of the saved job wrapper.
/Producer Text Product Name /Title Text I Set to name of the document The key-value pairs set forth in Table 2 are included in the root object of type /C.'atalog 50.
Table 2: Key-Value pairs for the root object of type/Catalog Key Type Value /Type name /Catalog /Pages dictionary Indirect. reference to the root of the ;Pages tree.
/XERX JobTicket stream Indirect. reference to Job Ticket stream. See below.
The dictionary associated with the Job Ticket stream object 32 contains the key-value pairs set forth in Table 3.
Table 3: Key-Value pairs for the dictionary associated with the /XERX JobTicket ~ctream Key Type Value /Type name /XERX JobTicket /XERX FileAttr Xerox File Attributes of the Job Ticket attributes file. See below.
/Length Integer 0 Each /XERX FileAttr dictionary that encodes the location of the Job Ticket file contains the key-value pairs set forth in Table 4.
__1~__ Table 4: Key-Value pairs for the /XERX FileAttr dictionary for the Job Ticket file Key Type Value /XERX_F Array of 1st element: Relative path name of the strings job ticket file 2nd element: Full path name of the job ticket file /XERX_FileSi Integer File size in bytes.
ze /XERX_VolNum Integer Volume number on which file resides.
Default value is 1 if missing.
Each /Page object 54 dictionary contains the key-value pairs set forth in Table 5.
Table 5: Key-Value pairs that are either included or inherited for the /Paqe object dictionarv Key Type Value /Type Name /Page /Parent Dictionar Indirect reference to the Parent y object.
/Resources Dictionar See below.
Y
/MediaBox Array [O,O,x,y): Size of the image dimensions expressed in points (1 point = 1/72") where x and y a:re the dimensions in the slow-scan and fast-scan directions, respectively.
/Contents Stream See below.
__1g__ Each /Resources dictionary contains the key-value pairs set forth in Table 6.
Table 6: Key-Value pairs that are either included or inherited for the /Resources dictionary Key Type Value /Xobject Dictionar If DRI is present:
y /DRI <stream object number> .
Stream object encodes DRI data. See below.
If DRI is absent:
/AbsentDRI <stream object number> .
Stream object encodes AAbsent DRI-message. See below /XERX Xobjec Dictionar /PRI <stream object number> .
t y Stream object encodes PRI image data.
See below.
/ProcSet Array Procedure Sets required for imaging the page.
It should be noted that the <stream object number>
is a variable that denotes an indirect reference to a stream object.
The user has the option of suppressing the generation of DRIB when submitting the job for save. In this case, it is necessary to indicate to the user that a DRI is not available for the page or pager selected. This is addressed further below.
Each DRI stream contains the key-value pairs set forth in Table 7.
Table 7: Key-Value pairs for the dictionary associated with the /XObject stream 58 Key Type Yalue /Type name /Xobj ect /Subtype name /Image /Width Integer Number of pixels in the slow scan direction.
/Height Integer Number of pixels .in the fast scan direction.
/BitsPerComponent Integer Number of bits per component =
/ColorSpace name Color space in which the DRI
is created. For most printers, likely to be /Device CMYK.
/Filter name The cornpression scheme adopted to compress the DRI
data. /DCTDecode /DecodeParms dictionary If required.
/Length Integer Length in bytes of the stream data.
In the case where DRIB are not created for a job, rather than including the image data for a DRI, this object will include the data of a universal image that indicates that a DRI is Aabsent- or Aunavaila.ble- for that page.
Typically, the image data file will be installed at the DFE
22, and included in the PDF wrapper 38 for a job where the user has choosen to suppress DRI generation..
The advantage of this approach to indicating an absent DRI is that the PDF reader or editor is not required to support any fonts at all in order to view or edit the FRF
job. The cost of this approach i.s the greater effort required to build and install the Aabsent DRI- image and, if no universal symbol exists for Aabsent- or Aunavailable-, multiple images may need to be constructed and the appropriate image included in the localized language packages. Only one /XObject containing the image data for an Aabsent DRI- is constructed in the PDF wrapper 38. The /Contents object 56 of any page that has no associated DRI
will make an indirect reference to this /XObject. Thus the image data for an Aabsent DRI- will be included in a PDF
wrapper file only once.
The dictionary associated with each PRI image stream contains the key-value pairs set forth in Table 8.
Table 8: Key-Value pairs for the dictionary associated with the /XERX XOb~ect stream 60 Key Type Value /Type Name /XERX XObject /SubType Name /XERX-PrintImage /XERFileAttr Xerox Attributes of the Xerox Print Image File file.
attribute See below.
s /Length Integer 0 Each /XERX-FileAttr dictionary that encodes the location of the PRI image files contains the key-value pairs set forth in Table 9.
Table 9: Key-Value pairs for the /XERX_FileAttr dictionary for the PRI image files Key Type Value /XERX_F Array of 1st element: Relative path name of the strings PRI file.
2nd element: Full path name of the PRI
file.
/XERX FileSi Integer File size in bytes.
ze /XERX VolNum Integer Volume number o:n which file resides.
Default value is 1 if missing.
The first element of the key /XERX_F provides the relative path name of the image file, whereas the second element provides an alternative (in this case absolute) search path for the image file. When a job is submitted for fast reprint, the DFE 22 will first attempt to find the image using the relative path name. If this fails, it will attempt to find the image using the absolute path name. If this fails as well, an AUnable to resolve file reference-fault will be raised. In the preferred embodiment only two path names to the PRI file are necessary. However, the array of strings associated with the key /XERX_F may include as may elements as desired. In this case, the DFE 22 would attempt to find the PRI file at the locations specified in the array starting at the first element and continuing along the array until it finds the desired PRI file.
The attributes and content of the /Contents stream object are as follows: the dictionary associated with the /Contents stream consists of an entry corresponding to the specification of the length of the stream using the key /Length. The /Contents object stream of a /Page object that has an associated DRI is constructed as follows: i) the stream begins and ends with the PDF operators Aq= and AQ-that store and restore the current graphics state. If necessary, a concatenation matrix will be included next. The concatenation matrix operator is described subsequently. The PDF operator ADo- will execute an operand that is a named image. This named image is identica7_ to the image name in the object of type /XObject.
With reference now to Figure 6, once a print job has been saved, such as being stored on a save disk 70 associated with the DFE 22, a PDF reader tool may be used to view the DRIB of the saved job and navigate through the pages of the job. In addition to Job View, modifications of the saved job may be made through the use of a PDF editor tool 72. In particular, a PDF editor tool 72 provides the capability to re-order and delete pages in a single job.
Note that although it is the ordering of the DRIB that is being changed, the printed output of the modified saved job will reflect the new page order since the PDF file will be created in such a fashion that the reference to the associated PRI image will always move with the DRI. Note that this functionality is supported by Acrobat Exchange.
Further, the PDF editor provides the capability to open multiple jobs and insert the pages from one job into another. Once again, although it is the DRIs that are being inserted, the corresponding references to the PRI images are inserted as well and continue to be associated with the inserted DRIB. Note that this functionality is also supported by Acrobat Exchange.
An enhancement to the basic PDF editor functionality is provided by a Job 'picket Plug-in 74 that interprets the referenced job ticket 32, and displays as well as allows modification of the j ob programming attributes .
That is, the PDF plug-in 74, associated with the DFE 22, is capable of recognizing the Private PDF tags that are embedded within the PDF wrapper 38. The plug-in has the capability to locate and decode the contents of the=_ j ob programming file (i.e. job ticket 32) and graphically display the job programming of the saved job. It should be noted that without a Job Ticket Plug-in 32, the associated job ticket will not be updated. Thus, it would be up to the user to change the job programming when submitting the edited FRF job for reprint.
The advantages of using PDF as the saved job wrapper are more evident when remote (i.e. at a location other than the UI 24 of the DFE 22) job viewing and editing workflow is considered, as shown in Figure 7. A browser at a client workstation 12 uploads the necessary saved job wrappers 38 along with the associated job ticket files 32 from the save repository 70 at the DFE 22 to the local client workstation disk 76 using the ASave As- option in the browser. Thus, in order to view both the images and the job programming information, a remote viewer is required to upload both the saved job wrapper and the job ticket file.
It is necessary for the user to save the wrapper 38 and the associated job ticket file 32 in the same folder or directory, and furthermore the job ticket file should not be renamed. These restrictions are necessary so that the reference to the job ticket file from the saved job wrapper is valid. Alternatively, if the cl=ient has Network File System (NFS) access to the save repository 70, the saved job wrapper 38 may be accessed directly. The DFE '~2 supports saving jobs to multiple locations including, for example, the local controller disks) 70, an NFS mounted disk, and other portable disks connected to the controller through a SCSI
connection. However, saving jobs as they are being created on disks other than the local controller disk 70 is subject to likely performance degradation due to I/O bandwidth limitations.
Once the necessary files are available at the client workstation 12, the PDF editor 72 with the plug-in 74 (the appropriately ported version for the client workstation platform) or a third party tool for viewing and editing may be used in much the same fashion as at the UI 24 associated with the DFE 22. Once any editing on the uploaded jobs has been completed, there are a number of ways in which the modified jobs can be transferred back to the DFE 22 as discussed below. In all cases, the DFE 22 matches the DRI 36 in the saved job with the correct PRI image data 34.
One strategy for transferring a modified job back to the DFE 22 is to copy the modified job over to removable media 78 (Fig. 7) attached initially to the client workstation. The media may then be removed and mounted at the DFE 22 and the modified saved job copied over to the save repository 70 at the DFE 22. The modified job may then be submitted for reprint either at the DFE 22 or at any one of the client workstations 12. Note that the modified saved job may be placed anywhere in the save repository 70 and not necessarily replace the original saved job. Further, the modified saved job need not necessarily be copied to the save repository, but may be printed directly from the removable media although this is likely to cause performance degradation.
Although the above provides a mechanism to transfer a modified saved job back to the save repository 70, it is not very convenient for the user at a client workstation. An easier workflow may involve an HTTP download to the controller (i.e. DFE 22) as described in detail below with regard to a further embodiment of the present invention.
However, this requires some level of an authent_i.cation and authorization mechanism at the DFE 22. In the absence of an HTTP download, the modified saved job may be submitted for printing through a job submission tool 80 at the client workstation 12 and will be treated no differently than any other job. This workflow is different: than HTTP download in two respects: i) a new job ticket, based on the contents of the uploaded saved job ticket, may need to be constructed and submitted through the normal Internet Printing Protocol (IPP) channels, and ii) the modified saved job will be deleted once it completes printing successfully.
It is conceivable that the user at the client workstation may upload a saved job from one DFE and insert it into an uploaded saved job from another DFE. If the two DFEs do not share a common repository, a modified saved job that contains images form both DFEs will fault when submitted for reprint at either of the two DFEs. In this case, it is necessary to copy the required saved jobs from one DFE to the other before attempting to upload the saved jobs for editing and subsequent job submission.
If so desired, the PDF wrapper file may be submitted for print to any Acheaper- or Anon-targetecL
printer that supports PDF as the input PDL type. Since the wrapper is a legitimate PDF file that contains the low resolution DRIB, this will result in a Alow-cost. draft print of the contents of the FRF job.
The rendering data within the PRIs is generally calculated based on the knowledge of the rendering characteristics of the attached Image Output Terminal (IOT).
Thus, the PRIs 34 created for one DFE-IOT (22, 18) combination may not either print at a.11, or may print with poorer image quality, on another DFE-IOT combination.
However, the DRI 36 format is kept independent of the DFE-IOT
combination and, as mentioned above, is a format that conforms with the Adobe PDF Specification 1.3.
In order to solve this problem, it is contemplated that when a print job is submitted to a DFE with the disposition of Save, the DFE will decompose the PDL file creating the PRI and DRI for each page. Concurrently, the DFE will create and update the PDF wrapper as each page is decomposed. The PDF wrapper will embed the DRI and include the PDF-private tags that indicate the location of the PRI
file. Each PRI file can also include information that indicates the particular DFE-IOT combination for which the PRI file is targeted. One the last page is decomposed, the job programming will be stored in a job ticket file and the PDF wrapper updated with PDF-private tags to point to the job ticket file.
When viewing the saved job, the PDF plug-in module will have the capability to locate and decode the contents of the job programming file and graphically display the job programming of the saved j ob as well as the target DFE-IOT
combination. When editing a saved job, if an attempt is made to insert pages from a PDF wrapper that is targeted to a first DFE-IOT combination, into a PDF wrapper that is targeted to a second DFE-IOT combination, the PDF plug-in module will post an error message and prohibit this operation.
When submitting a saved job for fast reprint, the targeted DFE will recognize the PDF-specific tags in the PDF
wrapper and, rather than decompose the DRIB within the PDF
wrapper, it will locate the PRI associated with each DRI.
The DFE will first determine if the target DFE-IOT
combination stored within the PRI is the same as the DFE-IOT
combination that the PDF wrapper was submitted to. If affirmative, the PRI is submitted to the marking engine.
Since no decomposition is required, it will result in a fast reprint. Further the DFE will also locate the associated job programming f i 1e and apply the programming to the j ob . I f not, the DFE will fault the job and indicate the DFE-IOT
combination that the PRI is targeted f:or.
-_2~__ In the case where a print job is submitted to the DFE 22 from a web-based client workstation such as one of the workstations 12 of Figure 1, the web-based end-user would submit a job through a secure channel established with the web server 26 (Figure 1). The web server authenticates the end-user, determines if a valid account exists, c:ommunicates with a print server that then forwards the job to the appropriate DFE-IOT combination based on the job programming requested. Once the job is successfully saved on a repository (e. g. save repository 70, the print server notifies the end-user that the job is ready for a soft proof.
Thereafter, the user subsequently connects with the print server, is authenticated once again and given authorization to access only those saved jobs that resulted from previous job submissions from that end-user=s account. The end-user is then able to soft proof the job (i.e. view the DRIB
embedded within the PDF wrapper 38 and the view the job programming stored in the Job Ticket file 32) to verify that the job was constructed per the submitted job programming.
The end-user also has the option to download a private copy of the saved job, manipulate it by deleting pages, re-ordering pages, inserting pages from another saved j ob, and change some j ob programming parameters and veri fy the effects of these modifications. The end-user may then either submit the modified private copy of the saved job for one or more hard copies, or instruct. the print server to print one or more hard copies of the original saved job. An appropriate business model can be used. to deliver the copies to the user. The end-user also has the option of keeping the saved jobs on the repositories and is billed for this service accordingly. The end-user has the option to request hard copies of the saved job at a subsequent time and is guaranteed to obtain hard copies that. are identical within acceptable tolerance of the first set of hard copies requested.
--2g--Note that some enhancements to the existing platform capabilities would be neces:~ary to implement this web-based client-server model. For instance, the architecture that enables the associated workflow consists of a Hypertext Transfer Protocol (HTTP) server 26 that supports a security protocol such as the Secure Socket Layer (SSL) technology. This server is responsible for communication with the web-based clients of a print shop (e. g. the place where the document processing apparatus 14 is located). The HTTP server communicates with a print server (such as a PrintXchange$ print server) that manages and controls one or more DFEs which are connected to IOTs. The HTTP and print servers and the DFEs are networked (such as by Network File System protocol) to a saved job repository (such as repository 70).
It should be appreciated that the above description of the components is a logical, not physical, view. In all likelihood, the HTTP and print server will reside on the same hardware platform. In the case where a print shop has only one DFE, all three software components, namely, the HTTP
server, print server and the DFE may reside on only one hardware platform such as the document processing apparatus 14 of Figure 1.
In order to initiate a transaction from a web-based client workstation, an end-user uses a browser to connect to a Uniform Resource Locator (URL) addre=~s that makes available the web-based client submission software and PDF Job Ticket Plug-in software. Further, the customer must have a PDF
editor application loaded on the client: platform as well. It is also possible that the print shop may also make these software components available to the customer as well. The customer also establishes an account and obtains the necessary ID and password from the print shop.
When submitting a print job for Save using the web-based submission client, the end-user enters the account ID
and password and submits a job to the HTTP server 26 at the print shop over a secure connection, such as b:y using the Secure Socket Layer (SSL) technology. The job typically consists of a Page Description Language (PDL) file along with the associated job programming. The HTTP server authenticates the user and communicates with the print server that then forwards the job to the appropriate DFE, based on the job programming requested which may include a specification of the intended DFE-IOT target such as DFE-IOT
22, 14. The DFE 22 decomposes the PDL file and creates a DRI
36 and PRI 34 for each page. Concurrently, the DFE 22 creates and updates a PDF wrapper 38 as each page is decomposed, the job programming will be encoded and included within the PDF wrapper 38 along with Private PDF tags pointing to the location of the job programming within the PDF wrapper.
Upon executing some bookkeeping tasks, the PDF
wrapper 38 will be completed. The PDF wrapper 38 so constructed will conform to the latest Adobe PDF
specifications. Note that since the PRIs 34 are stored external to the PDF wrapper 38, the PDF wrapper 38 is compact relative to the size of the PRIs 36. The PDF wrapper 38 and the associated set of PRIs 34 form the saved job and is stored on the save repository 70. Once the save operation is completed, the DFE 22 notifies the Print Server which, through the HTTP server, notifies the end-user that the saved job is ready for soft-proofing.
Upon receiving the notification, the end-user connects with the HTTP server 26 and enters the ID and password. The HTTP server 26 once again authenticates the user and displays a list of saved jobs that the user with the specified ID is authorized to view. This list contains only the PDF wrappers 38 but not the associated PRIs. The end-user then selects the appropriate PDF' wrapper to view ( the PDF wrapper is named after the name c>f the PDL file in the originally submitted job). The end-user chooses to download the file and launches the PDF editor application (which also serves as a viewer) with the PDF Plug-in 74, to view the saved job. Note that only the relatively compact PDF wrapper is downloaded, but the large PRIs will continue to remain on the save repository 70 at the print shop. In fact, the latter are never authorized for access to the end-user. The PDF reader displays the DRIB 36 within the PDF wrapper 38 and, because of the PDF Job Ticket Plug-in 74, the effects of certain job programming will also be observable such as horizontal and vertical image shift, inserts, chapter starts, positioning of the staples/stitching and tumble.
As with the previous embodiments, there are a limited number of editing operations that a user may perform on the saved job through manipulation of the PDF wrapper.
These are page-level editing, such as page re-order, page deletion, and inserting pages from another of the end user=s saved job archived at the print shop. This is achieved through the operations that are available through the PDF
editor application. Although it is the DRIs that are being re-arranged by the editor, the Private PDF tags associated with the DRIB 36 that point to the corresponding PRI 34 will move with the DRIs 36. In addition, the Job Ticket Plug-in 74 allows the end-user to change job programming parameters (restricted to only those that are not related to rendering) - this list includes finishing options, stock size, plex, tumble, inserts, chapter starts, horizontal and vertical image shifts.
The PDF editor application with the Job Ticket Plug-in displays to the end-user the <=ffects of any changes in the job programming parameters. Once the end-user is satisfied with the soft-proof of the changes made, the end user may submit the PDF wrapper file, through the web-based submission client to the print shop HTTP server 26. Although the mechanism for submission remains the same as that for submission of a print job with the disposition of Save, the DFE 22, when it eventually receives the job, recognizes the Private PDF tags and the existence o:f the associated PRIs, and will not attempt to decompose the PDF wrapper. Although another PDF wrapper is created that is destined for the save repository 70, it is largely similar to the submitted PDF
wrapper; the latter is deleted when the job is complete. The DFE will not create any PRIs because all the PRIs referenced within the submitted PDF wrapper will already exist in the Save Repository.
If the soft-proof meets approval, the end-user connects with the HTTP server 26, and after the above-described authentication and authorization process, request the printing of a certain number of hard copies of selected PDF wrapper file(s). Associated information such as delivery options are also provided. The HTTP server 26 forwards the print request to the print server, and the print server in turn forwards the request to an available DFE-IOT
combination. The important restriction is that the DFE-IOT
combination cannot be different than the one on which the saved job was originally created. Once successfully delivered, an appropriate billing model is used to bill or debit the end-users account.
The end-user may choose to delete the saved jobs or may choose to archive them at the print shop in the event that additional copies are required in the future. The print shop is expected to implement a billing model based on size and length of the saved jobs and possibly other parameters and debit or bill the end-user=s account accordingly. If the end user has chosen to archive the saved jobs at the print shop, hard copies of any of the end user=s saved job may be requested at some subsequent time by following the process outlined above for requesting printing of a saved job upon soft approval. Since no re-decomposition takes place on a reprint and the PRIs are in printer-ready format, the printed output at any subsequent time will be of the same quality as the first hard copy print requested within the DFE-IOTs tolerance specifications.
Lastly, local copies of the PDF wrappers 38 may also be archived at the end-user=s workstation 12. This allows the end-user to view or edit the files at some subsequent time without having to connect with the print shop=s HTTP server. In addition, the end-user may also choose to print a draft mode print of the PDF wrappers on a locally available, non-targeted printer. When the PDF
wrapper is submitted to this printer, it will not recognize the Private PDF tags and will decompose the lower-resolution DRIs in the PDF wrapper. This results in what is considered to be a draft-mode print.
The invention has been described with reference to the preferred embodiments. Obviously, modifications and alterations will occur to others upon reading and understanding the preceding detailed description. It is intended that the invention be construed as including all such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.
For instance, it is recognized that when the save repository is backed-up or archived to a mass storage unit such as a tape drive unit, it is more expedient to transfer the files that comprise the stored print job (i.e. file wrapper, job ticket file, PRIs), as a single file or data stream rather than transfer the files separately.
Accordingly it is contemplated that the PRIs and/or the job ticket file can be embedded within th.e file wrapper by the DFE prior to being archived.
APPENDIX A
$PDF-1.3 ~ This file is an example of how a PDF wrapper file for a Fast Reprint Format saved job may be created.
The contents of the file do not necessarily reflect the actual contents of the PDF wrapper file, nor does it mandate any ~ specific order of encoding of the PDF objects.
For demonstrative purposes, this file is a two-page file where a DRI is present for the first image and absent for the second image. However, typically, either all DRIs will be present for ~ the job or none at all when the PDF wrapper' file is created.
In order to conserve space, a small B&W image is used for $ the DRI, which is subsequently magnified.
This file is legitimate (conforms to PDF1.3) and is complete.
2 0 ~ It was tested with both Acrobat Reader/Exch.ange 3.0 and 4Ø
~ The Information Object 2 5 1 0 obj /Author (adegani) /CreationDate (D:20000501150000-05'00') /Producer (Xerox Product Name) 3 0 /Title (example.ps) endobj ~ In this example, the first page is assumed to contain a DRI.
$ The Page object.
2 0 obj
d) embedding in the wrapper file pointers to the location of the print resolution image data;
e) storing attribute data for the print job in the job ticket file;
f) embedding pointers to the location of the job ticket file in the wrapper file; and g) storing the wrapper file, the job ticket file, and the print resolution image data on a save repository.
One advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file wrapper so that when printing a saved job, submission of the PDF file wrapper through existing submission mechanisms results in a digital front end associated with a document processing apparatus recognizing Private PDF tags embedded in the PDF wrapper, acting upon job programming instructions in an associated job ticket file, and printing associated print resolution images of the saved job.
Another advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file wrapper so that when viewing a saved job, any existing application (such as Adobe Acrobat ReaderT"') may be used to view the display resolution images that are embedded within the PDF file wrapper on any networked platform, including a digital front end associated with a document processing device.
Yet another advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file wrapper so that when editing a saved job, any existing application (such as Adobe Acrobat Exchanger"") may be used to re-order or delete pages of a job, or insert pages from one job into another on any networked platform, including a digital front end associated with a document processing device.
3a A further advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file wrapper so that when the edited job is submitted for print, the print resolution image files associated with the PDF file wrapper will print in the same order as the display resolution images that are embedded within the PDF file wrapper.
__g__ A further advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file wrapper so that the PDF
wrapper file may be submitted to a alternate printer resulting in a draft-mode print of the display resolution images that are embedded within the PDF file wrapper.
A still further advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file wrapper that provides the capability to access page and image data on demand and in any order.
Still further advantages of the present invention will become apparent to those of ordinary skill in the art upon reading and understanding the following detailed description of the preferred embodiments.
Brief Description of the Drawings The invention may take form in various components and arrangements of components, and in various steps and arrangements of steps. The drawings are only for purposes of illustrating a preferred embodiments) and are not to be construed as limiting the invention.
Figure 1 is a simplified block diagram of an exemplary network document processing system that incorporates the features of the present invention therein;
Figure 2 is a schematic representation of the Fast Reprint Format (FRF) logical job stru~~ture according to the present invention;
Figure 3 is a schematic representation of the Fast Reprint Format (FRF) physical job structure according to the present invention;
Figure 4 is a schematic representation of an exemplary PDF file that has not been updated;
__5-_ Figure 5 is a schematic representation of the logical document structure and salient objects of a PDF saved job file wrapper according to the present invention;
Figure 6 is a schematic representation for workflows for job view and edit at the digital front end of a document processing apparatus according to the present invention; and Figure 7 is a schematic representation for possible workflows for job view and edit at a client workstation that is in communication with digital front end of a document processing apparatus according to the present invention.
Detailed Description of the Invention With reference now to Figure 1, there is shown an exemplary network document processing system 10 comprising a plurality of document processing units. In particular, document processing system 10 comprises one or more clients such as workstations 12-1, 12-2, 12-3, . . . 12-n, which may be on-site (e. g. LAN) and/or remote (e. g. WAN), and at least one document processing apparatus 14 that communicates with the workstations 12 through a network or communication channels 16. As will be appreciated, while only a limited number of document processing units are shown in Figure 1, the preferred embodiment contemplates the use of as many document processing units as are required to meet the demands of the users of the system.
Clients 12 provide the electronic documents that are the source of the print jobs and, for this purpose, individual ones or all of clients 12 may have a document scanner, disk input, keyboard, fax, etc. for generating the electronic documents that comprise the job to be printed.
Clients 12 each have a User Interface (UI) with interactive screen (not shown) enabling programming selections for documents or jobs to be made.
--6__ The document processing apparatus 14 can take the form of a multi-functional document processing device, for example, a color digital copier that includes an Image Input Terminal (IIT) 18 such as a document scanner, an Image Output Terminal (IOT) 20 such as a printer/marker, a digital front end (DFE) or controller 22 with a User Interface (UI) module 24. As described in detail with respect to a further embodiment of the present invention, the DFE 22 can include an HTTP/Print server 26. As is known in the art, the multi-functional document processing apparatus 14 can also include a facsimile module 28, if desired. The multi-functional document processing apparatus 14 is conventionally connected to the network 16 through a network port associated with the DFE 22.
As described in detail below, the DFE 22 is configured or otherwise programmed to facilitate i) reprinting a saved print job at the engine speed of the IOT
(i.e. reprint a saved job without requiring re-RIPping), ii) viewing thumbnails of the images of a saved print job, 20 and iii) re-ordering, deleting and/or inserting pages of a saved print job, at any of the client workstations 12 and/or the UI 24 associated with the DFE 22.
It should be appreciated that, given the limitations of currently available processing power, it is not possible to save raster image data in an industry standard format yet provide reprinting at engine speed. Fast reprint essentially requires no re-RIPping of a saved job, and further requires that the compressed image data be saved in such a manner that it can be consumed directly by hardware decompressor boards without any (potentially time-consuming and productivity degrading) conversion or manipulation of the image data.
Besides reprint performance, preserving the image quality of the saved print job is an equally important consideration in choosing a scheme that does not involve re-RIPping the job and using a compression format that preserves control information. Preserving this information ensures that reprints of the saved job will print identically within system tolerance. Conversion to an industry-standard format that does not support the encoding of all of the image and control data that are present in the proprietary format will result in loss of information that will manifest in poorer image quality of the reprints.
Briefly, in order to create images that can reprint at the engine speed of the IOT 20 with good image quality, a compressed image format, termed the print resolution image (PRI) format, is necessary. To construct a display image from the compressed image data (i.e. the PRI image data) at the point of demand (e.g. at any one of the workstations 12) is too time-consuming to be of any practical value. Thus, according to the present invention, display image data, termed a Display Resolution Image (DRI) data, is generated at the same time that the PRI data is generated. Generally, the size of the DRI data is considerably less than the corresponding PRI data (less than about. 1~). As used herein, the term ADisplay Resolution Image- or simply ADRI- refers to an image that is a lower resolution replica of a printer resolution image that is typically used for display on a monitor. Further, as used herein, the term APrint Resolution Image- or simply APRI- refers to an image file in which the image data are in a postRIP compressed format.
A schematic view of a print job that is saved according to the Fast Reprint Format (FRF) of present invention is shown in Figure 2, and the physical structure of the saved print job is shown in Figure 3. As used herein, the term AFast Reprint Format- or simply AFRF= refers to a __g__ format that specifies the encoding of job and image attributes in which the image data are in postRIP compressed form that may be consumed directly by the video path to the IOT. Further, the Fast Reprint Format also refers to a format that permits the use of existing third-party tools to perform various operations of saved print jobs and their contents, and to encapsulate the details of a saved print job file and image formats.
The saved print job is not a single file but a collection of files that is stored in a single container directory. The saved print job is not referenced by its components but by the name of the container directory 30.
There are four distinct components of a saved print job according to the present invention: i) a job ticket file 32 that describes the job programming of the saved print job (a job ticket file conventionally encodes those job attributes that are required to enable the reprint of a saved print job); ii) a set of images composed of print-ready (i.e.
postRIPed) compressed raster data (i.e. the PRIs) 34; iii) a corresponding set of display resolution images (DRI) 36; and iv) a saved job Afile wrapper- 38 that sequences the set of print-ready PRIs and DRIB and encodes their attributes. As described in detail below, the DRIB are embedded within the file wrapper, but each PRI, as well as the job ticket file, is stored separately and accessed indirectly through a file reference within the wrapper.
Job tickets generally include information relating to attributes that characterize a document job.
Specifically, the job ticket 32 encodes those job attributes that are required to enable the reprint. of a saved print job.
The attributes typically include job :Level attributes (e. g.
set quantity, copy count, finishing requirements and plex) and page level attributes (e.g. stock information). The present invention uses the Adobe Portable Document Format (PDF) 1.3 specification to create a PDF file (i.e. the saved __g__ job file wrapper 38) that organizes the various elements of a saved print job, namely the job programming (i..e. the job ticket 32), the display resolution images (DRI) 36 and the print resolution images (PRI) 34. As described in detail below, the PDF wrapper 38 includes a number of private PDF
tags which are primarily used to locate the job programming file 32 and the PRIs 34 that are stored at the DFE 22 and external to the PDF wrapper 38. On the other hand, the DRIs 36 are embedded within the PDF wrapper. 38 and conform to the PDF 1.3 specification. The PDF wrapper 38 is embedded with private data through the use of second-class name extensions ( i . a . the private PDF tags ) that have been registered with the Adobe PDF Name Registry. Second-class names are prefix strings to keys that are assigned to individual companies .
The present assignee of the present invention has registered the second-class prefix string AXERX~ with Adobe. All PDF
readers that support PDF versions beyond 1.0, will ignore such private data.
There are a number of advantages associated with referencing the PRIs 34 within the PDF wrapper 38, such as i) large PRI files are not accessed when the PDF wrapper 38 is either viewed or edited at the UI 24 of the DFE 22, and ii) the PRI files are not transmitted through the network 16 if the saved print job is viewed at a workstation 12. The cost associated with referencing the PRI files in the PDF wrapper 38 is that a relationship must be e:>tablished between the location of the PDF wrapper 38 and the PRI images 34 to prevent lost or stale references. This is a concern where archival to and retrieval from removable media and page insertion capabilities are required.
Likewise, there are a number of advantages associated with embedding the DRIs 36 within the PDF wrapper 38, such as when viewing the saved print job remotely (i.e.
at a workstation 12), only the PDF wrapper 38 with the embedded DRIs 36 must be uploaded. Otherwise, the PDF
wrapper 38 and potentially tens or hundreds of DRIs would need to be uploaded individually making remote viewing inconvenient. In addition, there are no lost or stale file references with embedded DRIB. A cost associated with embedding DRIs in the file wrapper 38 is that the PDF wrapper along with the embedded DRIs may potentially become large.
It is contemplated that a fairly <aggressive compression scheme can be employed to reduce the size of the DRI. Since the wrapper is a PDF file, it is necessary to employ a compression scheme for the DRIB that is supported by PDF.
When a print job is to be saved, the job is submitted to the DFE 22 with a disposition of Save. The job typically consists of a Page Description Language PDL file along with the associated job programming. The DFE 22 is programmed to decompose the PDL file and create a PR:L and DRI for each page of the print job. Concurrently, the DFE 22 r_reates and updates the PDF wrapper 38 as each page of the print job is decomposed. The PDF wrapper 38 is embedded with t:he DRIs and with Private PDF tags (i.e. pointers) that indicate the location of the PRI files. Once the last page of the print job is decomposed, the job programming will be stored in a job ticket file 32 and the PDF wrapper 38 updated with Private PDF tags to point to the job ticket file 32. Once constructed, the PDF wrapper 38 conforms to the Adobe PDF 1.3 specification. Since the PRIs 34 are stored external to the PDF wrapper 38, the PDF wrapper 38 is compact relative to the size of the PRIs.
Thus, any third-party viewer that conforms to the Adobe PDF 1.3 specification (such as Adobe Acrobat Reader) will be capable of viewing the DRIB 36 embedded in the PDF
wrapper 38. The viewer may reside on any platform that has access to the PDF wrapper 38. This includes i) the UI 24 associated with the DFE 22, ii) a workstation platform 12 with a network connection to the DFE 22 using a communication protocol such as Network File Syst=em (NFS), FTP (File Transfer Protocol), Hyper Text Transfer Protocol (HTTP), etc, or iii) a platform connected to a portable media (for instance, a CD) to which the PDF wrapper 38 was copied to when previously mounted on the DFE 22. Note that in (ii) and (iii) above, access to the large PRI files 34 is not required. The PDF wrapper that is constructed with Xerox Private PDF tags (i.e. second-class names with the prefix "XERX") includes a small distinguishing stamp image superimposed on each DRI image at a non-intrusive location (i.e. in a corner of the displayed image). Upon viewing such a stamp image, the PDF wrapper 28 will be identifiable as a PDF wrapper file.
Further, any third-party editor that conforms to the Adobe PDF 1.3 specification (such as Adobe Acrobat Exchanger"') will be capable of re-ordering the DRIB, deleting the DRIB, and/or inserting DRIB from another job. The editor may reside on any platform listed above and, once again, direct access to the PRTs is not necessary_ Although it is the DRIs that are being rearranged by the editor, the PDF
specific tags associated with the DRIs that point to the corresponding PRI move with the DRIB. This is in accordance with the Adobe PDF 1.3 specifications. In particular, an editor is required to move tags it does not understand along with the page. Thus when an edited PDF wrapper 38 is submitted to the DFE 22 through the normal submission mechanisms, the PRIs 34 will print in the same order as the newly ordered DRIs 36. In addition to editing the DRIB 36 of the saved job, a PDF plug-in described below provides the capability of editing the job programming file 32 of the saved job.
The previously saved job may be submitted for a reprint at some later time using any of the usual submission mechanisms. The DFE 22 will recognize the Private PDF tags in the PDF wrapper 38 and, rather than decomposing the DRIB
36 within the PDF wrapper 38, it will locate the PRI 34 associated with each DRI 36 and submit it to the marking engine 20. Since no decomposition is required, it will result in a fast reprint at the engine speed of the IOT 20.
Further, the DFE 22 also locates the associated job programming file (i.e. job ticket file 32) and applies the programming to the job.
As is well known in the art, the Portable Document Format (PDF) provides a file structure that represents a document. The current PDF specification by Adobe Systems Incorporated is entitled Portable Document Format Reference Manual, Version 1.3, March 11, 1999 (IBSN 0-201-62628-4).
The PDF file structure provides a way to rapidly access any part of a document, and a mechanism for updating it. With reference now to Figure 4, a standard PDF file 40 consists of four sections: a one-line header 42, a body 44, a cross-reference table 46, and a trailer 48. A PDF document can be described as a hierarchy of objects contained in the body section 44 of the PDF file 40. Most objects in this hierarchy are dictionaries.
Parents, child, and sibling relationships are represented by key-value pairs whose values are indirect references to parent, child, or siuii:~g objeci.s. Fog example, the Catalog object, which is the root of the hierarchy, contains a Pages key whose value is an indirect reference to the object that is the root of the Pages tree. Comments can appear anywhere in the body section of a PDF file. Comments have the same syntax as those in the PostScript language; they begin with a A~= character and may start at any point on a line.
With continued reference to Figure 4, the one-line header section 42 of a PDF file specifies the version number of the PDF specification to which the file adheres. The Body section 44 of a PDF file consists of a sequence of PDF
objects that collectively represent a PDF document. More particularly, the objects represent components of the document such as fonts, pages, and sampled images. The Cross-reference section (i.e. table) _46 contains information that permits random access to indirect objects in the file, so that the entire file need not be read to locate any particular object. For each indirect object in the file, the table contains a one-line entry describing the location of the object in the file. A PDF file contains one cross-reference table, consisting of one or more sections. If no updates have been appended to the file, the cross-reference table contains a single section. One section is added each time updates are appended to the fila_. The Cross-reference section is the only part of a PDF file with a fixed format.
This permits random access to entries in the cross-reference table. The Cross-reference section begins with a line containing the keyword xref, followed by one or more cross reference subsections.
The Trailer section 48 of a PDF document enables an application reading a PDF file to quickly find the Cross-reference table and certain special objects. Applications typically read a PDF file from its end. The last line of a PDF file contains only the end-of-file marker, ~~EOF. The two preceding lines contain the keyword startxref and the byte offset from the beginning of the file to the beginning of the word xref in the last Cross-reference section in the file. The Trailer dictionary precedes this line. The Trailer dictionary, consists of the keyword trailer followed by a set of key-value pairs enclosed in double angle brackets. The trailer keyword specifies the location of the Catalog object as the value of the trailer=s Root key. In addition, the trailer specifies t:he location of the document=s Info dictionary, a structure that contains general information about the document, as the value of the trailer=s Info key .
The Catalog object is a diet=ionary that is the root node of the document. It contains a reference to the tree of pages contained in the document, a reference to the tree of objects representing the document=s outline, a reference to the document=s article threads, and the list of named destinations. In addition, the Catalog indicates whether the document=s outline or thumbnail page images should be displayed automatically when the document is viewed and whether some location other than the first page should be shown when the document is opened.
Figure 5 shows the logical document structure of a PDF file that may be used as a saved FRF j ob wrapper 3 8 .
Also, an exemplary PDF saved job wrapper is shown in the Appendix A that illustrates the construction and organization of the PDF objects described below. At the root of the FRF
job wrapper 38 is an object of type/Catalog 50 that includes an indirect reference to the root of the Pages Tree 52 as well as a reference to a file that contains the saved job programming (i.e. the job ticket 32). The Pages Tree 52 is not an object per se but represents either a single object or an hierarchical tree of objects of type/Pages. Objects of the type/Page 54a, 54n form the leaf nodes of the /Pages objects.
Page attributes that are not specified in the /Page object are inherited from the parent/Pages objer_t. On the other hand, if the same attribute is specified in both the /Pages and /Page objects, the value of the attribute in the /Page object overrides the value in the parent/Pages object.
This inheritance property is useful in organizing the pages according to the attributes they share through their ancestral /Pages objects.
Each /Page object contains an indirect reference to an object of type/Contents 56 that describes the imaging content of that page. The /Contents object typically requires resource objects in order to successfully image the page. For the fast reprint format (FRF) of the present __15__ invention, there are primarily two resource objects that will be used, namely an object of type /XObject and subtype/Image 58, and a Private PDF object of type /XERX XObject and subtype /XERX_PrintImage 60. The object /XObject 58 describes the attributes of the DRI 36 and includes the DRI
data as well. The object /XERX XObject 60 is equivalent to the object /XObject but encodes private data and references the PRI image data 34 in an external file through a dictionary /XERX FileAttr (discussed below).
Finally, there is an object of type /Info 62 that provides information about the document. This object is not part of the hierarchy outlined above but along with the /Catalog object 50 is accessed through a trailer dictionary located at the trailing end of the PDF file.
What follows is a discussion of the contents of key PDF objects that are required for the FRF file wrapper 58 of the present invention. The /Info object 62 contains a dictionary of the key-value pairs set forth in Table 1.
Table 1: Key-Value pairs for the /Info object in the trailer dictionary Key Type Value /Author Text Set to name of job submitter /CreationDate Date Date (and time) of creation of the saved job wrapper.
/Producer Text Product Name /Title Text I Set to name of the document The key-value pairs set forth in Table 2 are included in the root object of type /C.'atalog 50.
Table 2: Key-Value pairs for the root object of type/Catalog Key Type Value /Type name /Catalog /Pages dictionary Indirect. reference to the root of the ;Pages tree.
/XERX JobTicket stream Indirect. reference to Job Ticket stream. See below.
The dictionary associated with the Job Ticket stream object 32 contains the key-value pairs set forth in Table 3.
Table 3: Key-Value pairs for the dictionary associated with the /XERX JobTicket ~ctream Key Type Value /Type name /XERX JobTicket /XERX FileAttr Xerox File Attributes of the Job Ticket attributes file. See below.
/Length Integer 0 Each /XERX FileAttr dictionary that encodes the location of the Job Ticket file contains the key-value pairs set forth in Table 4.
__1~__ Table 4: Key-Value pairs for the /XERX FileAttr dictionary for the Job Ticket file Key Type Value /XERX_F Array of 1st element: Relative path name of the strings job ticket file 2nd element: Full path name of the job ticket file /XERX_FileSi Integer File size in bytes.
ze /XERX_VolNum Integer Volume number on which file resides.
Default value is 1 if missing.
Each /Page object 54 dictionary contains the key-value pairs set forth in Table 5.
Table 5: Key-Value pairs that are either included or inherited for the /Paqe object dictionarv Key Type Value /Type Name /Page /Parent Dictionar Indirect reference to the Parent y object.
/Resources Dictionar See below.
Y
/MediaBox Array [O,O,x,y): Size of the image dimensions expressed in points (1 point = 1/72") where x and y a:re the dimensions in the slow-scan and fast-scan directions, respectively.
/Contents Stream See below.
__1g__ Each /Resources dictionary contains the key-value pairs set forth in Table 6.
Table 6: Key-Value pairs that are either included or inherited for the /Resources dictionary Key Type Value /Xobject Dictionar If DRI is present:
y /DRI <stream object number> .
Stream object encodes DRI data. See below.
If DRI is absent:
/AbsentDRI <stream object number> .
Stream object encodes AAbsent DRI-message. See below /XERX Xobjec Dictionar /PRI <stream object number> .
t y Stream object encodes PRI image data.
See below.
/ProcSet Array Procedure Sets required for imaging the page.
It should be noted that the <stream object number>
is a variable that denotes an indirect reference to a stream object.
The user has the option of suppressing the generation of DRIB when submitting the job for save. In this case, it is necessary to indicate to the user that a DRI is not available for the page or pager selected. This is addressed further below.
Each DRI stream contains the key-value pairs set forth in Table 7.
Table 7: Key-Value pairs for the dictionary associated with the /XObject stream 58 Key Type Yalue /Type name /Xobj ect /Subtype name /Image /Width Integer Number of pixels in the slow scan direction.
/Height Integer Number of pixels .in the fast scan direction.
/BitsPerComponent Integer Number of bits per component =
/ColorSpace name Color space in which the DRI
is created. For most printers, likely to be /Device CMYK.
/Filter name The cornpression scheme adopted to compress the DRI
data. /DCTDecode /DecodeParms dictionary If required.
/Length Integer Length in bytes of the stream data.
In the case where DRIB are not created for a job, rather than including the image data for a DRI, this object will include the data of a universal image that indicates that a DRI is Aabsent- or Aunavaila.ble- for that page.
Typically, the image data file will be installed at the DFE
22, and included in the PDF wrapper 38 for a job where the user has choosen to suppress DRI generation..
The advantage of this approach to indicating an absent DRI is that the PDF reader or editor is not required to support any fonts at all in order to view or edit the FRF
job. The cost of this approach i.s the greater effort required to build and install the Aabsent DRI- image and, if no universal symbol exists for Aabsent- or Aunavailable-, multiple images may need to be constructed and the appropriate image included in the localized language packages. Only one /XObject containing the image data for an Aabsent DRI- is constructed in the PDF wrapper 38. The /Contents object 56 of any page that has no associated DRI
will make an indirect reference to this /XObject. Thus the image data for an Aabsent DRI- will be included in a PDF
wrapper file only once.
The dictionary associated with each PRI image stream contains the key-value pairs set forth in Table 8.
Table 8: Key-Value pairs for the dictionary associated with the /XERX XOb~ect stream 60 Key Type Value /Type Name /XERX XObject /SubType Name /XERX-PrintImage /XERFileAttr Xerox Attributes of the Xerox Print Image File file.
attribute See below.
s /Length Integer 0 Each /XERX-FileAttr dictionary that encodes the location of the PRI image files contains the key-value pairs set forth in Table 9.
Table 9: Key-Value pairs for the /XERX_FileAttr dictionary for the PRI image files Key Type Value /XERX_F Array of 1st element: Relative path name of the strings PRI file.
2nd element: Full path name of the PRI
file.
/XERX FileSi Integer File size in bytes.
ze /XERX VolNum Integer Volume number o:n which file resides.
Default value is 1 if missing.
The first element of the key /XERX_F provides the relative path name of the image file, whereas the second element provides an alternative (in this case absolute) search path for the image file. When a job is submitted for fast reprint, the DFE 22 will first attempt to find the image using the relative path name. If this fails, it will attempt to find the image using the absolute path name. If this fails as well, an AUnable to resolve file reference-fault will be raised. In the preferred embodiment only two path names to the PRI file are necessary. However, the array of strings associated with the key /XERX_F may include as may elements as desired. In this case, the DFE 22 would attempt to find the PRI file at the locations specified in the array starting at the first element and continuing along the array until it finds the desired PRI file.
The attributes and content of the /Contents stream object are as follows: the dictionary associated with the /Contents stream consists of an entry corresponding to the specification of the length of the stream using the key /Length. The /Contents object stream of a /Page object that has an associated DRI is constructed as follows: i) the stream begins and ends with the PDF operators Aq= and AQ-that store and restore the current graphics state. If necessary, a concatenation matrix will be included next. The concatenation matrix operator is described subsequently. The PDF operator ADo- will execute an operand that is a named image. This named image is identica7_ to the image name in the object of type /XObject.
With reference now to Figure 6, once a print job has been saved, such as being stored on a save disk 70 associated with the DFE 22, a PDF reader tool may be used to view the DRIB of the saved job and navigate through the pages of the job. In addition to Job View, modifications of the saved job may be made through the use of a PDF editor tool 72. In particular, a PDF editor tool 72 provides the capability to re-order and delete pages in a single job.
Note that although it is the ordering of the DRIB that is being changed, the printed output of the modified saved job will reflect the new page order since the PDF file will be created in such a fashion that the reference to the associated PRI image will always move with the DRI. Note that this functionality is supported by Acrobat Exchange.
Further, the PDF editor provides the capability to open multiple jobs and insert the pages from one job into another. Once again, although it is the DRIs that are being inserted, the corresponding references to the PRI images are inserted as well and continue to be associated with the inserted DRIB. Note that this functionality is also supported by Acrobat Exchange.
An enhancement to the basic PDF editor functionality is provided by a Job 'picket Plug-in 74 that interprets the referenced job ticket 32, and displays as well as allows modification of the j ob programming attributes .
That is, the PDF plug-in 74, associated with the DFE 22, is capable of recognizing the Private PDF tags that are embedded within the PDF wrapper 38. The plug-in has the capability to locate and decode the contents of the=_ j ob programming file (i.e. job ticket 32) and graphically display the job programming of the saved job. It should be noted that without a Job Ticket Plug-in 32, the associated job ticket will not be updated. Thus, it would be up to the user to change the job programming when submitting the edited FRF job for reprint.
The advantages of using PDF as the saved job wrapper are more evident when remote (i.e. at a location other than the UI 24 of the DFE 22) job viewing and editing workflow is considered, as shown in Figure 7. A browser at a client workstation 12 uploads the necessary saved job wrappers 38 along with the associated job ticket files 32 from the save repository 70 at the DFE 22 to the local client workstation disk 76 using the ASave As- option in the browser. Thus, in order to view both the images and the job programming information, a remote viewer is required to upload both the saved job wrapper and the job ticket file.
It is necessary for the user to save the wrapper 38 and the associated job ticket file 32 in the same folder or directory, and furthermore the job ticket file should not be renamed. These restrictions are necessary so that the reference to the job ticket file from the saved job wrapper is valid. Alternatively, if the cl=ient has Network File System (NFS) access to the save repository 70, the saved job wrapper 38 may be accessed directly. The DFE '~2 supports saving jobs to multiple locations including, for example, the local controller disks) 70, an NFS mounted disk, and other portable disks connected to the controller through a SCSI
connection. However, saving jobs as they are being created on disks other than the local controller disk 70 is subject to likely performance degradation due to I/O bandwidth limitations.
Once the necessary files are available at the client workstation 12, the PDF editor 72 with the plug-in 74 (the appropriately ported version for the client workstation platform) or a third party tool for viewing and editing may be used in much the same fashion as at the UI 24 associated with the DFE 22. Once any editing on the uploaded jobs has been completed, there are a number of ways in which the modified jobs can be transferred back to the DFE 22 as discussed below. In all cases, the DFE 22 matches the DRI 36 in the saved job with the correct PRI image data 34.
One strategy for transferring a modified job back to the DFE 22 is to copy the modified job over to removable media 78 (Fig. 7) attached initially to the client workstation. The media may then be removed and mounted at the DFE 22 and the modified saved job copied over to the save repository 70 at the DFE 22. The modified job may then be submitted for reprint either at the DFE 22 or at any one of the client workstations 12. Note that the modified saved job may be placed anywhere in the save repository 70 and not necessarily replace the original saved job. Further, the modified saved job need not necessarily be copied to the save repository, but may be printed directly from the removable media although this is likely to cause performance degradation.
Although the above provides a mechanism to transfer a modified saved job back to the save repository 70, it is not very convenient for the user at a client workstation. An easier workflow may involve an HTTP download to the controller (i.e. DFE 22) as described in detail below with regard to a further embodiment of the present invention.
However, this requires some level of an authent_i.cation and authorization mechanism at the DFE 22. In the absence of an HTTP download, the modified saved job may be submitted for printing through a job submission tool 80 at the client workstation 12 and will be treated no differently than any other job. This workflow is different: than HTTP download in two respects: i) a new job ticket, based on the contents of the uploaded saved job ticket, may need to be constructed and submitted through the normal Internet Printing Protocol (IPP) channels, and ii) the modified saved job will be deleted once it completes printing successfully.
It is conceivable that the user at the client workstation may upload a saved job from one DFE and insert it into an uploaded saved job from another DFE. If the two DFEs do not share a common repository, a modified saved job that contains images form both DFEs will fault when submitted for reprint at either of the two DFEs. In this case, it is necessary to copy the required saved jobs from one DFE to the other before attempting to upload the saved jobs for editing and subsequent job submission.
If so desired, the PDF wrapper file may be submitted for print to any Acheaper- or Anon-targetecL
printer that supports PDF as the input PDL type. Since the wrapper is a legitimate PDF file that contains the low resolution DRIB, this will result in a Alow-cost. draft print of the contents of the FRF job.
The rendering data within the PRIs is generally calculated based on the knowledge of the rendering characteristics of the attached Image Output Terminal (IOT).
Thus, the PRIs 34 created for one DFE-IOT (22, 18) combination may not either print at a.11, or may print with poorer image quality, on another DFE-IOT combination.
However, the DRI 36 format is kept independent of the DFE-IOT
combination and, as mentioned above, is a format that conforms with the Adobe PDF Specification 1.3.
In order to solve this problem, it is contemplated that when a print job is submitted to a DFE with the disposition of Save, the DFE will decompose the PDL file creating the PRI and DRI for each page. Concurrently, the DFE will create and update the PDF wrapper as each page is decomposed. The PDF wrapper will embed the DRI and include the PDF-private tags that indicate the location of the PRI
file. Each PRI file can also include information that indicates the particular DFE-IOT combination for which the PRI file is targeted. One the last page is decomposed, the job programming will be stored in a job ticket file and the PDF wrapper updated with PDF-private tags to point to the job ticket file.
When viewing the saved job, the PDF plug-in module will have the capability to locate and decode the contents of the job programming file and graphically display the job programming of the saved j ob as well as the target DFE-IOT
combination. When editing a saved job, if an attempt is made to insert pages from a PDF wrapper that is targeted to a first DFE-IOT combination, into a PDF wrapper that is targeted to a second DFE-IOT combination, the PDF plug-in module will post an error message and prohibit this operation.
When submitting a saved job for fast reprint, the targeted DFE will recognize the PDF-specific tags in the PDF
wrapper and, rather than decompose the DRIB within the PDF
wrapper, it will locate the PRI associated with each DRI.
The DFE will first determine if the target DFE-IOT
combination stored within the PRI is the same as the DFE-IOT
combination that the PDF wrapper was submitted to. If affirmative, the PRI is submitted to the marking engine.
Since no decomposition is required, it will result in a fast reprint. Further the DFE will also locate the associated job programming f i 1e and apply the programming to the j ob . I f not, the DFE will fault the job and indicate the DFE-IOT
combination that the PRI is targeted f:or.
-_2~__ In the case where a print job is submitted to the DFE 22 from a web-based client workstation such as one of the workstations 12 of Figure 1, the web-based end-user would submit a job through a secure channel established with the web server 26 (Figure 1). The web server authenticates the end-user, determines if a valid account exists, c:ommunicates with a print server that then forwards the job to the appropriate DFE-IOT combination based on the job programming requested. Once the job is successfully saved on a repository (e. g. save repository 70, the print server notifies the end-user that the job is ready for a soft proof.
Thereafter, the user subsequently connects with the print server, is authenticated once again and given authorization to access only those saved jobs that resulted from previous job submissions from that end-user=s account. The end-user is then able to soft proof the job (i.e. view the DRIB
embedded within the PDF wrapper 38 and the view the job programming stored in the Job Ticket file 32) to verify that the job was constructed per the submitted job programming.
The end-user also has the option to download a private copy of the saved job, manipulate it by deleting pages, re-ordering pages, inserting pages from another saved j ob, and change some j ob programming parameters and veri fy the effects of these modifications. The end-user may then either submit the modified private copy of the saved job for one or more hard copies, or instruct. the print server to print one or more hard copies of the original saved job. An appropriate business model can be used. to deliver the copies to the user. The end-user also has the option of keeping the saved jobs on the repositories and is billed for this service accordingly. The end-user has the option to request hard copies of the saved job at a subsequent time and is guaranteed to obtain hard copies that. are identical within acceptable tolerance of the first set of hard copies requested.
--2g--Note that some enhancements to the existing platform capabilities would be neces:~ary to implement this web-based client-server model. For instance, the architecture that enables the associated workflow consists of a Hypertext Transfer Protocol (HTTP) server 26 that supports a security protocol such as the Secure Socket Layer (SSL) technology. This server is responsible for communication with the web-based clients of a print shop (e. g. the place where the document processing apparatus 14 is located). The HTTP server communicates with a print server (such as a PrintXchange$ print server) that manages and controls one or more DFEs which are connected to IOTs. The HTTP and print servers and the DFEs are networked (such as by Network File System protocol) to a saved job repository (such as repository 70).
It should be appreciated that the above description of the components is a logical, not physical, view. In all likelihood, the HTTP and print server will reside on the same hardware platform. In the case where a print shop has only one DFE, all three software components, namely, the HTTP
server, print server and the DFE may reside on only one hardware platform such as the document processing apparatus 14 of Figure 1.
In order to initiate a transaction from a web-based client workstation, an end-user uses a browser to connect to a Uniform Resource Locator (URL) addre=~s that makes available the web-based client submission software and PDF Job Ticket Plug-in software. Further, the customer must have a PDF
editor application loaded on the client: platform as well. It is also possible that the print shop may also make these software components available to the customer as well. The customer also establishes an account and obtains the necessary ID and password from the print shop.
When submitting a print job for Save using the web-based submission client, the end-user enters the account ID
and password and submits a job to the HTTP server 26 at the print shop over a secure connection, such as b:y using the Secure Socket Layer (SSL) technology. The job typically consists of a Page Description Language (PDL) file along with the associated job programming. The HTTP server authenticates the user and communicates with the print server that then forwards the job to the appropriate DFE, based on the job programming requested which may include a specification of the intended DFE-IOT target such as DFE-IOT
22, 14. The DFE 22 decomposes the PDL file and creates a DRI
36 and PRI 34 for each page. Concurrently, the DFE 22 creates and updates a PDF wrapper 38 as each page is decomposed, the job programming will be encoded and included within the PDF wrapper 38 along with Private PDF tags pointing to the location of the job programming within the PDF wrapper.
Upon executing some bookkeeping tasks, the PDF
wrapper 38 will be completed. The PDF wrapper 38 so constructed will conform to the latest Adobe PDF
specifications. Note that since the PRIs 34 are stored external to the PDF wrapper 38, the PDF wrapper 38 is compact relative to the size of the PRIs 36. The PDF wrapper 38 and the associated set of PRIs 34 form the saved job and is stored on the save repository 70. Once the save operation is completed, the DFE 22 notifies the Print Server which, through the HTTP server, notifies the end-user that the saved job is ready for soft-proofing.
Upon receiving the notification, the end-user connects with the HTTP server 26 and enters the ID and password. The HTTP server 26 once again authenticates the user and displays a list of saved jobs that the user with the specified ID is authorized to view. This list contains only the PDF wrappers 38 but not the associated PRIs. The end-user then selects the appropriate PDF' wrapper to view ( the PDF wrapper is named after the name c>f the PDL file in the originally submitted job). The end-user chooses to download the file and launches the PDF editor application (which also serves as a viewer) with the PDF Plug-in 74, to view the saved job. Note that only the relatively compact PDF wrapper is downloaded, but the large PRIs will continue to remain on the save repository 70 at the print shop. In fact, the latter are never authorized for access to the end-user. The PDF reader displays the DRIB 36 within the PDF wrapper 38 and, because of the PDF Job Ticket Plug-in 74, the effects of certain job programming will also be observable such as horizontal and vertical image shift, inserts, chapter starts, positioning of the staples/stitching and tumble.
As with the previous embodiments, there are a limited number of editing operations that a user may perform on the saved job through manipulation of the PDF wrapper.
These are page-level editing, such as page re-order, page deletion, and inserting pages from another of the end user=s saved job archived at the print shop. This is achieved through the operations that are available through the PDF
editor application. Although it is the DRIs that are being re-arranged by the editor, the Private PDF tags associated with the DRIB 36 that point to the corresponding PRI 34 will move with the DRIs 36. In addition, the Job Ticket Plug-in 74 allows the end-user to change job programming parameters (restricted to only those that are not related to rendering) - this list includes finishing options, stock size, plex, tumble, inserts, chapter starts, horizontal and vertical image shifts.
The PDF editor application with the Job Ticket Plug-in displays to the end-user the <=ffects of any changes in the job programming parameters. Once the end-user is satisfied with the soft-proof of the changes made, the end user may submit the PDF wrapper file, through the web-based submission client to the print shop HTTP server 26. Although the mechanism for submission remains the same as that for submission of a print job with the disposition of Save, the DFE 22, when it eventually receives the job, recognizes the Private PDF tags and the existence o:f the associated PRIs, and will not attempt to decompose the PDF wrapper. Although another PDF wrapper is created that is destined for the save repository 70, it is largely similar to the submitted PDF
wrapper; the latter is deleted when the job is complete. The DFE will not create any PRIs because all the PRIs referenced within the submitted PDF wrapper will already exist in the Save Repository.
If the soft-proof meets approval, the end-user connects with the HTTP server 26, and after the above-described authentication and authorization process, request the printing of a certain number of hard copies of selected PDF wrapper file(s). Associated information such as delivery options are also provided. The HTTP server 26 forwards the print request to the print server, and the print server in turn forwards the request to an available DFE-IOT
combination. The important restriction is that the DFE-IOT
combination cannot be different than the one on which the saved job was originally created. Once successfully delivered, an appropriate billing model is used to bill or debit the end-users account.
The end-user may choose to delete the saved jobs or may choose to archive them at the print shop in the event that additional copies are required in the future. The print shop is expected to implement a billing model based on size and length of the saved jobs and possibly other parameters and debit or bill the end-user=s account accordingly. If the end user has chosen to archive the saved jobs at the print shop, hard copies of any of the end user=s saved job may be requested at some subsequent time by following the process outlined above for requesting printing of a saved job upon soft approval. Since no re-decomposition takes place on a reprint and the PRIs are in printer-ready format, the printed output at any subsequent time will be of the same quality as the first hard copy print requested within the DFE-IOTs tolerance specifications.
Lastly, local copies of the PDF wrappers 38 may also be archived at the end-user=s workstation 12. This allows the end-user to view or edit the files at some subsequent time without having to connect with the print shop=s HTTP server. In addition, the end-user may also choose to print a draft mode print of the PDF wrappers on a locally available, non-targeted printer. When the PDF
wrapper is submitted to this printer, it will not recognize the Private PDF tags and will decompose the lower-resolution DRIs in the PDF wrapper. This results in what is considered to be a draft-mode print.
The invention has been described with reference to the preferred embodiments. Obviously, modifications and alterations will occur to others upon reading and understanding the preceding detailed description. It is intended that the invention be construed as including all such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.
For instance, it is recognized that when the save repository is backed-up or archived to a mass storage unit such as a tape drive unit, it is more expedient to transfer the files that comprise the stored print job (i.e. file wrapper, job ticket file, PRIs), as a single file or data stream rather than transfer the files separately.
Accordingly it is contemplated that the PRIs and/or the job ticket file can be embedded within th.e file wrapper by the DFE prior to being archived.
APPENDIX A
$PDF-1.3 ~ This file is an example of how a PDF wrapper file for a Fast Reprint Format saved job may be created.
The contents of the file do not necessarily reflect the actual contents of the PDF wrapper file, nor does it mandate any ~ specific order of encoding of the PDF objects.
For demonstrative purposes, this file is a two-page file where a DRI is present for the first image and absent for the second image. However, typically, either all DRIs will be present for ~ the job or none at all when the PDF wrapper' file is created.
In order to conserve space, a small B&W image is used for $ the DRI, which is subsequently magnified.
This file is legitimate (conforms to PDF1.3) and is complete.
2 0 ~ It was tested with both Acrobat Reader/Exch.ange 3.0 and 4Ø
~ The Information Object 2 5 1 0 obj /Author (adegani) /CreationDate (D:20000501150000-05'00') /Producer (Xerox Product Name) 3 0 /Title (example.ps) endobj ~ In this example, the first page is assumed to contain a DRI.
$ The Page object.
2 0 obj
4 0 /Type /Page /Parent 3 0 R
/Resources /XERX XObject « /PRI 4 0 R »
4 5 /XObject « /DRI 5 0 R /DRI_stamp 6 0 R»
/ProcSet 13 0 R
/Contents 7 0 R
»
/Resources /XERX XObject « /PRI 4 0 R »
4 5 /XObject « /DRI 5 0 R /DRI_stamp 6 0 R»
/ProcSet 13 0 R
/Contents 7 0 R
»
5 0 endobj g ~ Note that /DRI stamp is a small identifying image ~ that will be displayed on the lower left hand corner ~ and indicates that the displayed DRI is a "special"
55 ~ image that will print to full resolution and without g reRIPping (without the stamp) but will print "draft"
o mode (with the stamp) on any other printer.
g g The print-ready PRI image object.
__35__ 4 0 obj /Type /XERX_XObject /Subtype /XERX-PrintImage /XERX FileAttr /XERX_F [(example.ps.dir/example.ps.p00001.pri) (/var/spool/MySave/example.ps.frf/example.ps..dir/example.ps.p00001.pri) 1 0 /XERX FileSize 113413 /XERX VolNum 1 /Length 0 stream endstream endobj The Display Resolution Image object.
2 0 ~ In this file, only a small image is being used to conserve space.
5 0 obj /Type /XObject 2 5 /Subtype /Image /Width 24 /Height 23 /BitsPerComponent 1 /ColorSpace /DeviceGray 3 0 /Filter /ASCIIHexDecode /Length 165 stream 3 5 75F'E88 17FF8C 175F14 1C07E2 3803C4 703182 F8EDFC
001800 OOF800>
endstream endobj ~ The Contents object.
7 0 obj « /Length 61 »
stream q 500 0 0 500 0 0 cm /DRI Do Q
50 0 0 50 0 0 cm /DRI-stamp Do Q
endstream endobj ~ In this example, the second page is assumed not to contain a DRI.
~ The Page object.
8 0 obj /Type /Page /Parent 9 0 R
/Resources «
/XERX-XObject « /PRI 10 0 R »
/XObject « /AbsentDRI 11 0 R »
/ProcSet 13 0 R
»
/Contents 12 0 R
endobj 1 0 ~ The print-ready PRI image object.
0 obj «
/Type /XERX XObject 1 5 /Subtype /XERX_PrintImage /XERX FileAttr /XERX_F [(example.ps.dir/example.ps.p00002.px-i) (/var/spool/MySave/example.ps.frf/example.ps.dir/example.ps.p00002.pri) ) /XERX FileSize 234312 /XERX VolNum 1 /Length 0 »
stream endstream endobj 3 0 ~ The image that indicates that a DRI for this page is unavailable.
In this file, the image shows an "X" (to signify not available) and once again a small image is used which is subsequently magnified.
11 0 obj «
/Type /XObject /Subtype /Image /Width 24 /Height 23 4 0 /BitsPerComponent 1 /ColorSpace /DeviceGray /Filter /ASCIIHexDecode /Length 165 »
stream 400002 SOU001>
5 0 endstream endobj ~ The contents object for the absent DRI
5 5 12 0 obj « /Length 37 »
stream q 500 0 0 500 0 0 cm
55 ~ image that will print to full resolution and without g reRIPping (without the stamp) but will print "draft"
o mode (with the stamp) on any other printer.
g g The print-ready PRI image object.
__35__ 4 0 obj /Type /XERX_XObject /Subtype /XERX-PrintImage /XERX FileAttr /XERX_F [(example.ps.dir/example.ps.p00001.pri) (/var/spool/MySave/example.ps.frf/example.ps..dir/example.ps.p00001.pri) 1 0 /XERX FileSize 113413 /XERX VolNum 1 /Length 0 stream endstream endobj The Display Resolution Image object.
2 0 ~ In this file, only a small image is being used to conserve space.
5 0 obj /Type /XObject 2 5 /Subtype /Image /Width 24 /Height 23 /BitsPerComponent 1 /ColorSpace /DeviceGray 3 0 /Filter /ASCIIHexDecode /Length 165 stream 3 5 75F'E88 17FF8C 175F14 1C07E2 3803C4 703182 F8EDFC
001800 OOF800>
endstream endobj ~ The Contents object.
7 0 obj « /Length 61 »
stream q 500 0 0 500 0 0 cm /DRI Do Q
50 0 0 50 0 0 cm /DRI-stamp Do Q
endstream endobj ~ In this example, the second page is assumed not to contain a DRI.
~ The Page object.
8 0 obj /Type /Page /Parent 9 0 R
/Resources «
/XERX-XObject « /PRI 10 0 R »
/XObject « /AbsentDRI 11 0 R »
/ProcSet 13 0 R
»
/Contents 12 0 R
endobj 1 0 ~ The print-ready PRI image object.
0 obj «
/Type /XERX XObject 1 5 /Subtype /XERX_PrintImage /XERX FileAttr /XERX_F [(example.ps.dir/example.ps.p00002.px-i) (/var/spool/MySave/example.ps.frf/example.ps.dir/example.ps.p00002.pri) ) /XERX FileSize 234312 /XERX VolNum 1 /Length 0 »
stream endstream endobj 3 0 ~ The image that indicates that a DRI for this page is unavailable.
In this file, the image shows an "X" (to signify not available) and once again a small image is used which is subsequently magnified.
11 0 obj «
/Type /XObject /Subtype /Image /Width 24 /Height 23 4 0 /BitsPerComponent 1 /ColorSpace /DeviceGray /Filter /ASCIIHexDecode /Length 165 »
stream 400002 SOU001>
5 0 endstream endobj ~ The contents object for the absent DRI
5 5 12 0 obj « /Length 37 »
stream q 500 0 0 500 0 0 cm
6 0 /AbsentDRI Do Q
endstream endobj The /XObject image for the stamp identifier.
6 0 obj «
/Type /XObject /Subtype /Image /Width 16 /Height 11 /BitsPerComponent 1 1 0 /ColorSpace /DeviceGray /Filter /ASCIIHexDecode /Length 56 stream 074F SFBF C67F E37F E5FF F3FF FOFF E47F CE3F 9F1F OEOF>
endstream endobj The ProcSet object.
13 0 obj [/PDF /ImageB]
endobj 2 5 ~ The hierarchy of the Pages objects.
The Pages object for all pages that contain. the DRIB.
3 0 obj «
/Type /Pages /Parent 14 0 R
/Count 1 /Kids [2 0 R]
»
endobj ~ The Pages object for all pages that don't contain the DRIB.
9 0 obj «
/Type /Pages /Parent 14 0 R
/Count 1 4 5 /Kids [8 o R]
endobj ~ The Pages object for all pages.
14 0 obj /Type /Pages /Count 2 5 5 /MediaBox [0 0 612 792]
/Kids [3 0 R 9 0 R]
endobj ~ The Root Object 15 0 obj /Type /Catalog __3g__ /Pages 14 0 R
/XERX-JobTicket16 0 R
endobj The Job Ticket object.
16 0 obj /Type /XERX-JobTicket /XERX_FileAttr /XERX_F [(example.ps.jt) (/var/spool/MySave/example.ps.frf/example.ps.jt)]
/XERX-FileSize 098 /XERX VolNum /Length 0 2 stream endstream endobj xref 0000000000 65535f 0000000818 00000n 0000001036 00000n 3 0000004111 00000n 0000001564 00000n 0000001949 00000n 0000003728 00000n 0000002312 00000n 3 0000002519 00000n 0000004249 00000n 0000002721 00000n 0000003206 00000n 0000003589 00000n 4 0000003980 00000n 0000004359 00000n 0000004469 00000n 0000004573 00000n trailer /Size 17 /Root 15 0 R
/Info 1 0 R
5 startxref ~~EOF
endstream endobj The /XObject image for the stamp identifier.
6 0 obj «
/Type /XObject /Subtype /Image /Width 16 /Height 11 /BitsPerComponent 1 1 0 /ColorSpace /DeviceGray /Filter /ASCIIHexDecode /Length 56 stream 074F SFBF C67F E37F E5FF F3FF FOFF E47F CE3F 9F1F OEOF>
endstream endobj The ProcSet object.
13 0 obj [/PDF /ImageB]
endobj 2 5 ~ The hierarchy of the Pages objects.
The Pages object for all pages that contain. the DRIB.
3 0 obj «
/Type /Pages /Parent 14 0 R
/Count 1 /Kids [2 0 R]
»
endobj ~ The Pages object for all pages that don't contain the DRIB.
9 0 obj «
/Type /Pages /Parent 14 0 R
/Count 1 4 5 /Kids [8 o R]
endobj ~ The Pages object for all pages.
14 0 obj /Type /Pages /Count 2 5 5 /MediaBox [0 0 612 792]
/Kids [3 0 R 9 0 R]
endobj ~ The Root Object 15 0 obj /Type /Catalog __3g__ /Pages 14 0 R
/XERX-JobTicket16 0 R
endobj The Job Ticket object.
16 0 obj /Type /XERX-JobTicket /XERX_FileAttr /XERX_F [(example.ps.jt) (/var/spool/MySave/example.ps.frf/example.ps.jt)]
/XERX-FileSize 098 /XERX VolNum /Length 0 2 stream endstream endobj xref 0000000000 65535f 0000000818 00000n 0000001036 00000n 3 0000004111 00000n 0000001564 00000n 0000001949 00000n 0000003728 00000n 0000002312 00000n 3 0000002519 00000n 0000004249 00000n 0000002721 00000n 0000003206 00000n 0000003589 00000n 4 0000003980 00000n 0000004359 00000n 0000004469 00000n 0000004573 00000n trailer /Size 17 /Root 15 0 R
/Info 1 0 R
5 startxref ~~EOF
Claims (24)
1. A method for generating a print job comprising the steps of:
a) decomposing the print job into print resolution image data and display resolution image data for each page of the print job, wherein said print resolution image data is in a post-raster-image-processed ( postRIPed) format and said display resolution image data is a lower resolution replica of the print resolution image data;
b) generating a wrapper file and a job ticket file;
c) embedding the display resolution image data in the wrapper file;
d) embedding in the wrapper file pointers to the location of the print resolution image data;
e) storing attribute data for the print job in the job ticket file;
f) embedding pointers to the location of the job ticket file in the wrapper file; and g) storing the wrapper file, the job ticket file, and the print resolution image data on a save repository.
a) decomposing the print job into print resolution image data and display resolution image data for each page of the print job, wherein said print resolution image data is in a post-raster-image-processed ( postRIPed) format and said display resolution image data is a lower resolution replica of the print resolution image data;
b) generating a wrapper file and a job ticket file;
c) embedding the display resolution image data in the wrapper file;
d) embedding in the wrapper file pointers to the location of the print resolution image data;
e) storing attribute data for the print job in the job ticket file;
f) embedding pointers to the location of the job ticket file in the wrapper file; and g) storing the wrapper file, the job ticket file, and the print resolution image data on a save repository.
2. The method of claim 1, wherein step c) includes the step of:
h) embedding the display resolution image data in the wrapper file as each page of the print job is decomposed.
h) embedding the display resolution image data in the wrapper file as each page of the print job is decomposed.
3. The method of claim 1, wherein step d) includes the step of:
h) embedding in the wrapper file pointers to the location of the print resolution image data as each page of the print job is decomposed.
h) embedding in the wrapper file pointers to the location of the print resolution image data as each page of the print job is decomposed.
4. The method of claim 1, wherein step e) includes the step of:
h) after the last page of the print job has been decomposed, storing attribute data for the print job in the job ticket file.
h) after the last page of the print job has been decomposed, storing attribute data for the print job in the job ticket file.
5. The method of claim 1, wherein step b) includes the step of:
h) generating a wrapper file that conforms to the Adobe Portable Document Format 1.3 specification.
h) generating a wrapper file that conforms to the Adobe Portable Document Format 1.3 specification.
6. The method of claim 1, wherein step g) includes the step of:
h) storing the print resolution image data on the save repository in a compressed format.
h) storing the print resolution image data on the save repository in a compressed format.
7. The method of claim 1, wherein step g) includes the step of:
h) storing the wrapper file, the job ticket file, and the print resolution image data on the save repository which is associated with a digital front end of a digital color copier apparatus.
h) storing the wrapper file, the job ticket file, and the print resolution image data on the save repository which is associated with a digital front end of a digital color copier apparatus.
8. The method of claim 7, further including the step of:
i) displaying the display resolution image data embedded in the wrapper file at a user interface associated with the digital front end.
i) displaying the display resolution image data embedded in the wrapper file at a user interface associated with the digital front end.
9. The method of claim 7, further including the step of:
i) displaying the display resolution image data embedded in the wrapper file at a workstation that communicates with the digital front end.
i) displaying the display resolution image data embedded in the wrapper file at a workstation that communicates with the digital front end.
10. The method of claim 7, further including the step of:
i) editing the wrapper file at a user interface associated with the digital front end.
i) editing the wrapper file at a user interface associated with the digital front end.
11. The method of claim 10, wherein step i) includes the step of:
j) at least one of re-ordering, inserting, and deleting display resolution image data embedded in the wrapper file at a user interface associated with the digital front end.
j) at least one of re-ordering, inserting, and deleting display resolution image data embedded in the wrapper file at a user interface associated with the digital front end.
12. The method of claim 7, further including the step of:
i) editing the wrapper file at a workstation that communicates with the digital front end.
i) editing the wrapper file at a workstation that communicates with the digital front end.
13. The method of claim 10, wherein step i) includes the step of:
j) at least one of re-ordering, inserting, and deleting display resolution image data embedded in the wrapper file at a workstation that communicates with the digital front end.
j) at least one of re-ordering, inserting, and deleting display resolution image data embedded in the wrapper file at a workstation that communicates with the digital front end.
14. The method of claim 1, further including the step of:
h) displaying the display resolution image data embedded in the wrapper file with a PDF viewer tool.
h) displaying the display resolution image data embedded in the wrapper file with a PDF viewer tool.
15. The method of claim 1, further including the step of:
h) editing the display resolution image data embedded in the wrapper file with a PDF editor tool.
h) editing the display resolution image data embedded in the wrapper file with a PDF editor tool.
16. The method of claim 1, further including the step of:
h) displaying the print job attribute data that is stored in the job ticket file with a PDF plug-in tool.
h) displaying the print job attribute data that is stored in the job ticket file with a PDF plug-in tool.
17. The method of claim 1, further including the step of:
h) editing the print job attribute data that is stored in the job ticket file with a PDF plug-in tool.
h) editing the print job attribute data that is stored in the job ticket file with a PDF plug-in tool.
18. The method of claim 1, further including the step of:
h) embedding data indicative of a targeted document processing apparatus in the print resolution image data.
h) embedding data indicative of a targeted document processing apparatus in the print resolution image data.
19. The method of claim 1, further including the step of:
h) printing the wrapper file on a non-targeted document processing apparatus to generate a draft-mode copy of the saved print job.
h) printing the wrapper file on a non-targeted document processing apparatus to generate a draft-mode copy of the saved print job.
20. The method of claim 1, further including the step of:
h) editing at least one of the file wrapper and the job ticket file from a web-based client workstation.
h) editing at least one of the file wrapper and the job ticket file from a web-based client workstation.
21. The method of claim 1, further including the step of:
h) printing the print resolution data image that is stored on the save repository.
h) printing the print resolution data image that is stored on the save repository.
22. The method of claim 1, further including the step of:
h) printing the print resolution image data in the same order as the display resolution image data embedded in the file wrapper.
h) printing the print resolution image data in the same order as the display resolution image data embedded in the file wrapper.
23. The method of claim 1, further including the steps of:
h) editing the file wrapper to rearrange the display resolution image data; and i) printing the print resolution image data in the same order as the rearranged display resolution image data.
h) editing the file wrapper to rearrange the display resolution image data; and i) printing the print resolution image data in the same order as the rearranged display resolution image data.
24. The method of claim 1, further including the steps of:
h) editing the job ticket file to modify job attributes of the saved print job; and i) printing the print resolution image data with the modified job attributes.
h) editing the job ticket file to modify job attributes of the saved print job; and i) printing the print resolution image data with the modified job attributes.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US20215600P | 2000-05-05 | 2000-05-05 | |
| US60/202,156 | 2000-05-05 | ||
| US58682100A | 2000-06-05 | 2000-06-05 | |
| US09/586,821 | 2000-06-05 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2346215A1 CA2346215A1 (en) | 2001-11-05 |
| CA2346215C true CA2346215C (en) | 2006-01-24 |
Family
ID=26897405
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002346215A Expired - Fee Related CA2346215C (en) | 2000-05-05 | 2001-05-02 | Fast reprint file format that utilizes private tags to provide reprintable jobs that can be viewed and edited using standard tools |
Country Status (3)
| Country | Link |
|---|---|
| BR (1) | BR0101790A (en) |
| CA (1) | CA2346215C (en) |
| MX (1) | MXPA01004466A (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1963961A4 (en) * | 2005-12-01 | 2010-11-03 | Avery Dennison Corp | System and method of managing a ticket order |
| US7472828B2 (en) * | 2005-12-01 | 2009-01-06 | Avery Dennison Corporation | System and method of managing a ticket order |
| WO2008058423A1 (en) * | 2006-11-14 | 2008-05-22 | Yuqian Xiong | Method for step-type downloading and displaying pdf file |
-
2001
- 2001-05-02 CA CA002346215A patent/CA2346215C/en not_active Expired - Fee Related
- 2001-05-03 MX MXPA01004466A patent/MXPA01004466A/en unknown
- 2001-05-07 BR BR0101790-0A patent/BR0101790A/en not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| MXPA01004466A (en) | 2005-07-25 |
| CA2346215A1 (en) | 2001-11-05 |
| BR0101790A (en) | 2001-12-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6628417B1 (en) | Data communication apparatus, image server, control method, storage medium, and image system | |
| US6611349B1 (en) | System and method of generating a printing plate file in real time using a communication network | |
| US6708309B1 (en) | Method and system for viewing scalable documents | |
| US7688459B2 (en) | Document processing method | |
| US6904185B1 (en) | Techniques for recursively linking a multiply modified multimedia asset to an original digital negative | |
| US20060179080A1 (en) | System for management of source and derivative data | |
| JP4681786B2 (en) | Video editing workflow method and apparatus | |
| US6611348B1 (en) | System and method for communication over a TCP/IP network with an appletalk network for publishing and printing services | |
| ES2349776T3 (en) | METHOD AND APPLIANCE FOR THE DOCUMENT PROCESS. | |
| US20040133924A1 (en) | Techniques for syncronizing any of a plurality of associated multimedia assets in a distributed system | |
| US20030090531A1 (en) | Digital data preservation system | |
| US20030053107A1 (en) | Printing control apparatus and printing control method | |
| JP3055455B2 (en) | Document storage device | |
| US20080313537A1 (en) | Document management apparatus, document management method, and program | |
| WO2005019979A2 (en) | Methods and systems for creating digital photography books | |
| JP6088625B2 (en) | Acquiring multimedia assets from multiple multiple modified child multimedia assets | |
| US20090249195A1 (en) | Computer-Implemented System For Creating A Publication And Method Thereof | |
| US20020029242A1 (en) | Image editing method and system | |
| JP5829083B2 (en) | Techniques for synchronizing any of multiple associated multimedia assets in a distributed system | |
| JP2970521B2 (en) | Document storage device | |
| KR20070042684A (en) | Generation method of pdf document by editing and merging documents from mutiple application | |
| CA2346215C (en) | Fast reprint file format that utilizes private tags to provide reprintable jobs that can be viewed and edited using standard tools | |
| US7212322B2 (en) | Preview function in a digital data preservation system | |
| JP2003091527A (en) | Information processing device and method | |
| US20010027454A1 (en) | Method, apparatus, and recording medium for displaying templates |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |