MXPA01004466A - Fast reprint file format that utilizes private tags to provide reprintable jobs that can be viewed and edited using standard tools. - Google Patents

Abstract

The invention involves they 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

METHOD FOR GENERATING AN IMPRESSION WORK Background of the Invention The present invention relates to document processing techniques. It finds particular application in conjunction with a method and apparatus for structuring a Portable Document Format File (PDF) that uses private PDF marks to provide a reprintable work that can be viewed and edited using standard PDF tools, and will be described with reference particular to these. The ability to create a stored printed job in which subsequent operations such as viewing small parts of the images of a job; reordering, deletion, and insertion of pages; and presentation for a fast reprint without requiring an internal image reprocessing (frame image processing) is currently provided by several sellers only at the front end or digital input (DFE) of a document processing apparatus such as a digital copier The formats of the stored print jobs and images are patented and the programs and programming systems to carry out the above operations were developed, and are provided in the DFE only. There are two disadvantages of this method, from the Ref: 129113 perspective of the client, the user presenting a work to be stored will most likely do this from a platform connected to the network whose operating system (OS) and file system are not identical to that of the DFE. Instead of being able to carry out any of the above operations from the same platform, the user must move to the DFE, or provide instructions to the DFE operator, which has a negative impact on the productivity of the client's workflow. This is a problem especially if the end user is presenting a job to a client using a network-based presentation that is physically located a considerable distance from the DFE. From the perspective of the vendor, this solution has a negative impact on the reduction of the practice since they must be designed, documented and maintained formats of patented works and images along with the design, developed and tested programs and programming systems that provide all the capabilities described above. In addition, if vendors choose to provide this capability on platforms other than the DFE, it would probably require additional improvements to the formats of jobs and images along with a port of the other programs and programming systems for other platforms.

Accordingly, it has been considered desirable to provide a novel and improved method for structuring a Portable Document Format (PDF) file using private PDF marks to provide a reprintable work that can be viewed and edited using standard PDF tools that meet the needs stated above. and overcomes the above and other difficulties and provides both better and more advantageous results.

Brief Description of the Invention In accordance with one aspect of the present invention, a method for generating a stored print image is described. The method includes the steps of: a) decomposing the print job into print resolution image data and displaying the resolution image data for each page of the print job; b) generate an enveloping file and an entry ticket to the work; c) include the data of the display resolution image in the envelope file; d) include the indicators of the envelope file in the location of the data of the print resolution image; e) store the data of the attributes for the print job in the entry ticket to work; f) include indicators in the location of the entry ticket to work in the envelope file; and g) store the envelope file, the entry ticket to the work file, and the print resolution data in a storage depot. An advantage of the present invention is that it provides a method and apparatus for structuring a Portable Document Format (PDF) file envelope, so that when a stored job is printed, the envelope presentation of the PDF file through the mechanisms of Existing presentation results in a front end or digital input associated with a document processing device that recognizes private PDF marks included in the PDF envelope, acting on the work schedule instructions in a work ticket file, and printing print resolution images associated with the stored job. Another advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file envelope, so that when a work is viewed, it can be used for any existing application (such as Adobe Acrobat ReaderS) to view the display resolution images that are included within the envelope of the PDF file on any platform connected to the network, including a front end or digital input associated with a document processing device.

Yet another advantage of the present invention is the provision of a method and an apparatus for structuring a portable document format (PDF) file envelope, so that when a stored job is edited, any existing application (such as Adobe Acrobat Exchanged) to reorder or delete pages of a job, or insert pages of one job into another or any platform connected to the network, including a front end or digital input associated with a document processing device. A further advantage of the present invention is the provision of a method and an apparatus for structuring a Portable Document Format (PDF) file envelope, so that when the edited work is presented for printing, the associated resolution image files The envelope of the PDF file will be printed in the same order as the display resolution images that are included in the envelope of the PDF file. A further advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file envelope, so that when the PDF wrap file can be presented to an alternative printer the result is erasing mode of the display resolution images that are included within the envelope of the PDF file. An even further advantage of the present invention is the provision of a method and apparatus for structuring a Portable Document Format (PDF) file envelope that provides the ability to access data on pages and images upon request and in any order . Still further advantages to the present invention will be apparent in the art upon reading and understanding the following detailed description of the preferred embodiments.

Brief Description of the Drawings The invention can take form in several components and arrays of components, and in several steps and arrangements of steps. The drawings serve only for the purpose of illustrating a preferred embodiment and should not be construed as limiting the invention. Figure 1 is a simplified block diagram of an exemplary network document processing system embodying the features of the present invention therein; Figure 2 is a schematic representation of the structure of the Rapid Reprint Format (FRF) logical work according to the present invention; Figure 3 is a schematic representation of the physical structure of the Rapid Reprint Format (FRF) according to the present invention; Figure 4 is a schematic representation of an exemplary PDF file that has not been updated. Figure 5 is a schematic representation of the structure of the logical document and the protruding objects of the PDF stored work file envelope according to the present invention; Figure 6 is a schematic representation for workflows for viewed and edited works 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 viewed and edited works in a client workstation that is in communication with the digital front end of a document processing apparatus according to the present invention.

Detailed Description of the Invention Referring now to Figure 1, there is shown an exemplary network document processing system 10 comprising a plurality of document processing units. In particular, the document processing system 10 comprises one or more clients such as workstations 12-1, 12-2, 12-3, ... 12-n which may be on the site (eg LAN). ) and / or remote (eg WAN), and at least one document processing apparatus 14 communicating with work stations 12 through a network or communication channels 16. As will be appreciated, although 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 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 clients or all clients 12 can have a document scanner, disk entry, keyboard, fax, etc. to generate the electronic documents that comprise the work to be printed. The clients 12 each have a User Interface (UI) with interactive screen (not shown) that allows programming of selections of documents or work to be performed. The document processing apparatus 14 may take the form of a multifunctional document processing device, for example, a digital color copier that includes an Image Input Terminal (IIT) 18 such as a document scanner, a terminal Output of Images (IOT) 20 such. as a printer / marker, a digital front end (DFE) or a controller 22 with a User Interface (UI) of the module 24. As described in detail with respect to a further embodiment of the present invention, the DFE may include a HTTP server / Printing 26. As is known in the art, the multifunctional document processing apparatus 14 may also include a facsimile module 28, if desired. The multifunction 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) the reprinting of the printed work stored at the speed of the IOT 20 machine (ie reprint a stored job without requiring a frame input reprocessing), ii) view small parts of the images of a print job stored, and iii) reorder, delete and / or insert pages of a stored print job, in any of the work stations of the client 12 and / or the UI 24 associated with the DFE 22. It should be noted that, given the limitations of Currently available processing power, it is not possible to store raster image data in a standard format in the industry to provide reprinting at the speed of the machine. Rapid compression essentially does not require a reprocessing of the frame input of the stored job, and further requires that the data of the compressed image be stored in such a way that it can be consumed directly by the decompression cards of the physical computing components without any conversion or manipulation (which potentially consumes time and degrades productivity) of the image data. In addition to the operation of the reprint, preserving the quality of the stored print job is an equally important consideration in choosing a scheme that does not involve reprocessing the work's frame input and using a compression format that preserves the information from control. The preservation of this information ensures that the reprints of the stored work will be printed identically within the tolerance of the system. The conversion to a standard format in the industry that does not support the coding of all the image and control data that is present in the patented format will result in the loss of information that will manifest itself in a poor image quality of the reprints.

