The invention relates to a system for the automatic generation of printable files from data in a database, said system comprising a printing system consisting of at least one print processing component, whereby the print processing component has means for printing and/or further processing the files.
The invention also relates to a method for the automatic generation of printable files from data in a database, according to which method the files are generated, printed out and/or further processed by a printing system consisting of at least one print processing component and one print job generation element.
The generation of printable files is acquiring increasing significance since ever-greater volumes of print objects are being generated electronically, further processed and printed out in a wide array of application areas. In particular, there is a need to generate individualized mailpieces by electronic means and to subsequently print out and further process them.
For example, postal service providers offer numerous services in the letter and mailing realm that go well beyond the mere sending of letters and parcels. Such a system supports the entire production process for documents that are printed and that are to be sent out. With the growing significance of electronic mail, this also holds true in the realm of e-mail communication and Internet-based logistics.
In this context, components of a system designed for such procedures serve various purposes. On the one hand, they serve as a receiving interface and production system for letter mailings that are ultimately printed on paper and that are delivered to the recipients by mail. On the other hand, system components with interfaces offer a direct transfer capability for messages via electronic means. Thus, the sending and delivery can be carried out through e-mail and web protocols.
A number of production-related obstacles have to be overcome in order for users to make use of these options. This ranges from the design of a mailing and the acquisition of target group addresses to the actual serial printing, including quality control. Even when specialized service providers such as letter shops and printing centers are used, the creation of mailings still proves to be quite a complex process. Multiple media discontinuities and heterogeneous interfaces or approaches among all kinds of intermediates involved make the process expensive and complicated for small mail volumes. For large-scale mailings, it is time-consuming and technically complicated.
In order to print and further process print jobs within a printing system, various print processing components such as printers, sorting and enveloping machines or other processing devices are typically used. This leads to multi-faceted possibilities in terms of hardware combinations and job sequences, each requiring a special print preparation.
Print preparation methods for all kinds of requirements are known from the state of the art. DE 199 21 120 C2, for example, describes a method and a system for the signature-wise imposition of printing data within a POD (Print On Demand) system. This involves the printing and folding of printed sheets, a process in which the printed images of consecutive pages are positioned so as to match precisely.
Furthermore, DE 100 17 785 C2 describes a method and a system for processing a data stream in which the data stream is prepared to be output by a printing device. Here, a print data stream that is present in a first print data format is converted into a standardized data format and the print data stream thus converted is indexed on the basis of prescribed indexing criteria. The indexed print data stream is then sorted in a sorting sequence according to sorting parameters and the sorted print data stream is output for purposes of further processing, especially for being printed out.
In actual practice, the problem often arises that print jobs are transmitted to different printing systems, whereby each printing system requires a different print preparation. This is particularly the case when, for example, a postal service provider receives data for print jobs from users of a service system designed for this purpose, stores this data in a central database and transmits the command for the execution of the print jobs to its own system components or to printing service providers. Typically, each printing service provider has its own specific printing system with different software and hardware components. In order for the user jobs to be prepared uniformly and to be transmitted to the particular printing system of the service provider once the data has been received by the postal service provider, the postal service provider has to know all of the specifications of the commissioned printing service provider. This, in turn, calls for extensive hardware and software on the part of the postal service provider.
DE 198 17 878 A1, for example, discloses a method and a device for producing, wrapping and enveloping printed mailings. Here, the party ordering a print job produces the print data and transmits it via a network to a printing means, where the transmitted print data is printed out. The ordering party produces the print job on his personal computer, which is connected to one or more central computers. The central computers are connected to servers that can be located, for example, in different cities or countries. The ordering party selects a server with free printing capacity and transmits the print job to this server. This print job is executed fully automatically on the selected server, whereby the server preferably has another personal computer and a printing means. The print job is stored on the personal computer and it controls the printing means and its various components such as paper rolls and gluing machines as well as printing, cutting, wrapping and folding units.
Moreover, DE 101 23 488 A1 describes a printing system for printing a plurality of jobs in one system having a plurality of processing stations. Each of the processing stations is used to render the documents into a ready-to-print file format and to issue an electronic job ticket containing global document properties. In this case, a customer transmits an order for objects to be printed either directly in paper form, on a data carrier or else via the Internet.
DE 101 22 880 A1 discloses a method for the automatic generation of printing instructions. For this purpose, a user enters instructions at a computer in response to which the computer places a plurality of received documents into an electronic folder and arranges the documents in the folder in the desired order for the printed final product. Here, a customer's job for objects to be printed is likewise transmitted to the printing system either directly in paper form, on a data carrier or else via the Internet.
The invention is based on the objective of creating a system that allows a printing system to receive data from a database outside of the area of the printing system and to automatically generate printable files on the basis of this data as a function of the specific requirements of the printing system.
It is likewise an objective of the invention to provide a method for the automatic generation of print jobs from data in a database by a printing system in which the database is located outside of the area of the printing system.
According to the invention, this objective is achieved by a system for the automatic generation of printable files from data in a database, said system comprising a printing system including at least one print processing component, whereby the print processing component has means for printing and/or further processing the files, said system comprising the following features:
The objective is also achieved by a method for the automatic generation of printable files from data in a database, by means of which the files are generated, printed out and/or further processed by a printing system consisting of at least one print processing component and one print job generation element, and the method includes the following steps:
The printing system is, for example, a system at a service provider comprising printers, sorting and enveloping machines and/or other processing devices. According to the invention, a print job generation element that can be connected to a server is installed in such a printing system. The server, in turn, can be connected to a database containing data for print jobs to be generated. The database is located outside of the printing system and typically comprises large volumes of data. This data comes, for example, from users of a service system of a postal service provider who have placed orders for print jobs for mailings.
The print job generation element according to the invention is typically a program that is preferably installed on computers of the printing system. The term “computer” here is not to be understood in any limiting manner. This can be any unit that is suitable for executing computations such as, for example, a work station, a personal computer, a microcomputer or circuitry that is suitable for executing computations and/or comparisons.
In an especially preferred embodiment of the invention, the print job generation element in the form of a first interface can be connected to a SOAP server via a SOAP interface. The abbreviation SOAP stands for Simple Object Access Protocol. SOAP is a communication protocol for access to individual program modules on the Internet. SOAP is a lightweight protocol with which proprietary modules can be packaged and provided with generally understandable interfaces. SOAP specifies how a function procedure call takes place with XML data via computer platforms (Remote Procedure Call). Advantageously, a connection to the server is possible via the Internet, but other connections are also possible. These can be temporary or permanent connections.
According to the invention, the server can be connected to at least one database via a second interface. In an especially preferred embodiment of the invention, a PL/SQL layer is used for the connection between the server and the database. The abbreviation PL/SQL stands for Procedural Language/Structured Query Language. This is a proprietary programming language, for example, for Oracle, that adds procedural constructs and control possibilities to the non-procedural SQL. Via the server, data from the database is transmitted to the print job generation element, said data containing, for example, templates, variable data, personalization instructions and other information about the print jobs that are to be produced.
The print job generation element produces print jobs from the received data and automatically generates printable files. In this process, the print job generation element describes how the files are to be prepared for a certain paper/hardware combination. This includes, for example, information pages for the personnel, control characters for an enveloping machine, crop marks, paper formats, the production of RIP tickets for printers, SDL control characters, conversion instructions and instructions on how the data is transported to a printer.
The data in a database constitutes jobs from users pertaining to the printing of mail-pieces. Jobs from users are referred to below as UserJobs, whereas the resultant print jobs are designated as PrintJobs. Since the UserJobs produced by users can be of greatly varying sizes, and since advantageously, the Print Jobs should be neither too large nor too small for purposes of optimal production, it has proven to be practical to divide large jobs and/or to combine several small jobs into larger ones. For this purpose, special preference is given to the implementation of a mechanism that automatically divides large jobs.
Additional advantages, special features and practical refinements of the invention can be gleaned from the subordinate claims and from the presentation below of preferred embodiments making reference to the figures.
The figures show the following:
Printing service providers typically have different printing systems with specific requirements for different print processing components 14, whereby the print processing components can comprise, for example, printers 11, sorting machines 12 and/or and enveloping machines 13. Consequently, according to the invention, a print job generation element 15 is used for the specific preparation of data in the area of the printing system 10. The print job generation element 15 is typically a program that is preferably installed on one or more computers of the printing system 10.
In order to allow the print job generation element 15 and thus the printing system 10 to access the contents of a database 30 outside of the area of the printing system, and in order to automate these steps, in an especially preferred embodiment of the invention, a client-server architecture was selected that uses SOAP as the communication medium via the Internet. For this purpose, the print job generation element 15 is connected via a first SOAP interface 40 to a SOAP server 20 outside of the area of the printing system. This first interface is preferably realized via the Internet 60. However, other types of connections can also be selected and these can be temporary or permanent connections.
A SOAP interface has the advantage over proprietary communication protocols such as CORBA (common object request broker architecture) or RMI (remote method invocation) that, for example, during the data transmission, no conflicts occur with a firewall of the print job generation element 15 and/or of the printing system 10. SOAP preferably uses HTTP/HTTPS as the data transmission protocol. HTTP/HTTPS is either permitted through most firewalls or else it is tunneled via proxies, so that it is not necessary to adapt the firewalls and no new points of attack are created. Moreover, by using a SOAP protocol that uses the HTTP protocol as the basic transport protocol, a simple transmission via the Internet is possible.
All of the methods that the print job generation element 15 needs in order to receive all of the necessary information from the database 30 for a print job are provided via the SOAP interface 40. Advantageously, the system is secured against outside access. The system can be secured in different ways. For example, an authentication of the print job generation element 15 at the server 20 can be employed. Moreover, it is advantageous to use HTTPS (HTTP Secure) as the transmission protocol.
In an especially preferred embodiment of the invention, access of the SOAP server 20 to the database 30 is carried out via a PL/SQL layer 40. In this manner, it is possible, among other things, to protocol all database accesses or to set certain attributes. This has the advantage that consistency of the database can be ensured.
It has proven to be advantageous to execute all status changes in the print job generation element without establishing a connection to the Internet and to then send the executed changes to the server. This has the advantage that the print job generation element only has to have a temporary connection to the Internet, and can operate even without a permanent Internet connection.-An Internet connection only needs to be established for the merging operations with the server.
Furthermore, an advantage of the system according to the invention is that updates for the configuration of the print job generation element can be stored centrally on the server. In an especially preferred embodiment of the invention, the print job generation element checks at the start whether any updates are available and it updates its configuration automatically from the central server via JavaWebStart.
It is also especially advantageous to execute the actual communication via SOAP through an Apache SOAP API. The abbreviation API stands for Application Programming Interface, and it is an interface specified by an operating system or an application program by means of which standardized software tools are made available to other applications. Hence, an API allows an application program to use a function and/or services of another software. In contrast to a file interface, an API is a so-called call interface. The advantages of using an API lie, for example, in the reduction of programming work and in a uniform user interface and mode of operation.
Method calls via SOAP appear as XML messages that are sent via HTTP.
In detail, the SOAP call appears using the Apache SOAP API as shown by way of example in
A TargetObject-URI method corresponds, for example, to an unambiguous URI that is associated on the server side in the RPC router with a certain object (in the case of the example here, with the SOAP server).
A mapTypes method is preferably called several times so as to be able to transmit its own classes (for example, UserJob, User) via the SOAP.
The method name can be specified via a setMethodName method, and a list of parameter values can be set via setParams.
An invoke method carries out the actual call via SOAP. A first message 16 is generated and this is then sent to the server 20 via HTTP.
It has proven to be advantageous that, on the part of the server 20, first of all, a web server 21 accepts the query and evaluates it. The web server can be, for example, Tomcat. In order to allow a successful SOAP call, a sent URL has to be associated with the Apache SOAP API's RPC router-servlet where the server-SOAP object is known. The call is transmitted to this servlet. The abbreviation URL stands for Uniform Resource Locator. Via a URL, all documents in the Internet can be unambiguously addressed.
The RPC router-servlet then analyzes the SOAP message, determines the class to be called and instantiates it. Then the desired method with the transmitted parameters is called. The possible return value is then, in turn, converted into a second SOAP message 17 and this is returned as a response via HTTP. The call object 18 on the client side analyzes this message and returns the obtained result to the print job generation element 15. In case of an error, a failure object can optionally be queried here.
If a print job generation element 15 calls a method on the SOAP server, then, in an especially preferred embodiment of the invention, it can use a ServerProxy class. A proxy server accepts requests from a client and returns them—optionally modified—to the original destination.
Such a sequence is shown in
The SOAP response message is analyzed and
The appropriate methods then convert primitive data types, which are returned as objects, into the appertaining primitive data type and then return said date types. Thus, for the particular print job generation element, the SOAP communication is not transparent but rather the ServerProxy 22 behaves as if it were calling local methods (except for the longer runtimes of the methods).
In an especially preferred embodiment of the invention, the RPC (Remote Procedure Call) is selected for the communication. RPC provides a remote procedure call. Within the scope of this concept, each server in a network makes a number of services available that can be called with RPC. These functions are implemented as procedures of a program and can be addressed by indicating the server address, program number and procedure number. RPC offers the possibility of transmitting method calls and their parameters in a simple manner. This does not specify the transmission of entire XML trees as a parameter or return value. In the case of the SOAP server, preferably an expansion of the SOAP API of Apache is used, which specifies how XML trees can be transmitted via the SOAP RPC. Thus, UserJobs can be transmitted as method parameters via the Apache SOAP API.
The SOAP RPC protocol also offers the possibility to transmit simple data types such as strings or integers. However, complex data types can also be transmitted in structs or arrays which, in turn, consist of simple data types.
Various complex data types (for example, LogicalProduct, User, UserJob) are typically transmitted during the communication between the print job generation element 15 and the server 20. In order to be able to transmit these data types in the SOAP RPC protocol, methods are advantageously implemented that convert the classes as SOAP structs and vice versa (serialization/deserialization). However, this step is simplified by the Apache SOAP API in that it provides a class that offers this functionality for all classes that comply with a JavaBeans specification. This is why the three data classes are advantageously implemented on the basis of the JavaBeans specification and can thus be transmitted via the SOAP API in a simple manner. JavaBeans are a portable platform-independent component model that is written in Java.
Below, an especially preferred embodiment of a print job generation element that is installed in a printing system is presented by way of an example. Especially advantageously, the realization of the print job generation element is in the form of an XML configuration. Such a configuration can control the entire production sequence for the printing. The operation advantageously takes place via a graphic user interface by means of which, for example, actions can be initiated and parameters can be entered. The printable files can be transmitted automatically to a production printer.
By means of the print job generation element, a printing system can transfer orders assigned to it, for example, from a mailing system to its own local systems and it can report back to the mailing system about the processing status. As a local application, the print job generation element assumes the central function of preparing the print data. The preparation of the print data can comprise, for example, the following functions:
The configuration of the print job generation element advantageously consists of modules, virtual printers and settings.
General settings such as, for example, paths and communication parameters, are configured in the settings. The parameters can be changed by means of a user interface of the print job generation element. The following table lists the meaning/function of a few possible setting parameters by way of example:
In order to generate printable files from a PrintJob XML file, it has proven to be advantageous to provide a PDF kernel. The way in which the printable files are produced is described by a configuration language. The kernel is informed by the interface of only one PrintJob XML file and one virtual printer to be used.
In order to generate print data, the print job component receives job data consisting, for example, of a template in PDF format and variable data for the personalization and meta-information in XML format. Making use of an external PDF library, which can be located, for instance, in the database 30, the print job generation element finally generates completed PDF files. The generation technique depends on the job data and on the hardware-independent meta-information such as, for example, the size of the print job, sorting according to postal criteria, routing slip instructions for the postal delivery and/or attachments. It is also carried out as a function of hardware-specific meta-information such as imposition, performance optimization and/or specific barcodes that are configured in the virtual printers.
The generation technique also depends on how the processing is defined. Therefore, the print job generation element is also an interpreter that derives its logic from a processing file, preferably in XML format. For instance, if a print job generation element is supposed to be able to generate folding greeting cards with text on one side rather than generating postcards, then merely the processing file has to be adapted. This is carried out at a central place in the mailing system and, at the time of the next start-up, the change is automatically transmitted to the print job generation element so that the print job generation element can now generate greeting cards with text on one side.
The possibilities for producing a document are very multi-faceted and depend on several factors such as the original format, desired colors, paper format to be printed, final processing and printers employed. In order to describe how a document is to be produced for a concrete case, the term “virtual printer” has been introduced. A virtual printer describes the prerequisites under which a document can be produced with said printer and how the document will be prepared for this concrete case.
It is possible that different documents can be produced with the same virtual printer, for example, color as well as black-and-white documents could be generated with a color printer following the same preparation. It is possible for different virtual printers to use the same physical printer for the printing, for example, documents having the original format of DIN A4 can be printed on DIN A4 as well as on DIN A3 with a subsequent post-production. The two cases call for different preparation of the files and thus have to be prepared with different virtual printers. However, both virtual printers can send the files to the same physical printer if the latter is capable of printing DIN A3 as well as DIN A4.
The virtual printers are generated in the configuration and processed step-by-step by the PDF kernel during a PrintJob production.
At the start of the production, the kernel is informed about the virtual printer to be used. Then the PrintJob XML file is read in, from which the internal data structures that are needed for the further production are built up.
During the entire production, the production kernel ascertains which side of the letter is on the produced pages of the PDF documents. A CreateTemplatePDF function can be used to generate the static part for the production. For this purpose, empty pages have to be personalized. When these personalized pages are imposed, the kernel ascertains where the individual letters will be positioned. The personalized PDF file can be changed at will. This includes, for example, adding pages, changing the page sequence, adding texts and lines and performing the imposition. Only imposed files may not be imposed once again. Once the personalized PDF file (variable part) has been completely processed, CreateTemplatePDF can be used to generate a matching static PDF file. Here, a PDF file is generated on the basis of the PDF templates of all of the UserJobs and all of the necessary combinations appear once in this PDF file. For the later generation of a job ticket for a production printer, a data structure is built up that describes which variable page fits with which static page.
Attributes of CreateTemplatePDF are, for example, the following:
A Condition function can be used as an attribute for some functions so that these are executed under certain conditions. The following instructions evaluate the Condition: “AddText”, “AddLine” and “NewPDF”. The condition under which the instruction should be executed can be specified by indicating a keyword.
The following keywords, for example, can be implemented:
Within a SendToPrinter function, a rip ticket can be created, the PDF files can be converted and the completed files can be sent to a printer.
A CreateRipTicket function configures how a rip ticket is to be created. As an attribute, the file name has to be set with the destination name. Within CreateRipTicket, several Line descriptions are created in combination with DataLines. The Data attribute is set within Line. All of the texts of Line are written consecutively into the rip ticket file. In doing so, given variables are replaced. Repeat loops and loops can be built in at any desired place.
With a UserJob having the ID 10000105, in which eight variable PDF pages are formed, for example, the following rip ticket file is generated:
With a Convert function, the PDF files can be converted, for example, into a format such as PostScript. Possible attributes of Convert are:
With a NewPS tag, the print job generation element is instructed to convert a PDF file, for example, into PostScript. Tags are separator characters for command information in HTML. An attribute of NewPS in Convert can be InputFileName:
With a SendFile function, files can be sent directly to a printer. Possible attributes of SendFile are the following:
Any number of virtual printers can be set up in the configuration of the print job generation element. With a virtual printer, it is possible to configure which jobs can be processed with this virtual printer and how the documents are to be generated. A virtual printer has, for example, the following set up:
The attributes of VirtualPrinter can be, for example, the following:
With PrintJobConditions, it is possible to regulate which jobs can be produced with this virtual printer. Here, name-value pairs can be indicated, whereby the name must match a UserJobAttribute. The value in Value indicates which value the attribute must have so that the UserJob can be produced with this virtual printer. As soon as a condition does not apply, the UserJob cannot be produced with this virtual printer. UserJob attributes that are not indicated under the PrintJobConditions can be as desired.
Within PrepareJobDocuments, any number of PrepareDocumentSteps can be set up. These steps are carried out consecutively in order to produce the documents.
Within PrepareDocumentStep, it is described how a PDF document is generated. This document can also be used in further steps as the template. Loop, Repeat and NewPDF can be used within PrepareDocumentStep. It is also possible to indicate a module whose content is executed as follows:
Modules can also be created on the level of settings and VirtualPrinter. These modules can be referenced by several PrepareDocumentStep entries in various virtual printers.
Within a Loop, all of the commands contained therein are repeated. The number of repetitions is a function of the setting of AddressesPerPly in the virtual printer and of the number of addresses in the PrintJob (NumberOfPieces). The loop is repeated as often as AddressesPerPly fits into NumberOfPieces. If there is a remainder, this is advantageously rounded off.
Loop is used, for example, to execute “hidden JobSplitting”. During a loop pass, a variable LoopNo is set in each step. This variable can be used to generate various document names.
Repeat can be used to execute instructions multiple times. The number of repetitions can be parameterized. During the pass, the variable RepeatNo is set. The attributes of Repeat are, for example, the following:
A new PDF document can be generated with NewPDF. Within NewPDF, instructions have to be given as to how the PDF document is to be generated. The following instructions, for example, are possible within NewPDF: “Repeat”, “WorkFlow”, “PersonalizeOnTemplate”, “Personalize”, “CreateTemplatePDF” and “OpenpDF”.
NewPDF can have the following attributes:
It has proven to be especially advantageous to use WorkFlows which describe how a document is to be generated. Within WorkFlows, for example, VariableData, Merge and Impositioning can be allowed. WorkFlow advantageously has no attributes. If several WorkFlows are created consecutively, then they are processed, for example, consecutively, whereby the result of a WorkFlow always serves as the source of the next WorkFlow.
A PersonalizeOnTemplate command causes a new PDF file to be created in which several letters are consecutively located that consist of the PDF template and that are personalized with the data records from the variable data. The number of letters depends on the AddressesPerPly attribute. In order to generate letters for all of the variable data, PersonalizeOnTemplate has to appear within Loop. As a result, several PDF files are formed, each with a number of AddressesPerPly letters. If the number of addresses is not precisely divisible by the AddressesPerPly, then the remaining letters are located in the last PDF file. If there are different UserJobs in the PrintJob, then the PDF template that matches the appertaining address is used automatically.
In order to classify mailpieces, InfoPost criteria are normally specified that can comprise, for example, InfoLetter, InfoPost or Standard. If such an InfoPost criterion is set during the personalization, then only addresses that have the corresponding InfoPost criterion are processed.
An example of this is shown below:
By means of the instructions above, several PDF files are formed in Temppath with the new_ID_x_Pers_y name and having the following meaning:
The sum of all letters from the various InfoPost criteria at a value of X equals AddressesPerPly or rather the remainder of the division.
It is also advantageous to have a Personalize function that functions like PersonalizeOnTemplate, except that the personalization is not carried out on the PDF template but rather on a new empty document. Attributes of “personalize” can be the following, for example:
An OpenPDF function causes a PDF file to be opened. In the case of further instructions, this file serves as a source. An attribute of OpenPDF is, for example, Filename:
It is also advantageous that, with VariableData, additional data can be applied to a PDF document. Here, the current document which was either opened by OpenPDF, stemmed from the preceding WorkFlow, or else was most recently created during the momentary WorkFlow then serves as the template. For this purpose, a page range has to be indicated. On this page range, the commands stored within VariableData are executed. “AddText”, “AddSDL”, AddLine” and “AddOMR” are possible within VariableData.
Attributes of VariableData are, for example:
Functions such as StartPage and EndPage can also be used for mathematical instructions. For example, the following symbols can be supported:
Here, EndPage=“last/2+1”, for example, causes the pages to be processed up to the middle of the even-numbered pages.
Within VariableData, an AddText function can be used in order to add a text:
A function AddLine can be used within VariableData in order to add a line between two points:
An AddOMR function can be used within VariableData in order to add OMR control characters on pages:
Here, a “line” tag has to be added for each control character line within AddOMR.
An EmptyPageInsert function inserts, for example, one or more new empty pages. Possible attributes are:
Various PDF files can be merged by means of a Merge function:
Within Merge, the documents that are to be inserted are advantageously indicated with InsertPDF. Attributes of InsertPDF can be, for example, the following:
An Impositioning function is advantageous in order to determine how a document is to be imposed. Within Impositioning, any desired number of pages can be described. The page description specifies which pages from the original document are positioned on the new pages. The page description is preferably passed several times, whereby in each case, the original page to be taken is calculated once again. The number of passes depends on the values in Signature, Increment and on the number of original pages. It is preferably passed as often as the number of pages fits into Signature*Increment (rounded off).
Possible attributes for Impositioning are the following:
In this context, attributes for AddPage are:
Different variables can be accessed within the configuration of the print job generation element. These variables can be used to generate a document name and different texts in new documents. The variables are set at the beginning of or during the production, depending on their function.
For purposes of local data management, it is advantageous to have a QueueManager in the printing system 10 according to the invention with an installed print job generation element 15. It manages the necessary information such as, for instance, status, files and/or attributes, for all UserJobs and PrintJobs. For this purpose, the QueueManager preferably uses a hierarchical data structure. Every time there is a change, this data structure is stored by the QueueManager on a storage medium such as a hard disk so that all of the information is still available after a new start of the system. The path can be configured, for example, via a QueueManagerPath attribute in a configuration file (PSSConfiguration.xml). In the path, the QueueManager creates a path for each of the UserJobs and PrintJobs in which the corresponding XML files are stored.
An example of a QueueManager is shown below. The outermost container is always called QueueManager. In it, there are two containers: PrintJobs for all PrintJobs and UserJobs for all UserJobs.
An example of a data structure that the QueueManager creates for a UserJob can be seen in the following table:
During the synchronization with the SOAP server, the attributes are queried by new UserJobs. With these attributes, the QueueManager creates a new UserJob. In this process, the following approach, for example, is taken:
Possible virtual printers result from the configuration in a PSSConfiguration. All printers are inserted whose PrintJobConditions do not exclude attributes of the UserJob. The PrintJobConditions are stored for each printer in the structure. If, in the further course, one of more PrintJobs are generated on the basis of the UserJob, then the appropriate UserJobIDs are entered in the PrintJobs container. For each change, for example, in case of status changes, the LastChangeDate attribute is reset by the QueueManager. If the UserJob is downloaded, then DowloadedDate is set and the downloaded XML file is stored in the UserJob path.
An example of a data structure that the QueueManager creates for a PrintJob can be seen in the following table:
If a PrintJob is created from one or more UserJobs, then the QueueManager creates the appropriate PrintJob container. In this process, the following approach, for example, is taken:
For each subsequent change in the PrintJob status, the LastChangeDate and the corresponding Percentage are updated.
When a PrintJob is generated, a new PrintJob XML file is created on the basis of the UserJob XL files. This function is carried out, for example, by a RecreateXML class.
The UserJob XML file contains, for example, UserJob attributes, company data, item data and UserJob files. In an especially preferred embodiment of the invention, the UserJob files are Base64-encoded. Base64 is an encoding that is used by the MIMENCODE program in MIME standard to convert binary data into an ASCIT subset.
The RecreateXML class comprises all of the UserJobs into one JOBTRANSFER-ENVELOPE. The UserJob attributes, company data and item data are taken over unchanged by each UserJob. The files with the print instructions and the variable data are changed by RecreateXML. The remaining files are taken over.
If a UserJob is divided into several PrintJobs, the variable data is divided into records. Each PrintJob receives one of these records.
The print instructions of the UserJobs can have the following format, for example:
RecreateXML preferably uses an address formatter on the basis of which it generates print instructions that are understood by the PDF kernel. The print instructions for the above-mentioned file in the PrintJob file look, for example, like this:
In the UserJob XML file, the variable data looks, for example, like this:
Using the allocation in the Print Instruct file, Recreate XML generates the following on this basis:
In this manner, the personalization during the production yields the data that is available in a form in which the PDF kernel can use it directly.
The QueueManager administers the status for all UserJobs, PrintJobs and Plys. The QueueManager is notified of status changes by a data model of an interface. Here, for example, the following status can occur:
It has also proven to be advantageous for the QueueManager to set a Percentage attribute in case of status changes with the UserJobs and PrintJobs. This attribute indicates the completion of the UserJob in terms of a percentage. This value is transmitted for each UserJob during the synchronization with the server 20. The status of the UserJob and PrintJob in conjunction with the percentage of the completion are shown in the following table:
It is especially advantageous if users of the print job generation element 15 according to the invention can use a user interface to oversee and control the production within a printing system 10. The interface can be implemented, for example, by using Java Swing. The data for the interface is administered, for example, by a DataModel class that queries the QueueManager in order to ascertain values.
It is also advantageous for a user to be able to log in, log out and end the program via a menu in the SOAP server. These functions are preferably made available in a toolbar. During log-in, for example, a dialog box can be opened in which the user name and the password are to be entered. With this information, the system attempts to log into the SOAP server via an AuthenticateUser method from the ServerProxy. If the log-in is successful, then the user information is stored in the data model. This user information is employed for further communication with the server. In case of an error, it as advantageous for a dialog box with an error message to appear.
It is advantageous to implement a “log-out” function that deletes user information from the data model so that no communication is possible with the server without logging in once again. Another “log-out and end” function checks, for example, if production threads are still running. If there are still threads, another query is launched asking whether the program is to be ended. The program is ended, for example, with System.exit(0).
Via a ComboBox, for example, three different views of the UserJobs can be created. For all views, there are inner model classes in the main frame class (FrnApplication). The main frame initializes several ChangeListeners that set the possible actions in case of a change in the UserJob selection and in case of a UserJob status change. The possible actions are queried from the data model. The data model derives the possible actions from the status of the selected UserJobs that is queried by the QueueManager.
Via the UserJob menu, UserJobs can be downloaded, converted into PrintJobs, canceled, set at not-producible, reset and produced with a wizard. All actions can be launched via a toolbar. The possible actions depend on the status of the selected UserJobs.
The allocations between UserJob status and possible action are compiled in the following table:
The consequences of the UserJob actions are compiled in the following table:
The use of a production wizard is especially advantageous. The production wizard groups all of the selected UserJobs according to products. If no UserJob was selected, then all UserJobs are used. For purposes of grouping, the wizard uses, for example, the PRINT_MODE, PRINT_COLOR and PRINT_FORMAT attributes. The following table shows the wizard products and their attributes:
The view of the PrintJobs can likewise be made selectable via a ComboBox. The views and the action handling are implemented as with the UserJobs, but with the difference that the values for PrintJobs are queried by the QueueManager.
The possible actions depend on the status of the selected PrintJobs. The allocation between PrintJob status and possible action is compiled in the following table:
The following table shows the consequences of the PrintJob actions:
An advantageous embodiment of the invention is also that a user can perform synchronization via a server menu and reset the local cache.
If a synchronization is performed, the print job generation element first uses the ServerProxy to send to the server every status and the degree of completion as a percentage value of the local UserJobs. If a UserJob has the status CANCELED, FAILED or DELIVERED, the QueueManager is subsequently instructed to delete these local jobs. After the status transmission, the print job generation element queries all downloadable “exportable” UserJobs. If a downloadable UserJob is not yet present locally, then the QueueManager is instructed to create it. Then the attributes of this new UserJob are queried by the server and the QueueManager is notified. If an error occurs during the querying of the attributes, the QueueManager is instructed to set this UserJob at NOT_PRODUCIBLE.
In the next step, the print job generation element queries the list of already downloaded UserJobs from the SOAP server. If UserJobs that were already downloaded are no longer present locally, the UserJobs are newly created via the QueueManager and downloaded. This can take place, for example, if the local files of the QueueManager are deleted. If there are local UserJobs that are not in the list of downloaded UserJobs, then these UserJobs are deleted locally.
When the local cache is reset, to start with, all of the PrintJobs are eliminated. Then all of the files that are managed by the QueueManager are deleted. After the restart of the QueueManager that now takes place, a synchronization is performed in which, however, the transmission of the status to the SOAP server does not occur.
In an especially preferred embodiment of the invention, all of the errors that occur within the print job generation element are displayed to the user in a dialog box. Moreover, the errors and the date are preferably stored in a log file. The file is called, for example, error.log and it is located in a path that is indicated in the configuration under errorpath.
Preferably, all of the information used for the production is stored in a JobEnvironment. Here, to start with, all of the UserJobs contained in the PrintJob are stored in data objects of a UserJobData class. These data objects offer access to all of the UserJob data that is of importance for the production. In order for the total number to become known, the number of addresses, pages and sheets for all of the UserJobs is added and stored.
JobEnvironment analyzes how many letters are intended for each InfoPost criterion, namely, InfoLetter, InfoPost or Standard. A data object of a Letter class is generated on the basis of each address. For the further production sequence, JobEnvironment makes methods available in order to query certain information via the UserJob.
The Letter class contains information for a letter. This includes, for example, personalization information, the number of letter pages, the InfoPost criterion, the UserJobID and the position within the UserJob. The JobEnvironment manages a list with letter objects for all letters.
Preferably, an object of the UserJobData class contains all data of a UserJob. This includes all UserJob attributes as well as information about postage, price and company. The JobEnvironment has a list of UserJobs with all of the UserJobData objects of the job. The UserJobData class offers methods to access the UserJob information.
In order to manage the PDF page content, it is advantageous to use a PageContent class. Objects of this class describe for a page which letters are located on the page in which position. It is possible for several letters to be located on one page after the impositioning has been carried out.
Preferably, a DocumentContent hash table is used to manage the page content for each PDF file. In it, the file names and a list of the PageContent are stored for all of the PDF documents. These are preferably generated by a PDFLayer. The information serves for generating an OMR and SDL and for generating a PDF template with static content.
It is also advantageous that a PDF template with the static contents for an existing PDF file with personalization data can be generated at any desired place. In this process, it is checked which template pages are needed. In VariableToTemplateMatch, it is recorded which personalized pages belong to a static page. The information might be needed for a later generation of a book ticket. The VariableToTemplateMatch is entered in VarToTemplateMatchArray for each loop pass.
After the JobEnvironment has been set, the printable files are generated by the PDF kernel on the basis of the virtual printer that is in the configuration. For this purpose, in an especially preferred embodiment of the invention, the kernel has several levels. On the top level (JobHandler), the virtual printer is selected, the PrintJob is read in and the JobEnvironment is initialized. Then the JobHandler incrementally processes the PrepareDocumentStep entries of the virtual printer. On this level, the NewPDF, Loop, Workflow, Personalize, CreateTemplatePDF, PersonalizeOnTemplate, Repeat and OpenPDF entries are recognized and, as a function of the keyword, a method of the next level is called. On the next level (DocumentHandler), the instructions present within the above-mentioned entries are evaluated. The entries that are present in these entries are evaluated by another level (PDFDocument). PDFDocument uses PDFLayer to open and generate the documents.
In an especially preferred embodiment of the invention, an external PDFLib library is incorporated in order to generate and read in the PDF files. This library allows a quick generation of PDF documents by means of function calls. Existing PDF pages can thus also be inserted into new PDF documents. Access to this library preferably takes place via a PDFAccessLayer. In this manner, the remaining code is independent of the library and, in case of a transfer to another library, only the layer has to be adapted.
The layer is also responsible for setting DocumentsContent in the JobEnvironment. Every time a new PDF file is created, an empty PageContent is created and the JobEnvironment is informed of this with the file name. During the personalization, the PDFLayer is informed as to which letter page is being placed. The PDFLayer generates an appropriate PageContent and gives it to JobEnvironment. Every time an existing file is opened, the PDFLayer retrieves the page content (PageContent) from the JobEnvironment. When a page of this device is copied into a new document, the PDFLayer computes the position of the page on the new page and thus generates a PageContent.
In order to convert the PDF files into PostScript, it has proven to be advantageous to use a DLL pdf2ps_java under C. This DLL can address, for example, the Adobe Acrobat and Acrobat Reader programs. The DLL opens the programs and instructs them to convert a PDF file into PostScript. The DLL is loaded by the Pdf2PsNativeInterface class. The Pdf2PsConverter class uses Pdf2PsNativeInterface and makes a conversion method available.
Number | Date | Country | Kind |
---|---|---|---|
102 54 055.1 | Nov 2002 | DE | national |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/DE03/03789 | 11/14/2003 | WO | 5/18/2005 |