Briefly, to create images that can be reprinted at the speed of the IOT 20 machine with good image quality, a compressed image format, called print resolution image format (PRI), is necessary. Construct a display image from compressed image data (i.e. PRI image data) at the demand point. { for example in any of the work stations 12) it takes too much time to be of any practical value. Thus, according to the present invention, display image data, called Display Resolution Image Data (DRI), are generated at the same time PRI data is generated. In general, the size of the DRI data is considerably smaller than the corresponding PRI data (less than about 1%). As used herein, the term Display Resolution Image A = or simply ADRI = refers to an image that is a lower resolution printer replica that was typically used to be displayed on a monitor. Furthermore, as used herein, the term print resolution image A = or simply APRI = refers to an image file in which the image data is in a postRIP compressed format. A schematic view of a print job that is stored according to the Fast Reprint Format (FRF) of the present invention is shown in Figure 2, and the physical structure of the stored print job is shown in Figure 3. As shown in FIG. used here, the term Quick Reprint Format A = or simply AFRF = refers to a format that specifies the coding of work and image attributes in which the image data is in a compressed postRIP format that can be directly consumed by the video trajectory towards the IOT. In addition, the Quick Reprint Format also refers to the format that allows the use of an existing third-party tool to perform various operations of the stored print jobs and their content, and to encapsulate the details of a stored print job file. and image formats. The stored print job is not a single file but a collection of files that is stored in a single container directory. The stored print job is not referenced by its components but by the name of the container directory 30. There are four distinct components of a stored print job according to the present invention: i) a ticket entry file to a job 32 that describes scheduling the work of the stored print job (an entry ticket to work conventionally encodes those job attributes that are required to allow the reprint of a stored print job); ii) a set of images composed of compressed frame data ready to be printed (ie processed by the frame input processing) (i.e. PRIs) 34; iii) a corresponding set of display resolution images (DRI) 36; and iv) a wrapper of file A of work = 38 that sequences the set of PRI and DRI ready to print and encodes its attributes. As described in detail below, the DRIs are included within the envelope of the file, but each PRI as well as the entry ticket file is stored separately and is accessed indirectly through a file reference inside the envelope. Entry tickets to work generally include information related to attributes that characterize a document job. Specifically, the entry ticket to work 32 encodes those work attributes that are required to allow the reprint of a stored print job. Attributes typically include work attribute levels (for example, set amount, copy count, termination and plex requirements) and page level attributes (for example, paper information). The present invention uses the specification of Portable Document Format (PDF) Adobe 1.3 to create a PDR file (ie the envelope of the stored work file 38) that organizes the different elements of the stored print job, namely the work schedule (ie the entry ticket to work 32) the display resolution (DRI) images 36 and the print resolution images (PRI) 34. As described in detail below, the PDF 38 envelope includes a number of marks Private PDFs which are mainly used to locate the job programming file 32 and the PRI 34 that are stored in the DFE 22 and external to the PDF 38 envelope. On the other hand, the DRI 36 are included within the PDF 38 envelope and are conform to the specification of PDF 1.3. The PDF 38 envelope is included with private data through the use of second-class name extensions (ie private PDF marks) that have been registered with the Adobe PDF Name Record. Second class names are sequences ordered by prefixes that are assigned to individual companies. The assignee of the present invention has registered the ordered second-order prefix sequence AXERX = with Adobe. All PDF readers that support PDF versions greater than 1.0 will ignore such private data. There are a number of advantages associated with reference to PRI 34 within the PDF 38 envelope, such as i) large PRI files can not be accessed when the PDF 38 envelope is viewed or edited in the UI 24 of the DFI 22, and ii ) the PRI files are not transmitted through the network 16 if the stored print job is viewed on a workstation 12. The cost associated with reference to the PRI files in the PDF 38 envelope is that a relationship must be established between the location of the PDF 38 envelope and the PRI 34 images to prevent loss or expiration references. This is a concern where archiving and retrieval of removable media and page insertion capabilities are required. Likewise, there are a number of advantages associated with the inclusion of DRI 36 within the PDF 38 envelope, such as when viewing the print job stored remotely (i.e. on a workstation 12), it should only be loaded at the PDF 38 enclosure with the included DRIs 36. Otherwise, it would be necessary to individually load the PDF 38 enclosure and potentially dozens or hundreds of DRIs making remote viewing inconvenient. In addition, there are no loss or expiration file references with the DRIs included. A cost associated with the DRIs included in the envelope of file 38 is that the PDF envelope along with the DRIs included may become potentially large. It was contemplated that a very aggressive compression scheme can be employed to reduce the size of the DRI. Since the envelope is a PDF file, it is necessary to use a compression scheme for the DRI that is supported by PDF. When a print job is to be stored, the job is presented to DFE 22 with a Store setup. The job typically consists of a PDL Page Description Language file along with the associated job schedule. DFE 22 is programmed to decompress the PDL file and creates a PRI and DRI for each page of the print job. Concurrently, DFE 22 creates and updates the PDF 38 envelope as each page of the print job is decomposed. The PDF 38 envelope is included with the DRIs and with private PDF marks (that is, indicators) that indicate the location of the PRI files. Once the last page of the print job is decomposed, the work schedule will be stored in a work ticket 32 and the PDF 38 envelope updated with private PDF marks to point to the work ticket 32 file. Once built, the PDF 38 envelope complies with the Adobe PDF 1.3 specification. Since the PRI 34 are stored external to the PDF 38 envelope, the PDF 38 envelope is compact in relation to the size of the PRI. In this way, any observing third party that conforms to the Adobe PDF 1.3 specification (such as the Adobe Acrobat Readerd) should be able to read the DRI 36 included in the PDF 38. The observer can reside on any platform that has access to the PDF envelope 38. This includes i) the UI 24 associated with the DFE 22, ii) a workstation platform 12 with a DFE network connection 22 using a communication protocol such as the Network File System (NFS) , FTP (File Transfer Protocol), File Transfer Protocol (HTTP), etc., or iii) a platform connected to a portable medium (for example, a CD) to which the PDF 38 envelope was copied when mounted previously about DFE 22. Note that in (ii) and (iii) above, access to large PRI files is not required 34. The PDF envelope that is built with Xerox private PDF tags (ie second-class names with the prefix "XREX") includes a a small, distinctive stamped image superimposed on each DRI image in a non-intrusive place (ie in a corner of the displayed image). After viewing such a stamped image, the PDF 28 envelope will be identifiable with a PDF surround file. In addition, any third-party publisher that conforms to the Adobe PDF 1.3 specification (such as Adobe Acrobat ReaderS) will be able to order DRIs, suppress DRIs, and / or insert DRIs of other work. The editor can reside on any platform listed above and, once again, no direct access to the PRI is necessary. Although these are the DIRs that are being fixed by the editor, the PDF specific tags associated with the DRIs that point to the corresponding PRI move with the DRIs. This is in accordance with the Adobe PDF 1.3 specifications. In particular, an editor is required to move marks not included with the page. In this way when an edited PDF envelope 38 is presented to the DFE 22 through the normal presentation mechanisms, the PRI 34 will be printed in the same order as the newly arranged DRI 36. In addition to the DRI 36 edition of the stored job , a PDF connection described below provides the ability to edit the programming file of a job 32 of a stored job. The previously stored work can be presented for a representation at a later time using any of the usual presentation mechanisms. The DFE 22 will recognize the private PDF marks in a PDF envelope 38 and, in addition to decomposing the DRIs 36 within a PDF envelope 38, it will locate the PRI 34 associated with each DRI 36 and present it to the marking machine 20. Since it is not requires decomposition, this will result in a rapid reprint at the machine speed of the IOT 20. In addition, the DFE 22 also locates the associated work schedule file (i.e. the entry ticket file to work 32) and applies programming to work. 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, Portable Document Format Reference Manual, Version 1.3, March 11, 1999 (IBSN 0-201-62628-4), is incorporated herein by reference. The structure of the PDF file provides a way to have quick access to any part of a document, and a mechanism to update this. Referring now to Figure 4, the standard PDF file 40 consists of four sections: a header of a line 42, a body 44, a cross reference table 46, and a tail 48. A PDF document can be described as a hierarchy of objects contained in the body section 44 of the PDF file 40. Most of the objects in this hierarchy are dictionaries. Parent relationships, children and siblings are represented by pairs of key values whose values are indirect references to objects of parents, children or siblings. For example, the Catalog object, which is the root of the hierarchy, contains a Page 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 a PostScript language; they start with a character A% = and can start at any point in a line. Continuing with reference to Figure 4, the header section of a line 42 of a PDF file specifies the version number of the PDF specification to which the file adheres. The Body 44 section of a PDF file consists of a sequence of PDF files that collectively represent a PDF document. More particularly, the objects represent components of the document such as alphanumeric characters such as fonts, pages and sampled images. The cross-reference section (ie table) 46 contains information that allows random access to indirect objects in the file, so that the entire file does not need to be read to locate any particular object. For each indirect object in the file the table contains an entry of a line that describes the location of the object in the file. A PDF file contains a cross-reference table, consisting of one or more sections. If updates to the file have not been appended, the cross-reference table contains a single section. A section is added each time updates to the file are appended. The cross-reference section is the only part of a PDF file with a fixed format. This allows 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 Tail 48 section of the PDF document allows an application that reads a PDF file to quickly find the cross-reference table and certain special objects. Applications typically read a PDF file from its endpoint. The last line of a PDF file contains only the end-of-file marker, %% EOF. The two preceding lines contain the keyword initxref and the byte deviation from the beginning of the file from the beginning of "the word xref in the last cross-reference section of the file." The Cola dictionary precedes this line. queue consists of the keyword coJa followed by a set of pairs of key values enclosed in double angle brackets The keyword queue specifies the location of the Catalog object as the value of the Root key of the queue. the location of the Info document dictionary, a structure that contains general information about the document, such as the value of the queue's Info key The Catalog object is a dictionary that is the root node of the document. pages contained in the document, a reference to the tree of objects that represent the outline of the document, a reference to the threads of the document, and the nom named destination. In addition, the Catalog indicates whether the outline of the document or small parts of images should be presented automatically when the document is viewed and if it should be shown somewhere other than the first page when the document is opened. Figure 5 shows the structure of the logical document of a PDF file that can be used as a stored FRF work envelope 38. Also, an exemplary PDF stored work envelope is shown in Appendix A illustrating the construction and organization of the documents. PDF objects described later. At the root of the FRF 38 work envelope is an object of type / Catalog 50 that includes an indirect reference to the root of the Tree of Pages 52 as well as a reference to a file containing the stored work schedule (ie the entry ticket to work 32). The Page Tree 52 is not an object per se, but represents a single object or a hierarchical tree object of type / Pages. Objects of type / Page 54a, 54n form the leaf nodes of the Page objects. Page attributes that are not specified in / Page object are inherited to a parent / Pages object. On the other hand, if the same attribute is specified in both of the objects / Pages and / or Page objects, the value of the attribute in the object / Page exceeds the value in the parent / Pages object. This inherited property is useful in the organization of the pages according to the attributes they share through their ancestral objects / Pages. Each object / page contains an indirect reference to an object of type / Content 56 that describes the content of the image on that page. The object / content typically requires resource objects to successfully form a page image. For the fast reprint format (FRF) of the present invention, there are mainly two resource objects that will be used, namely an object of type / Object X and subtype / Image 58, and a Private PDF object of type / Obj etoXERX_X and the subtype / PrintImageXERX_ 60. The object / object X 58 describes the attributes of the DRI 36 and includes the data of the DRI as well. Object / ObjectXERX_X 60 is equivalent to Object / ObjectX but encodes private data and references to PRI 34 data in an external file through a dictionary / AttrdeArchivoXERX_X (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 previously sketched but it is accessed along with the object / catalog 50 through a queue dictionary located at the back end of the PDF file. The following is a discussion of the content of key PDF objects that are required for the envelope of the FRF file 58 of the present invention. The object / Info 62 contains a dictionary of the pairs of key values shown in Table 1.

Table 1: Pairs of Key Values for the object / Info in the queue dictionary The pairs of key values shown in Table 2 are included in the root object of type / Catalog 50.

Table 2: Pairs of Key Values for the root object type / Catalog The dictionary associated with the work ticket flow object 32 contains the pairs of key values presented in Table 3.

Table 3: Pairs of Key Values for the dictionary associated with the flow of the XERX WorkTicket Key Type Value / Type name / Entrance Ticket to XERX Work 3: Pairs of Key Values for the dictionary associated with the flow of / Entrance Ticket to Work_XERX (CONTINUED) Each dictionary in / Attrde_XERX_File that codes for the location of the Work Ticket file contains the key value pairs discussed in Table 4.

Table: Pairs of Key Values for the dictionary of / AttrdeArchivo_XERX for the File Entrance Ticket to Work Key Type Value / XERX_P 1st element arrangement: Relative path sequence name of Table 4: Pairs of Key Values for the dictionary of / AttrdeArchivo_XERX for the File Entry Ticket to Work (CONTINUED) Each dictionary of the object / Page 54 contains the pairs of key values presented in Table 5.

Table 5: Pairs of Key Values that are included or inherited by the object dictionary / Page Key Type Value / Type Name / Page / Parents Dictionary Indirect reference to the parent object / Dictionary Resources See below.

/ CajaMedia Array [0,0, X / y]: Size of the image dimensions expressed in points (1 point = 1/72"(0.035cm)) where xyy are the dimensions in the slow scan and fast scan directions , respectively.

/ Contents Flow See below.

Each dictionary of / Resources contains the key pairs presented in Table 6.

Table 6: Pairs of Key Values that are included or inherited by the / Resources dictionary / ObjectX Dictionary If the DRI is present: «/ DRI < flow object number > » The flow object encodes DRI data. See later. If the DRI is absent: «/ DRIAusente < flow object number ». The flow object encodes AAbsent DRI = message. See later / ObjectX_XERX Dictionary «/ PRI < flow object number > » The flow object encodes PRI image data. See later / ProcSet Fix The procedure sets the requirements to form the image of the page.

It should be noted that the < flow object number > it is a variable that denotes an indirect reference to a flow object.

The user has the option of suppressing the generation of DRI when presenting the work to be stored. In this case, it is necessary to indicate to the user that a DRI is not available for the page or selected pages. This is discussed later. Each DRI flow contains the key value pairs discussed in Table 7.

Pairs of Key Values for the dictionary associated with the flow of / ObjetoX 58 Key Type Value / Type name / ObjectX / Subtype name / image / Width Number Number of pixels in the entire slow scan direction.

Table 7: Pairs of Key Values for the dictionary associated with the flow of / ObjectX 58 (CONTINUED) Key Type Value / Height Number Number of pixels in the entire fast scan direction.

/ ComponentBy Number Number of bits per component Bits integer = 8 / SpaceColor name The color space in which the DRI was created. For most printers, it is probably the / CMYK Device.

/ Name filter The compression scheme adopted to compress the DRI data. / DecodeDCT / Dictionary parameters If required. Decoding ./Length Number Length in bytes of the entire data of the flow.

In the case 'where DRIs were not created for a job, instead of including the image data for a DRI, this object will include the data of a universal image that indicates that the DRI is absentA = or not availableA = for that page. Typically, the image data file will be installed in DFE 22, and included in the PDF 38 envelope for a job where the user has chosen to suppress DRI generation. The advantage of this method to indicate an absent DRI is that the reader or PDF editor is not required to support any alphanumeric characters at all to view or edit the FRF job. The cost of this method describes the greater effort required to build and install the missing DRI imageA = and, if there is no universal symbol for absentA = or not 'availableA =, it may be necessary to build multiple images and the appropriate image included in the packages of localized language. Only an / ObjectX that contains the image data for an absent DRIA = is constructed in the PDF 38 envelope. The object of / Content 56 of the page that has not been associated with the DRI will make an indirect reference to this / ObjectX. In this way the image data for an absent DRIA = will be included in a PDF envelope file only once. The dictionary associated with each PRI image stream contains the key value pairs discussed in Table 8.

Pairs of Key Values for the dictionary associated with the flow of / ObjectX_XREX 60 Each dictionary of / AttrdeArchivo_XERX that codes for the location of the PRI image files contains the pairs of key values exposed in Table 9.

Table 9: Pairs of key values for the dictionary of / AttrdeArchivo_XERX for PRI image files The first element of the key / XERX_F provides the name of the relative path of the image file, while the second element provides a path that produces the alternative (in this absolute case) for the image file. When the job is presented for fast reprint, DFE 22 will first try to find the image using the name of the relative path. If this fails, it will try to find the image using the absolute path name. If this also fails, an inability to resolve file reference will arise. In the preferred mode, only two path names are required for the PRI file. However, the arrangement of ordered sequences associated with the key / XERX_F can include as many elements as desired. In this case, DFE 22 would try to find the PRI file in the specified places in the ordered sequence of the array in the first element and continue along the array until finding the desired PRI file. The attributes and contents of the flow / content object are as follows: the dictionary associated with the flow of / content consists of an entry that corresponds to the specification of the length of the flow using the key / length. The flow of the object / content of an object / page that has an associated DRI is constructed as follows: i) the flow begins and ends with the operators of the PDF Aq = and AQ = that store and restore the current graphic state. If necessary, a concatenation matrix will be included below. The operator of the concatenation matrix is described later. The PDF operator ADo = will execute an operand that is a named image. This named image is identical to the name of the image in the object of the type of / ObjectX. Referring now to Figure 6, once a print job has been stored, such as when it is stored on a storage disk 70 associated with the DFE 22, a PDF reader tool can be used to view the DRIs of the job. saved and browse through the pages of the job. In addition to the View of a Work, modifications of stored or saved work can be made through the use of a PDF 72 editor tool. In particular, a PDF 72 editor tool provides the ability to reorder and delete pages in a single job. Note that although it is the reordering of the DRI that is being changed, the printed output of the modified stored job will reflect the new order of the page since the PDF file will be created in such a way that the reference to the associated PRI image will always move with the DRI. Note that this functionality is supported by Acrobat Exchanged. In addition, the PDF editor provides the ability to open multiple jobs and insert pages from one job into another. Again, although it is the DRIs that are being inserted, the references corresponding to the PRI images are also inserted and continue to be associated with the inserted DRIs. Note that this functionality is also supported by Acrobat Exchanged. An improvement to the basic PDF publishing functionality is provided by a Work Entry Ticket Connection 74 that interprets the entry ticket to the reference work 32, and thus presents the modification of the work program attributes. That is, that the PDF 74 connection, associated with the DFE 22, is capable of recognizing the private PDF marks that are included within the PDF envelope 38. The connection has the ability to locate and encode the contents of the work schedule file (ie the entry ticket to work 32) and graphically present the work schedule of the stored job. It should be noted that if a Ticket to Work connection 32, the associated entry ticket will not be updated. In this way, it would be the user who would have to change the work schedule when the FRF work is presented edited for reprinting. The advantages of using PDF as the envelope of the stored job are more evident when you are viewing a remote job (ie in a different place than the UI 24 of DFE 22) and is considered the editing workflow, as shown in Figure 7 '. A browser at the workstation of the client 12 loads the necessary stored work envelopes 38 together with the associated work ticket entry files 32 from the stored repository 70 in the DFE 22 to the workstation disk of the local client 76 using the option to save as Asave As = in the browser. In this way, in order to see both the images and the job scheduling information, a remote observer is required to load both the envelope of the stored job and the entry ticket to work. It is necessary for the user to save or store the envelope 38 and the associated ticket entry file 32 in the same folder or directory, and also that the entry ticket to work should not be renamed. These restrictions are necessary, so the entry reference to the work ticket for the stored work envelope is valid. Alternatively, if the client has access to the network file system (NFS) to the saved repository 70, direct access to the saved job envelope 38 can be accessed. DFE 22 supports jobs stored in multiple places including, for example, the Local controller disk 70, a disk mounted on an NFS, or other portable disks connected to the controller through a SCSI connection. However, the stored or stored jobs that are being created on disks other than the local controller disk 70 are subject to a probable performance degradation due to 1/0 bandwidth limitations. Once the necessary files are available on the workstation of client 12, the PDF 72 editor with connection 74 (the version appropriately ported by the platform of the client workstation) or a third party tool can be used to see and edit by much in the same way as with the UI 24 associated with the DFE 22. Once any editing on the loaded 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 compares the DRIs 36 in the work associated with the corrected PRI image data 34. One strategy for transferring a modified work back to the DFE 22 is to copy the modified work by removable means 78 (Figure 7) initially connected to the client's workstation. The media can then be removed and mounted in the DFE 22 and the modified stored work copied to the storage tank 70 in the DFE 22. The modified work can then be reprinted either in the DFE 22 or in any of the monitoring stations. work of the customer 12. Note that the modified stored work can be placed anywhere in the storage bin 70 and not necessarily replace the original stored job. In addition, modified stored work does not necessarily need to be copied to the same storage bin, but can be printed directly from the removable media, although this is likely to cause performance degradation. Although the above provides a mechanism for transferring a modified stored job back to the storage tank 70, it is not convenient for the user in a client workstation. An easier workflow may involve an HTTP download to the controller (i.e. DFE 22) as described in detail below with respect to a further embodiment of the present invention. Nevertheless, this requires some level of authentication and authorization mechanism in the DFE 22. In the absence of an HTTP download, the modified stored job may be presented for printing through a job submission tool 80 in the workstation of the client 12 and will be treated without differentiating from any other work. This workflow is different from the HTTP download in two aspects: i) it may be necessary to build and present a new entry ticket to work, based on the content of the entry ticket to the stored work loaded through the channels of the Internet Printing Protocol (IPP) normal, and ii) the stored and modified work will be deleted once the printing is completed successfully. It is conceivable that the user at the client workstation can load a stored job from a DFE and insert it into a stored job loaded with another DFE. If the two DFEs do not share a common repository, a modified stored job containing images of both DFEs will fail when presented for reprinting on any of the DFEs. In this case, it is not necessary to copy the stored jobs required from one DFE to another before attempting to load the stored jobs for editing and subsequent presentation of the job. If desired, the PDF envelope file can be presented for printing to any cheaper printer A = or not addressed to A = as the input PDL type. Since the envelope is a legitimate PDF file containing low resolution DRI, this will result in a low cost draft A = of the content of a FRF job. The production of data with the PRI is generally calculated based on the knowledge of the production characteristics of the Image Output Terminal (IOT). In this way, the PRI 34 created by a combination of DFE-IOT (22, 18) may not be printed at all, or may be printed with a poorer image quality, in another DFE-IOT combination. However, the DRI 36 format remains independent of the DFE-IOT combination, as mentioned above, it is a format that conforms to Adobe PDF Specification 1.3. To solve this problem, it was contemplated that when a print job is presented to a DFE with the Store provision, the DFE will decompose the PDF file creating the PRI and DRI for each page. Concurrently, the DFE will create and update the PDF envelope in which each page is decomposed. The PDF envelope will include the DRI and will include private PDF marks indicating 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 marked. Once the last page is decomposed, the work schedule will be stored in a work ticket file and the PDF file updated with private PDF marks to be printed to the work ticket file. When the stored work is observed, the PDF connection module will have the ability to locate and decode the content, the work schedule of the stored job as well as the target DFE-IOT combination. When a stored job is dictated, an attempt is made to insert pages of a PDF envelope that is directed to a first DFE-IOT combination, in a PDF envelope that is still directed to a second combination of DFE-IOT, the PDF connection module will send an error message and will prohibit this operation. When a stored job is submitted to be reprinted quickly, the directed DFE will recognize the specific PDF marks in the PDF envelope and, instead of decomposing the DRIs with the PDF envelope, 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 presented by the PDF envelope. If it is affirmative, the PRI is presented to the marking machine. Since no decomposition is required, this will result in a rapid reprint. In addition, the DFE will also locate the associated job scheduling file and apply job scheduling. If not, the DFE will fail at work and indicate the DFE-IOT combination to which the PRI is directed. In the case where the print job is presented to the DFE 22 from a network-based client workstation such as one of the work stations 12 of Figure 1, the end user based on the network will present a job through of a secure channel established with the network server 26 (Figure 1). The network server authenticates the end user, determines if a valid count exists, communicates with the print server that then sends the job to the appropriate DFE-IOT combination based on the schedule of the requested job. Once the job is successfully stored in a warehouse (for example, storage depot 70, the print server notifies the end user that the job is ready for a flexible test.) Subsequently, the user connects, subsequently with the server. printing, is authenticated once again and is granted access only to those stored jobs that resulted from previous work presentations of those end user accounts.The end user can then do a flexible test of the work (ie see the DRI included in the PDF 38 envelope and see the work schedule stored in the Work Ticket 32 file) to verify that the work was built by the work schedule presented The end user also has the option to download a private copy of the work. stored work, manipulate it by deleting pages, rearranging pages, inserting pages from another stored work, and change some parameters of the work schedule and verify the effects of those modifications. The end user can then present the modified private copy of the stored work for one or more printed copies, or instruct the print server to print one or more paper copies of the original stored job. An appropriate commercial model can be used to deliver the copies to the end user. The end user also has the option to keep the jobs stored in the deposits and be billed for this service accordingly. The end user has the option of requesting hard copies of a job stored later and being guaranteed to obtain printed copies that are identical within an adequate tolerance of the first set of printed copies requested. Note that it would be necessary to implement some improvements to the capabilities of the existing platform to implement this client-server model based on the network. For example, the architecture allowing the associated workflow consists of a HyperText Transfer Protocol (HTTP) 26 server that supports a security protocol such as Secure Socket Layer (SSL) technology. This server is responsible for the communication with the clients based on the network of a printing shop (for example the place where the document processing apparatus 14 is located). The HTTP server communicates with a print server (such as a PrintXchanged print server) that handles and controls one or more DFEs, which are connected to IOT. The HTTP and print servers and the DFE are networked (such as by the Network File System protocol) to a stored job repository (such as the repository 70). It should be noted that the above description of the components is a logical view, not a physical one. In all likelihood, the HTTP and print server will reside on the same platform of physical computing components. In the case where a print shop has only one DFE, the three components of the programs and programming systems, namely the HTTP server / print server and the DFE can reside solely on a platform of physical computing components such as the document processing apparatus 14 of Figure 1 To initiate a transaction from a client workstation based on the network, an end user uses a browser to connect to a Uniform Resource Locator (URL) address that makes available client presentation programming and programs based in the network and the programming programs and systems of connection of the entry ticket to the PDF work. In addition, the client must have a PDF editor application loaded on the client platform as well. It is also possible that the printing shop can make those components of the programs and programming systems available to the client. The customer also establishes an account and obtains the necessary ID and password from the print shop. When a print job is presented to be stored using the web-based presentation client, the end user enters the ID and password of the account and presents a job to the HTTP Job Server 26 in the print shop over a secure connection , such as using the Secure Connection Layer (SSL) technology.

The job typically consists of a Page Description Language (PDL) file along with the associated job schedule. The HTTP server authenticates the user and communicates with the print server that then sends the job to the appropriate DFE, based on the schedule of the requested job, which may include an intended target DFE-IOT specification such as the DFE- IOT 22, 14. DFE 22 decomposes the PDL file and creates a DRI 36 and PRI 34 for each page. Concurrently, DFE 22 creates and updates a PDF 38 envelope as each page is broken, the job's programming will be decoded and included within the PDF enclosure included along with private PDF marks that indicate the location of the job's programming within the PDF envelope. After executing some accounting tasks, the PDF 38 envelope will be completed. The PDF 38 envelope thus constructed will conform to the specifications of the latest Adobe PDF. Note that since the PRIs 34 are stored external to the PDF envelope 38, the PDF envelope 38 is compact in relation to the size of the PRIs 36. The PDF envelope 38 and an associated PRI set 34 of the stored job is stored in the repository. storage 70. Once the store operation is completed, DFE 22 notifies the Print Server which, through the HTTP server, notifies the end user that the stored job is ready for a flexible test. After receiving the notification, the end user connects to the HTTP server 26 and enters the ID and password. The HTTP server 26 authenticates the user once more and presents a list of stored jobs that the user with the specified ID is authorized to see. This list contains only the PDF 38 envelopes but not the associated PRIs. The end user then selects the appropriate PDF envelope to view (the PDF envelope is named after the name of the PDL file in the work originally presented). The end user chooses to download the file and launches the PDF editor application (which also serves as a viewer) with the PDF Connection 74, to view the stored work. Note that only the relatively compact PDF envelope is downloaded, but the large PRIs continue to remain in the stored store 70 in the print shop. In fact, access to the end user is never allowed to last. The PDF reader presents the DRI 36 within the PDF 38 envelope and, due to the connection of the PDF 74 Job Entry Ticket, the effects of certain job scheduling will also be observable such as the horizontal and vertical deviation of the image, inserts , beginning of chapter, positioning of staples / seams and jumps.

As with the above embodiments, there is a limited number of editing operations that a user can perform on the stored work through manipulation of the PDF envelope. These are page-level editions, such as reordering pages, deleting pages, and inserting archived stored work pages from the end user in 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 rearranged by the editor, the Private PDF marks associated with the DRIs 36 that point to the corresponding PRIs 34 will be moved with the DRIs 36. In addition, the connection of the Entry Ticket to Work 34 allows the user final load the work scheduling parameters (restricted only to those that are not related to production) - this list includes finishing options, paper size, plexus, jump, inserts, chapter starts, horizontal and vertical deviations of the image . The implication of the PDF editor with the connection of Entry Ticket to Work presents the end user with the effects of any changes in the work scheduling parameters. Once the end user is satisfied with the flexible test of the changes made, the end user can present the PDF envelope file, through the web-based presentation client to the HTTP server of the print shop 26. Although the mechanism for the presentation remains the same as for the presentation of a work of printing with the storage facility, DFE 22, when it eventually receives the job, recognizes the private PDF marks and the existence of associated PRIs, and will not attempt to decompose the PDF envelope. Although another PDF envelope is created that is intended for the storage repository 70, it is very similar to the PDF envelope presented; the last one is deleted when the work is completed. The PDF will not create any PRI because all the PRIs referred to within the presented PDF envelope will already exist in the storage repository. If the flexible test satisfies the approval, the end user connects to the HTTP server 26, and subsequently the authentication and authorization process described above requests the printing of a certain number of printed copies of the selected PDF envelope files. Information options associated with such delivery are also provided. The HTTP server 26 sends the print request to the print server, and the print server in turn sends the request to an available DFE-IOT combination. The important restriction is that the combination of DFE-IOT can not be different from one in which the stored work was originally created. Once delivered successfully, an appropriate billing model is used to bill or charge to the account of the end users. The end user can choose to delete the stored jobs or can choose to archive them in the print shop in the case of. that additional copies are required in the future. The print shop is expected to implement a billing model based on the size and length of the stored jobs and possibly other debit or billing parameters to the end-user account accordingly. If the end user has chosen to archive the jobs stored in the print shop, hard copies of any of the stored jobs of the end user can be requested at some later time by following the above process to request the printing of a job stored after a job. flexible approval Since no redisposition takes place in the printing and the PIs are in the printer-ready format, the output printed at any subsequent time will be of the same quality as the first printout of the requested printout within the tolerance specifications of the printed materials. DFE-IOT. Finally, local copies of the PDF 38 envelopes can also be achieved 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 to the client's HTTP server. In addition, the end user can also choose to print a draft print of the PDF envelopes on an unmanaged, locally available printer. When the PDF envelope is presented to this printer, it will not recognize private PDF marks and will decompose the lower resolution DRIs in the PDF envelope. This results in what is considered to be an impression in draft mode. The invention has been described with reference to preferred embodiments. Obviously, modifications and alterations would occur to others after reading and understanding the preceding detailed description. It is intended that the invention include all those modifications and alterations as long as they fall within the scope of the appended claims or equivalents thereof. For example, it is recognized that when the storage container is backed up or archived with a mass storage unit such as a tape unit, it is more expedient to transfer the files comprising the stored print job (i.e. the envelope of the file, ticket entry ticket to work, PRI), as a single file or data stream instead of transferring the files separately. Consequently, it was contemplated that the PRI and / or the entry ticket to the work can be included within the envelope of the file by the DFE before being archived.

APPENDIX A% PDF-1.3%% This file is an example of how it can be created % PDF wrap file for a job stored with% Fast Print Format. %% The content of the file does not necessarily reflect the % actual content of the PDF surround file, nor is % mandatory any specific encoding order% of PDF objects. %% For demonstration purposes, this file is a % file of two pages where a DRI is present for % the first image and absent for the second image. However, typically, any of the DRIs will be % present for work or none at all when % created a PDF surround file. To conserve % space, a small black and white image was used % for the DRI, which was subsequently amplified. %% This file is legitimate (conforms to PDF1.3) and is % full. It was tested with Acrobat Reader / Exchange% 4.0.

The Information Object% 1 0 obj «/ Author (adegani) / Creationdate (D: 20000501150000-05 '-00') / Producer (Product Name Xerox) / Title (example.ps)» findeobj%% In this example, it was assumed that the first page contains% a DRI. % The Page Object. % 2 0 obj «/ Type / Page / Origin 3 0 R / Resources« / ObjectX-XREX «/ PRI 4 0 R» / ObjectX «/ DRI 5 0 R / DRI_print 6 0 R» / ProcSet 13 0 R »/ Contents 7 0 R »findeobj%% Note that the / DRI_print is a small% identification image that will be displayed on the% lower left corner and indicates that the DRI% presented is a" special "image that will be printed at% full resolution and without reprocessing of% frame input (without stamping), but it will be printed in% "draft" mode (with stamping) or any other% printer. % The PRI image object ready to print. % 4 0 obj «/ Type / ObjectX_XERX / Subtype / XERXPrintFile / XERXFileAttrick« / XERX_F [(example.ps.dr / example.ps.pOOOOl .pri) (/var/carrete/MySave/example.ps.frf/example .ps.dir / example.ps .pOOOOl .pri)] / XEfile Size X 113413 / NumVol 1_XERX »/ Length 0» findeoflow flow findeobj%% The Display Resolution Image object. % In this file, only a small image% is being used to conserve space. % 5 0 obj «/ Type / ObjectX / Subtype / Image / Width 24 / Height 23 / BitsByComponent 1 /Color Space / GrayDevice / Filter / DecodingHexASCII / Length 165» flow 003B00 002700 002480 0E4940 114920 14B220 3CB650 75FE88 17FF8C 175F14 1C07E2 3803C4 703182 F8EDFC B2BBC2 BB6F84 31BFC2 18EA3C 0E3E00 07FC00 03F800 001800 00F800 > finaldefjojo findeobj%% The .object of Content. % 7 0 obj «/ Length 61» flow q 500 0 0 500 0 0 cm / Make D I Q 0 0 0 50 0 0 cm / Make DRI_find endoffluxfinishbj. %% In this example, it was assumed that the second page does not contain a DRI. %% The Page object. % 8 0 obj «/ Type / Page / Origin 9 0 R / Sources« / ObjectX_XERX «/ PRI 10 0 R» / ObjectX «/ DRIAusente 11 0 R» / ProcSet 13 0 R »/ Content 12 0 R» findeobj%% The PRI image object ready to print. % 10 0 obj «/ Type / Obj etoX_XERX / Subtype / XERXPrintImage / XERXFileAttribute« / XE X_F [(example .ps.dir / example.ps .p00002.pri) (/var/carrete/MySave/example.ps .frf / example .ps .dir / example .ps .p00002.pri)] / XEfile Size X 234312 / NumVol 1_XERX »/ Length 0» findeoflow flow findeobj%% The image indicating a DRI for this page is not available. % In this file, the image shows an "X" (which% means not available) and once again a small image is used which is subsequently amplified. % 11 0 obj «/ Type / ObjectX / Subtype / Image / Width 24 / Height 23 / BitsPorComponent 1 / ColorSpace / GrayDevice / Filter / DecodingHexASCII / Length 165» flow 800001 400002 200004 100008 080010 040020 020040 010080 008100 004200 002400 001800 002400 004200 008100 010080 020040 040020 080010 100008 200004 400002 800001 >; endflowflowfindeobj%% The content object for the DRI is absent% 12 0 obj «/ Length 37» flow q 500 0 0 500 0 0 cm / Make DRIAusente Q findeflowflowfindeobj%% The image / objettoX for the stamping identifier% 6 0 obj «/ Type / ObjectX / Subtype / Image / Width 16 / Height 11 / BitsByComponent 1 /Color Space / GrayDevice / Filter / DecodingHexASCII / Length 56» flow 074F 8FBF C7F E37F E5FF F3FF FOFF E47F CE3F 9FIF 0EF > findeoflow% findeobj The ProcSet object. % 13 O obj [/ PDF / ImagenB] findeobj%% The hierarchy of the Pages objects. % The Pages object. for all pages that contain% DRI. % 3 0 obj «/ Type / Pages / Origin 14 0 R / Count 1 / Types [2 0 R]» findeobj%% The Pages object for all pages that do not contain DRIs. % 9 0 obj «/ Type / Pages / Origin 14 0 R / Count 1 / Types [8 0 R]» findeobj%% The Pages object for all pages% 14 0 obj «/ Type / Pages / Count 2 / Cashbox [ 0 0 612 792] / Types [3 0 R 9 0 R] »findeobj%% The Root Object% 15 0 obj« / Type / Catalog / Pages 14 0 R / Entry Ticket to Work 16 0 R »findeobj%% The object of the Ticket Entry. % 16 0 obj «/ Type / Entry Ticket to Work_XERX / XERX File_Attring« / XERX_F [(example.ps. Jt) (/ var / reel / MySave / example ps.frf / example.ps. T)] / File Size_XERX 1098 / NumVol 1_XERX »/ Length 0» findeoflow flow findeobj »% xref 0 17 0000000000 65535 f 0000000818 00000 n 0000001036 00000 n 0000004111 00000 n 0000001564 00000 n 0000001949 00000 n 0000003728 00000 n 0000002312 00000 n 0.000002519 00000 n 0000004249 00000 n 0000002721 00000 n 0000003206 00000 n 0000003589 00000 n 0000003980 00000 n 0000004359 00000 n 0000004469 00000 n 0000004573 00000 n queue «/ Size 17 / Root 15 0 R / Info 1 0 R» comenzartxref 4780 %% EOF It is noted that in relation to this date, the best method known by the applicant to carry out the aforementioned invention, is that which is clear from the present description of the invention.

Claims (24)

1. CLAIMS Having described the invention as above, the content of the following claims is claimed as property. A method for generating a print job, characterized in that it comprises the steps of: a) decomposing the print job into print resolution image data image data of the display resolution for each page of the print job; b) generate an enveloping file and an entry ticket to the work; c) include the data of the display resolution image in the envelope file; d) include in the wraparound file indicators of the indication of the print resolution image data; e) store attribute data for the print job in a work ticket file; f) include indicators of the location of the entry ticket to work in the envelope file; and g) store an envelope file, the entry ticket to work, and print resolution data in a storage bin. 2. The method according to claim 1, characterized in that step c) includes the step of: h) including the resolution and display image data in the envelope file when each print job page is decomposed; The method according to claim 1, characterized in that step d) includes the step of: h) including in the envelope file indicators of the location of the print resolution image data when each print job page is decomposed. The method according to claim 1, characterized in that 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 file entry ticket to work. 5. The method according to claim 1, characterized in that step b) includes the step of: h) generating an envelope file conforming to specification 1.3 of the Adobe Portable Document Format. The method according to claim 1, characterized in that step g) includes the step of: h) storing the print resolution image in a storage bin in a compressed format after the frame entry processing. The method according to claim 1, characterized in that step g) includes the step of: h) storing the envelope file, the entry ticket to the job, and the print resolution data in an associated storage repository with a front end to the digital input of a digital color copier. The method according to claim 7, characterized in that it further includes the step of: i) displaying the display resolution image data included in the envelope file in a user interface associated with the front end or a digital input. The method according to claim 7, characterized by the step of: i) presenting the display resolution image data included in the envelope file at the workstation communicating with the digital front end. The method according to claim 7, characterized in that it further includes the step of: i) editing the envelope file in a user interface associated with a digital front end. The method according to claim 10, characterized in that step i) includes the step of: j) at least one of the reordering, insertion and deletion of the display resolution image data included in the envelope file in an interface of user associated with the digital front end. The method according to claim 7, characterized in that it also includes the step of: i) editing the envelope file in a workstation communicating with the front end or digital input. 13. The method according to claim. 10, characterized in that step i) includes the step of: j) at least one of the reordering, insertion and deletion of the resolution or display image data included in the envelope file at a workstation communicating with the digital front end . The method according to claim 1, characterized in that it also includes the step of: h) presenting the data of the display resolution image included in the envelope file with a PDF visualization tool. 15. The method according to claim 1, characterized in that it also includes the step of: h) editing the data of the display resolution image included in the envelope file with the PDF editor tool. 16. The method according to claim 1, characterized in that it also includes the step of: h) presenting the data of the attributes of the print job that are stored in the ticket file to work with a PDF connection tool. The method according to claim 1, characterized in that it also includes the step of: h) editing the data of the attributes of the print job that are stored in the ticket file to work with the PDF connection tool. The method according to claim 1, characterized in that it further includes the step of: h) including data indicative of a document processing apparatus addressed in the print resolution image data. The method according to claim 1, characterized in that it further includes the step of: h) printing the envelope file in an unprocessed document processing apparatus to generate a draft copy of the stored printed job. 20. The method according to claim 1, characterized in that it further includes the step of: h) editing at least one of the envelope file and the entry ticket file to the work of a client workstation based on the network. The method according to claim 1, characterized in that it further includes the step of: h) printing the print resolution data that is stored in a storage bin. 22. The method of compliance with the claim 1, characterized in that it includes the step of: h) printing the print resolution data in the same order as the display resolution data included in the envelope file. 23. The method according to the claim 1, characterized in that it also includes the steps of: h) editing the envelope of the file to rearrange the display resolution data; and i) printing the print resolution data in the same order as the reset resolution display data. 24. The method according to claim 1, characterized in that it also includes the steps of: h) editing the entry ticket file to modify the job attributes of the stored print job; and i) print the print resolution data with the modified job attributes.