WO2008104496A1

WO2008104496A1 - Method, printing system and computer program for automatically processing order support data of a print job

Info

Publication number: WO2008104496A1
Application number: PCT/EP2008/052129
Authority: WO
Inventors: Thomas Harms; Armin Gnaedig
Original assignee: OCé PRINTING SYSTEMS GMBH
Priority date: 2007-02-28
Filing date: 2008-02-21
Publication date: 2008-09-04
Also published as: DE102007009737A1; DE102007009737B4

Abstract

The invention relates to a method, a printing system and a computer program for automatically processing order support data of a print job. With the invention, incoming order support data of a print job is centrally analyzed in a print job manager by means of predetermined ticket rules, and optionally supplemented by additional print parameters, so that the order support data is used to form a printing system-specific job ticket, with which the print job can be correctly printed in the respective printing system. The central analysis of the order support data in the print job manager allows simple management of the ticket rules and, due to the proximity to the print server and the printing devices connected thereto, very printing system-specific processing of the job tickets.

Description

Method, printing system and computer program for automatically processing job-related data of a print job

The invention relates to a method, a computer program and a printing system for automatically processing order-related data of a print job.

In Digital Printing, Technology and printing techniques of Oce digital printing presses, 9 ^th edition, February 2005 (ISBN 3-00-001081-5) is an order distribution system (ODS) described in section 18.2, which is also known as the Workflow Manager , With this Order Distribution System, the entire digital printing process can be controlled, including a prepress, a

Includes high performance printer and finishing. In pre-press, image and text files from different sources, such as scanners, digital cameras, data carriers or a computer network, are brought together and finalized at a layout station. Subsequently, a printer driver converts the data created on different platforms, for example, into postscript files. These files can then be forwarded to a print server for printing. Print servers convert the data into compressed bitmaps, which are automatically imposed and forwarded to the printing system. The print server controls the printing process. The finishing of the printed product includes, for example, the binding or insertion of release sheets. The Order Distribution System is also responsible for the central administration of the production variants. This includes the printing service for intranet and internet users. The Order Distribution System informs users about approved production variants

Print jobs together with a digital job bag, causes automatic processing until printing. The Order Distribution System also monitors the correct execution of the selected printing and finishing options.

The Order Distribution System processes so-called job tickets. A job ticket is a file, in a specific data format, that contains control parameters for controlling the printout of print data of a print job. The job ticket can be used by the user when creating the

Print jobs or automatically created in a printing system.

Traditional job tickets have clear instructions that must be implemented accordingly. The printing process is becoming more and more extensive, as more and more devices are integrated into a printing process, causing the

Functionality increases. In addition, Internet and intranet print processes are increasingly regionally distributed or assigned to a pool of printers that can be regionally distributed. In addition, devices from different manufacturers increasingly have to work together in one process. In order to cope with these increased requirements, a uniform specification for the exchange of data formats in the printing process has been agreed, which is referred to as the Job Definition Format (JDF). There is a corresponding one for this

Job message format (Job Messaging Formats or JMF) specified accordingly. The specification of JDF can be downloaded from the website www.cip4.org, which is currently the current specification JDF Specification Release 1.3. JDF is an XML-based format in which the instructions for the printing process are arranged in a tree structure. Each node of the tree structure includes an instruction or set of instructions. The top one

Node is called root. The end nodes at branches are called leaf nodes.

The peculiarity of JDF is that there may be so-called intent nodes, which contain a very general instruction for a printing process that needs to be specified in order to be executed on a device.

DE 10 2004 047 327 A1 or the corresponding US 2007/0291300 A1 discloses a method in which the JDF format is used for the stepwise specification of a print job.

From EP-A2-1 197 838 a method for processing print jobs in a network is known in which it is checked by means of a job ticket whether a print service provider has the resources required to process the print job.

US 2002/0080400 A1 discloses a method for a document processing system in which a document processing job can be processed several times in different ways. How the document processing job is processed in detail is controlled by different job tickets. The special feature of this known method is that the different job tickets can be controlled by means of a master job ticket, which is also referred to as a super job ticket, all at once, so that the multiple document processing jobs by means of Master job tickets can be posted at once in the document processing system.

US Pat. No. 5,718,520 discloses a method for editing job tickets in which, when a particular control parameter is edited, a window is generated on a display device in which all possible values that can be used for the control parameter are displayed.

Digital Printing Technology and Printing Techniques of Oce Digital Printing Presses (cited above) disclose a server system known by the trade name Oce PRISMAproduction that processes or converts a wide range of data streams which are then printed on IPDS printers. The Oce PRISMAproduction server system includes a print manager PJM (see chapters 15.2.4 and 18.2) with which print jobs can be created on any customer client and edited and managed in this server system. Of the

Printj obmanagers is also referred to as a print job manager.

The term "server" refers to software modules that perform a central task: "Clients" are software modules that are connected to a server and receive data from or transmit data to the server. One server can have several clients in contact at the same time.

In this known client / server system, print jobs are generated by the clients. A print job includes the print data to be printed and a job ticket that includes control parameters for controlling the print data printout. The print jobs can come from different sources. The incoming print jobs are checked and, if necessary, adjusted on the clients upstream of the print job manager. This adaptation may include data or information accompanying the print job, with the content of the job ticket being adapted to the print environment. It is also possible that, for the first time, a job ticket is created on the print order manager from the data accompanying the print job and a default ticket available at the print manager. The format of any incoming job tickets is usually okay, but often contains parameters that are not usable or even lead to contradictions. For example, job tickets often contain printer names that are not present in the existing printing system. To correct such erroneous job tickets computer programs are provided on the clients, which automatically control the job tickets and correct if necessary. These computer programs are programmed as scripts individually for the individual clients and their applications. It is also customary for a number of such scripts to be provided on a client in order, for example, to revise different sources or job tickets with print data in different data formats. These scripts have proven to be very effective, as they automatically check and correct the incoming print jobs so that the entire printing process can run without delay.

Nevertheless occurs an error due to a wrong one

Parameters in the job ticket during the printing process, it is difficult in the present design of the printing system to determine where and by what the error has been caused. For this purpose, it must be understood on the one hand, via which client the print job to the

Print job manager has been fed, and then it must be determined with which script the job ticket has been edited. Even if this is established, it is often difficult to parse the script as to whether it caused the error, or if it caused the error when creating the print job at the customer or when transferring the print job to the client.

DE 102 35 124 A1 discloses a method in which already used and screened print jobs can be reused and modified. The "old" print jobs are located on a control device of a printing device. They can be retrieved from a client, with the client requesting the appropriate job ticket from the printing device. This job ticket is then reworked by the client, with instructions inserted to insert the changed pages, so that the unaltered pages from the old print job can be accepted at the printing device and only the pages to be replaced are rasterized.

The invention is therefore an object of the invention to provide a method, a printing system and a computer program for automatically processing order-related data for a printing process that allows automatic control of the job tickets without delay of the printing process and yet easy to understand and handle.

The object is achieved by a method having the features of claim 1, a printing system having the features of

Claim 15 and a computer program with the feature of claim 20 solved. Advantageous embodiments of the invention are specified in the respective subclaims.

The inventive method for automatically processing order-related data of a print job, comprising control parameters for controlling the print job, in a printing system having a print job manager, one or more clients on which print jobs are generated, and a print server for feeding the print jobs to a print device, comprises the following steps:

- Receiving a print job with

Order-related data from one of the clients by the print job manager, - checking the job-related data according to predetermined, freely programmable ticket rules and outputting a press-specific job ticket, and

- Forward the print job with the job ticket to the print server.

The method according to the invention is characterized in that the checking of the order-related data according to the predetermined ticket rules is carried out centrally on the print job manager.

Since the order-related data is checked and / or controlled centrally and preferably exclusively by the print order manager, the ticket rules used for a specific print job are easy to understand, because the ticket rules are only in one place, namely the print job manager, not the print job manager State of the art, the case is available to a variety of clients and there to investigate each. Furthermore, the central execution of the check of the job-related data at the print job manager ensures that all incoming job-related data are checked or checked according to the same ticket rules and, if appropriate, modified and corrected accordingly. Furthermore, by centrally executing the checking of the order-related data, the ticket rules are to be centrally managed, whereby they are also centrally controllable and it is avoided that similar order-related data or similar errors in

Order-related data are corrected differently.

A further advantage of checking the order-related data centrally at the print job manager is that the checking of the job-related data in the process chain takes place very close to the concrete printing device, so that this check can be carried out very specifically for the respective printing device. This can significantly increase the quality of the review. In the execution of the review of

Job-related data to the clients is the problem that the clients with different

Print job managers can communicate, so that carried out a check of the job-related data to the printing devices, with the different

Print job managers can be reached, which must be adapted, which in turn is very difficult.

The central administration of the ticket rules also makes it possible to provide the operator with tools that facilitate the creation and administration of the ticket rules. In particular, it is expedient to provide a graphical user interface (GUI) in which the ticket rules can be created and managed and to provide a software module with which the syntax of the edited ticket rules is automatically checked for a correct syntax.

The central checking of the order-related data enables a uniform check of

Job-related data from print jobs coming from different sources. To explain the present invention, some terms are defined below:

A complete order contains at least one

Document processing job, especially a print job.

A print job contains at least one print file to be printed.

A total order ticket contains information about an overall order, such as Delivery address, order date, desired delivery date, etc.

A job ticket contains all the data required to process a print job. These data include control parameters that are relevant in a workflow for the print job (j ob-workflow). The job ticket is coded in a corresponding ticket format.

A default job ticket contains standard data that is suitable for outputting a print job that contains no further processing information in an existing printing system or in an existing printing environment. Such data are control parameters and may be e.g. Names or addresses of printing devices connected to the respective print server.

A data ticket is understood to mean information that is generated by a print job-generating system, for example, a MFS mainframe computer system, together with the print data. The scope of such data is very limited due to the system and its format is not standardized, which is why they are not considered job tickets in the above sense. The order-related data can include both a total order ticket, a job ticket and / or a data ticket or control parameters that are attached to a print job in a different form.

Control parameters are often inserted in the file name of the print job.

If no job ticket is attached to the print job, a print system-specific job ticket is generated on the print job manager by means of the default job ticket and possibly further control parameters and the ticket rules. However, if a job ticket is attached to the print job, the job ticket is checked using the ticket rules to determine whether it is suitable as a printing system-specific job ticket and, if necessary, changed - which is the rule - and supplemented in particular by pressure-system-specific parameters from the default ticket.

The invention will be explained in more detail by way of example with reference to an embodiment shown in the drawings. The drawings show:

Figure 1: essential parts of a printing system for carrying out the method according to the invention schematically simplified in a block diagram;

FIG. 2 shows a screen copy of the graphical user interface of the system according to the invention;

FIGS. 3 to 7: parts of the screen copy of the graphical user interface of FIGS. 2, and

Figures 8 to 17: Copies of windows of the graphical user interface for displaying and editing TicketreggeIn. With the method according to the invention, incoming job-related data from corresponding print jobs from a printer are received at a printing system

Print job manager 1 (Figure 1) automatically processed.

Print job manager 1 (DAM) is connected to several clients 2 (CL). In the present embodiment, three different types of clients are provided, namely input modules 2/1, a print job client 2/2 and a ticket rule client 2/3.

Usually, a plurality of input modules 2/1 are provided, which are each connected to one or more computers 3 (RE) for generating a print job via data lines 46.

Typically, the print job manager 1 and the input modules 2/1 are located at an operator of a printing center and the computers 3 for generating the print jobs are at the customers of the operator of the printing system and transmit their print jobs to the input via a network, such as the Internet - Modules.

The clients 2 and the print job manager 1 are each computer program units. They can be installed and run on a common computer. However, it is equally possible, and also preferred, to install and execute at least print job manager 1 and clients 2 on at least two separate computers. Interfaces 47 are provided between the clients 2 and the print job manager 1, via which data, in particular print jobs, can be exchanged.

The print job manager is also referred to as the PJM server (printjob manager server). The to Print Job Manager 1 Corresponding Print Job Client 2/2 allows the operator of the print system to execute existing print jobs. Such print jobs are, for example, print jobs that could not or could not be printed correctly. With the help of the print job client 2/2, the operator can change the print job and in particular the job ticket of such a print job and transmit the respective print job to the print job manager 1 in order to have it printed on a printing device.

At the print job manager 1, the job-related data of the incoming print jobs are supplemented with data, in particular control parameters, from a default job ticket. In particular, missing, but necessary in the existing printing environment control parameters are added to the job-related data. If one

Overall order ticket should be present, the data, in particular control parameters of the total order ticket in the print job manager 1 are added to the pressure system-specific job ticket. During further processing, the so-supplemented pressure system-specific job ticket is taken into account. In the following, the term job ticket is thus understood to mean a printing-system-specific job ticket which is supplemented by data from an overall order ticket or a default job ticket, if such exists. The print job manager 1 has a ticket rule module 4 (TRM) in which ticket rules are stored. The ticket rules are managed by the ticket rule module and executed on the print job manager.

The ticket rule module 4 has an interface 48 to the ticket rule client 2/3, via which bidirectional communication is possible. Ticket rule client 2/3 includes a rule editor module that Rule module stored ticket rules can be edited. The rule editor module is provided with a graphical user interface (GUI), which will be explained in more detail below. The ticket rule module and / or the rule editor module are designed such that edited ticket rules are automatically checked for a correct syntax. Corresponding errors are displayed on the graphical user interface and, if necessary, a correction proposal is displayed.

The ticket rule module 4 may also be connected to multiple ticket rule clients 2/3. However, all ticket rules are stored exclusively in the ticket rule module 4 on the print job manager 1. With the ticket rule clients 2/3, only the ticket rules stored in the ticket rule module 4 can be accessed and these can be changed there.

The job ticket contains a list of control parameters for controlling the respective print job. The

Control parameter list is divided into sections each provided with a name. There is a section called "files." This section may occur multiple times in a job ticket, but the other sections are provided only once, and within each section are the control parameters with a designation called "key" and a specific one For example, in the section "files" there is a control parameter with the key "File_Copies", where the value of the control parameter is an integer that defines the number of copies to be printed.

The ticket rules comprise a sequence of actions that are based on incoming order-related data of the received

Be applied to print jobs. The following actions can be performed: - condition: A value ("value") of the order-related data is compared with a predetermined value and if the result is "true" and if the result is "false", the result is: The action eise corresponds to the action condition a match the result is "false" and if it is different, the result is "true." setting: With this action, a control parameter in the job-related data is set to a predetermined value.

- variable: With the action variable a variable can be defined.

- message: The action message generates a message depending on a specific control parameter of the job-related data. rule: With the action rule, another ticket rule is called within a predetermined ticket rule, which is referred to below as a sub-ticket rule. This sub-ticket rule is called in dependence of one or more control parameters of the order-related data. - break: The break action immediately stops the execution of the ticket rule, and if the ticket rule that terminates should be a sub-ticket rule, the parent ticket rule continues. - exit: The exit action immediately stops the execution of the ticket rule. This will not continue with a parent ticket rule.

- exit and stopjob: This action immediately stops the execution of the ticket rule. It does not continue with a higher-level ticket rule and the processing of the print job is also terminated. switch / case: This action compares a value of an order-tracking data control parameter with each value specified in a first column of a table. If there is a match with one of the values, the values of the row of this table are automatically entered into corresponding data fields, in particular into a corresponding table in the ticket rule. This allows the automatic transfer of records from tables, whereby the tables outside the ticket rules can be edited with a conventional spreadsheet program.

The sequence of actions of a ticket rule can be branched as in a tree, whereby the branches are respectively executed by the conditions "condition" or "else" and the leaves of the tree are represented by actions which then occur when the respective condition occurs ( en).

With these actions, the ticket rules can be freely programmed, analogous to the client-specific scripts mentioned at the beginning. With the ticket rules, job-related data can be corrected (e.g., with setting), i.e., parameters in the job-accompanying data that are inappropriate for the existing print environment can be replaced or deleted. These actions are therefore very powerful, as they can fundamentally change the parameters in order-related data. It is even possible to cancel print jobs (exit, stopjob).

The ticket rules make it possible to check the order-related data for correctness, ie to check whether the print job can be printed correctly with the job-related data on the respective printer or printing system. This check is carried out, for example, with the action condition. The ticket rules can be used to output a message which, for example, informs the operator of an error in the order-related data or requires a specific action of the operator on the system which is necessary for the further execution of the print job, such as insertion special paper or the supply of special toner.

Although the ticket rules can be programmed on different clients, since they are stored centrally, the operator or another person who can influence the ticket rules always has access to the entire set of ticket rules. This avoids errors that occur in conventional systems in which the corresponding instructions for influencing the order-related data are stored distributed on different computers and the operator often has no overview of all rules.

Using a set of ticket rules, order-related data from different sources can be checked centrally at a single point and, if necessary, corrected. The ticket rules thus serve the central and uniform review of

Job-related data of different print jobs.

The print job manager 1 is arranged with its ticket rule module 4, in which the ticket rules are stored as close as possible to the printer or to the printers, so that the ticket rules are specifically defined for the respective printing environment. Preferably, the print job manager 1 is directly connected to one or more printers or there is only one print server each between the print job manager 1 and one of the printers. It is also within the scope of the invention possible to integrate the print job manager into the printer.

In the present embodiment, an incoming at a client 2 print job to the

Print job manager 1 forwarded, in which case forwarding or transmission of the print job from the client 2 to the print job manager 1, a function is called, which carries out the processing of the respective print job. With the call of this function, a parameter is passed from the client 2 to this function, which contains a reference to a corresponding ticket rule with which the order-related data of the print job are checked. This function therefore calls the ticket rule on print job manager 1, depending on the parameter passed

A screen print of the graphical user interface of the ticket rule client 2/3 is shown in FIG.

The graphical user interface comprises a Main Toolbar 5, a Ticket Rules drop down menu 6, a Rule Definition window 7, a Rule definition tool bar 8, and Rule definition bar 8 a rule activation list 9 (RuIe activation list).

The main strip 5 is shown in Figure 3 in an enlarged view again. It has seven pictograms 10, 11, 12, 13, 14, 15, 16. By clicking on one of the pictograms with a computer mouse, a specific function can be triggered.

The pictogram 10 stores the current configuration of the ticket rules. These changes are stored in ticket module 4. Should be on the graphic User interface changes have been made to ticket rules, they are only applied to incoming order-related data when the icon 10 has been pressed, that is, when they are stored in the ticket control module 4.

Upon actuation of the icon 11, all changes made since the last time the ticket rules were stored are discarded.

With the icon 12, a new rule is generated. The user is first asked for the name of the new rule. The new rule is then appended to the rule activation list 9 and is activated. It does not contain any actions yet.

With the icon 13, an existing ticket rule can be copied to a new ticket rule. Again, the user is first asked for the name of the new ticket rule. All actions of the copied ticket rule are copied to the new ticket rule.

The icon 14 is used to delete a ticket rule. With the pictograms 15 and 16, the ticket rules listed in the rule activation list 9 can be moved up or down by one step at a time.

FIG. 4 shows the pop-up menu 6 in the unfolded state, in which the functions explained above with reference to the pictograms 10 to 16 can be called up.

In the rule activation list 9 (FIG. 5), all ticket rules are listed in tabular form. In a first column, the activation state is indicated, in a second column the rule name and in a third column a rule description. This rule description can either be generated automatically from the existing sequence of actions or can be entered manually via a separate window. Optionally, the generated description or the self-generated description can be displayed. The manually created description is saved together with a corresponding rule.

There are three activation states: (active, inactive) and sub-ticket rule (sub-rule).

A user can specify whether a particular rule should be in the "active" or "inactive" mode. The "inactive" mode is used when a particular rule is not to be applied to incoming job tickets, which is appropriate for old rules that are not going to be used temporarily or for new rules that have not yet been sufficiently tested to define a ticket rule for later use.

In the "active" mode, a rule can be set if it is executable and not a sub-ticket rule.The individual rules are automatically checked by the rule module 4 for their executability, that is, for the correctness of their syntax If the rule is executable, it will be displayed in black in the rule activation list, but if it is not executable, it will be displayed in red in this list.

A ticket rule with sub-ticket rule mode can only be used as a sub-ticket rule, which means that it must be called by another parent rule Rule Activation List 9 shown in italics in black for executable and in red for rules not executable. Double-clicking an element in the third column (rule description) opens a window (Figure 8) for editing the rule description. If the pictogram "Ok" is clicked in this window, the corresponding rule description is adopted.

The rules definition bar 8 (FIG. 6) includes icons 17, 18, 19, 20, 21, 22, 23, 24, 25, and 14 that correspond to the

Add and delete actions to a rule definition.

With the pictogram 17, a condition definition window 26 (FIG. 10) is called, with which conditions can be edited. This will be explained below.

With the icon 18, a setting definition window 28 (Figure 11) is opened. Each setting definition includes a name, a control parameter, a value, and an override flag. A set definition serves to set a control parameter in the job ticket to a specific value. This is explained in more detail below.

The icon 19 is used to add and edit variables. Upon actuation of this icon, a variable editor window 28 is opened (FIG. 12).

The icon 20 is used to open a

Message editor window 29 (Figure 16) and allows the editing of messages.

With the icon 21 sub-ticket rules can be added. From a list of all defined sub-ticket rules one can be selected. The icon 22 is used to add the condition "eise" into a sequence of actions.

The icon 23 is used to add the action "break" into a sequence of actions.

The icon 24 is used to add the action "exit" in a series of actions.

The icon 25 is for adding the action "exit and stopJob" to a sequence of actions.

With the icon 14 in the rule definition bar 8, a selected action can be deleted from a sequence of actions.

Not only can the ticket rules be defined by adding and / or removing actions, but the actions themselves can be changed, deleted or recreated. These are different

Action definition window provided. These windows each display a list of all the present actions of a type and allow editing, adding new actions, removing actions and copying actions. Each action has a specific status. Only correctly defined actions receive the status "true", which is represented by a black font, and with a status "false" the color of the font is red. An example of an action with a "false" status would be a condition without a defined control parameter.

There are basically two ways to open an action definition window.

1. Clicking on a selected action in the rule definition window 7 with the right mouse button. 2. After selecting an action in the

Control definition window 7, a suitable icon for adding an action (icon 17 to icon 25) in the rule definition bar 8 is clicked.

The action definition window can be left by clicking on a "Cancel" or "OK" icon. The "OK" pictogram can only be selected if a valid entry of an action is selected

Action definition window has been called from the rule definition window 7 by means of a suitable add icon, the new action is added to the existing sequence of actions after the selected action. If the action definition window is called by clicking on a specific action in the rule definition window 7, the action selected in the rule definition window 7 is replaced by the new action defined.

Actions that are currently not used by any rule can be deleted. When editing an action that is used by one or more rules, a window pops up listing the names of all ticket rules that use this action and the

User is requested to confirm this as this will change the definitions of the corresponding ticket rules.

Below, the individual action definition windows are explained in more detail. Some common features and agreements apply to all action definition windows. So every action can have a specific name. This name is unique to all ticket rules and allows the actions to be called globally in all ticket rules. This means that if an action is changed with a global name, all ticket rules will be the use this action, be changed. However, an action can also be provided without a name. But then it can only be called in a single ticket rule.

Such a "nameless" action is only applied locally, with the right mouse button you can invoke a corresponding action definition window to add a new action, this window will contain a list of all global and local actions, and if such a local action is added again they are listed in this list, even if an action of the same type already exists in the list, so that the actions can be copied with the respective parameters as often as required, whereby each copy is a local action independent of the original action.

The action definition windows have a column for control parameters. This control parameter column provides a special combo box for entering a ticket section and a control parameter (key). If the control parameter column is empty and the combo box is selected, a list of all known sections will be displayed. Thereafter, the user can recall the combo box and a list of all keys of the selected section is displayed. This allows the control parameter to be selected by clicking twice without having to call up an extensive list of all control parameters. If one

Section and a control parameter have been selected, a field ".." is also offered to go back to the first mode of the combo box, which displays only the list of known sections.Also, an empty field is offered in which a new section or a new key can be entered Control parameters can be deleted from the list of known control parameters.

The action definition window for conditions, the condition definition window 26 (FIG. 10), includes a condition definition menu bar 31 and a condition definition table 32. The

Condition definition menu bar 31 includes the above-explained icons 13, 14 and 17 with the respective functions of adding, deleting and copying conditions.

Each condition contains a parameter, an operator and a value and can be given a name. The respective section and key can be from one

Each pop-up window can be selected. The offered list of keys depends on the selected section.

The operator can be selected from a pop-up window. The following operators exist:

- equal

- equal (case insensitive) - not equal

- not equal (ignore case)

- contains

- contains (ignore case)

- does not contain - does not contain (case insensitive)

- begins with

- starts with (case insensitive)

- ends with

- ends with (case insensitive) - does not exist

- less than

- greater than - Smaller or equal

- greater or equal

- is not set

- is set - is an integer

- is floating point number

- is hexadecimal number

- is ASCII code

- is alphanumeric character (A-Z, a-z) - is Alnum (A-Z, a-z, 0-9)

- is a number

- is a hexadecimal digit (0-9, A-F, a-f)

- is regex

A condition with the operator "does not exist" is

"True" if the specified key of the section should not exist in the job-related data This condition differs from "is not set", which checks whether a certain existing key is empty or does not exist. It suffices that one of these two conditions is met. The operator "is regex" is true if the particular parameter matches the digest specified in the corresponding value column in the condition definition table 33.

A value can refer to a variable. Variabein are represented by "$ {variable-name}" For example, it is possible to check if the printer name is the same as the job name The definition of variables is described below.

If the variables are defined, it is also possible to check the contents of variables. Therefore the parameter Combo-Box also allows a special variable selection. If this is selected, a list of all defined variable names will be displayed. The section "Files" needs a special treatment because it can occur multiple times, a condition in the "Files" section is true if it applies to at least one section. If a setting action follows this condition, then this set action will be executed only in the file sections that satisfy these conditions. If a set action is defined in a file section that does not follow a condition using the file section, then the set action will be performed in all file sections.

The definition of a condition is always automatically checked for correctness. If there should be errors, such as a reference to an undefined variable or to a control parameter containing only one key, then the condition action defined in red in the condition definition table 33 is displayed. If the condition is correct, it will be displayed in black.

Set actions are defined in the set definition window 27 (FIG. 11), which includes a setting definition menu bar 33 and a setting definition table 34. The set definition menu bar 34 includes pictograms 18, 13 and 14 already explained above for adding, deleting and copying set actions. Furthermore, it includes a pictogram 35, with which job tickets can be imported. A window displays all available job tickets. After selecting such a job ticket, it will be imported with all its actions, keys and values and can now be edited. This feature is primarily intended to generate default job tickets from the Print Order Manager 1 with the job-in-order data of the incoming print jobs and supplement missing control parameters in incoming order-related data.

Each set action includes at least one parameter, a value, and an override flag, and may be named. A value can refer to a variable. A value may also be set to "[delete]" meaning that the entire entry of the control parameter up to the keys in the job ticket is to be deleted, unlike the entry "" with which nothing is entered in the key becomes.

If the setting action is to overwrite an existing section or key entry in the order-related data, then the corresponding

Override flag to be set. The default status is a set overwrite flag.

? ?

The section "files" needs a special treatment as this section can occur multiple times, so if a set action follows a condition in a file section that is true when applied to such a file section, then that set becomes If a set action is defined in a file section and does not depend on a condition that uses the file section, then the set action applies to all file sections. sections.

The correctness of the definitions of a set action is always checked automatically. If an error is detected, the set action in the set definition table 35 is displayed in red. Otherwise it will be displayed in black letters. The example of set actions shown in the set definition window 27 (Figure 11) means that the name of the print job is set to a new value beginning with the contents of a variable ($ V> new j if prefix <) and is followed by "" and ends with the value of another variable ($ V> new job name <). "Since the overwrite flag is set, this set action is also executed if a corresponding entry already exists the key "Client_Company" of the section

"Client" is set to "MyCompany", but only if the key does not already exist because the overwrite flag is not set.

- For all file sections that satisfy a condition and that are selected during the condition check, the key "file_copies" is set to a new variable value, so if the set action does not depend on a condition using the file section, the Key "File Copies" in all files set to this value.

For editing variables, the variable editor window 28 (FIG. 12) is provided. The variable editor window 28 includes a variable definition menu bar 36 and a variable definition table 37.

Each variable has at least one unique variable name and parameter. The name is necessary to call a variable. All variables represent global entries. Variables are called in the following form $ {variable name}.

A variable arranged in a sequence of actions provides in operation a control parameter at the location where the variable is located. This control parameter may already have been changed by previous actions. The variable definition table 38 includes other columns "Alteration Type" and "Alteration Code". Here, a statement can be defined with which the content of the variable is changed when a control parameter for the variable is incoming

Order-related data is adopted. There are three types of variable-changing actions:

- Field: This divides the contents of a variable into fields, and a desired field is cut out.

- Replacement: Replaces a predefined string with another string. Calculation: Changes the value of an integer variable or floating-point variable using a mathematical operation.

To define the change rules, the corresponding variable is clicked in the variable definition table 37. By clicking on the corresponding fields in the columns "Alteration Type" and "Alteration Code", respective drop-down menus open from which suitable entries can be selected.

If the value "Field" is entered in the column Alteration Type, then a field definition window 38 (FIG. 13) opens with which data fields are defined individual field entries are separated in a string. If no field delimiter is specified, then this character is a separate data field. As a field delimiter, only a single character can be entered.

The input fields "From Field" and "To Field" can be used to enter the range of data fields to be extracted from a predefined string. For this, the data fields are numbered twice, namely with positive integers, whereby the data field arranged at the left edge is assigned the value 1 and these values are increased from one field to the other by 1 in each case. When numbering with whole negative numbers, the numbering on the right arranged data field ends with the value -1 and decreases from data field to data field by 1 in the direction to the left. The following is an example of this numbering for the string "Testring":

1 2 3 4 5 6 7 8 9 10 T e s t r i n g -10 -9 -8 -7 -6 -5 -4 -3 -2 -1

In the input fields "From Field" and "To Field" both numbering can be used alternatively. The positive numbers are used when one wants to define a particular data field with respect to the left edge, and the negative numbers are used when one wants to define a particular data field with respect to the right edge. In this field definition window 38, a data field example ("Example") is automatically specified in each case and in the row arranged below it is shown what becomes of this data field example by the defined action ("becomes").

This field definition is primarily used to cut out strings. However, it can also be used to cut certain numeric records.

In the variable definition table 37, the entry "Replacement" can be entered in the "Alteration Type" column, with which predetermined character strings are replaced by other character strings. For this purpose, a replacement definition window 39 opens in which a searched string is entered in the data field row "Find" and the string used to replace the searched string is entered in the data field line "Replace".

Furthermore, the number of replacements to be performed can be entered in the data field line "Occurances", where either a whole positive number or "all" is entered, which means that all found character strings are replaced. Setting a flag will replace the string regardless of the case. Also in this replacement definition window 39 there is again an example line "Example" in which a string is indicated, which in the line arranged thereunder corresponds to the defined one

Definition ("becomes") In the example lines, a user can also enter any character string, which is then converted accordingly.

If a value "Calculation" is entered in the variable definition table 37 in the "Alteration Type" column, a calculation definition window 40 opens (FIG. 15). In this calculation definition window 40, an operator of one of the four basic operations "+", "-", "*", or "/" can be entered in a field 41, and in a field 42 the calculation value, which with the corresponding operator is set to a variable for integers or floating-point numbers are applied.

The system according to the invention allows the output of messages when the ticket rules on

Print Job Manager 1 can be selected. This is particularly advantageous in connection with the central execution of all ticket rules, since these messages, which are primarily warnings and error messages, are output centrally at one point in the print job manager and so a reliable monitoring of the same is possible.

By clicking on the icon 20 in the rule definition bar 8, the message editor window 29 (FIG. 16) is opened. This window comprises a message definition menu bar 43 and a message definition table 44. In the message definition menu bar 43, icons 20, 14, 13 for adding, deleting and copying a message are listed. Each message includes a message identifier ("Message-ID"), a message type ("Type"), a short message text ("Short Text"), a long message text ("Long Text") and an optional text ("Optional Text At least one short and one long message text must be entered for the message to be valid. <br /> <br /> Variables can also be used in the message text whose contents are displayed when they are called up.

After creating a message, the message is always checked for correctness. If the message is incorrect, it will be displayed in red, otherwise in black.

When clicking on the icon 21 in the rule definition bar 8, a sub-rule window 45 (Figure 17) is opened, in which all sub-ticket rules are listed. Adding new sub-ticket rules is done in Rule Activation List 9 by changing the corresponding entry for a particular rule to Sub-Rule in the Activation column, so the sub-rule Window 45 for information only and not for editing the sub-ticket rules.

In the above-described system for automatically processing a print job, the print jobs processed with the associated order-related data automatically to the print job manager 1, wherein after a predetermined ticket rule a printing system-specific job ticket is generated.

In the context of the invention, it is also possible for a ticket rule to be called explicitly in the order-related data, so that control parameters of the job ticket or data ticket are not accidentally changed. To do this, enter the following command in the order-related data:

TicketRule = "Test RuIe 1"

Between the quotation marks is the name of the ticket rule to be called.

The entry of the ticket rule in the order accompanying data can be done on the client 2 or at an upstream processing stage and / or when creating the job-accompanying data.

Within the scope of the invention, it is also possible to provide a SuperTicket rule which basically checks all incoming order-related data according to predetermined criteria and parameters and, depending on the check, invokes a respectively suitable ticket rule, if one exists, or an incoming job - Forwards ticket without further verification by a ticket rule. In such an embodiment of the invention, no corresponding references to ticket rules are to be entered in the order-related data or no corresponding parameter must be entered when the request is made.

The invention has been explained above with reference to an exemplary embodiment in which either an incoming job ticket is supplemented or, based on a default job ticket, a job ticket specific to the printing system is produced. In the context of the invention, however, it is also possible for an incoming job ticket of a certain format to be converted into the format for job tickets used in the present printing system.

The invention can be briefly summarized as follows:

The invention relates to a method, a printing system and a computer program for automatically processing order-related data of a print job.

With the invention, incoming order-related data of a print job to a print job manager are checked centrally by means of predetermined ticket rules and optionally supplemented or changed by further printing parameters, so that from the order accompanying data a printing system-specific job ticket is formed, with which the print job can be printed correctly in the respective printing system.

The central check of the order-related data at the print job manager allows an easy administration of the ticket rules and due to the proximity to the print server and the connected printing devices a very printing system-specific processing of the job tickets is possible.

LIST OF REFERENCE NUMBERS

1 print job manager

2 client 3 computers

4 ticket rule module

5 main bar

6 drop-down menu

7 Rule Definition Window 8 Rule Definition Bar

9 rule action list

10 pictogram

11 pictogram

12 pictogram 13 pictogram

14 pictogram

15 pictogram

16 pictogram

17 Pictogram 18 Pictogram

19 pictogram

20 pictogram

21 pictogram

22 Pictogram 23 Pictogram

24 pictogram

25 pictogram

26 condition definition window

27 Set Definition Window 28 Variable Editor Window

29 message editor window 30

31 condition definition menu bar

32 Condition Definition Table 33 Set definition menu bar

34 Set definition table

35 pictogram 36 Variable definition menu bar

37 Variable definition table

38 Field Definition Window

39 Replace Definition Window 40 Calculation Definition Window

41 field

42 field

43 Message Definition Menu Bar 44 Message Definition Table 45 Sub-rule window

46 data line

47 interface

48 interface

Claims

claims

A method for automatically processing job-related data of a print job that includes control parameters for controlling a printing operation in a printing system having a print job

Print job manager (1), one or more clients (2) on which print jobs are generated, and a print server for supplying the print jobs to a printing device, comprising

- Receiving a print job with the

Job-related data from one of the clients (2) by the print job manager (1),

- Check the order-related data according to predetermined, freely programmable ticket rules centrally on

Print Job Manager (1) and print job specific job ticket, and

- Forward the print job with the printing system-specific job ticket to the print server.

2. The method of claim 1, wherein a job-in-order data is checked by print jobs originating from different sources.

3. Method according to claim 1 or 2, wherein a print job can be aborted when checking the order-related data on the basis of the ticket rules (exit, stop job).

4. The method according to any one of claims 1 to4, characterized in that when checking the order-accompanying data based on the ticket rules, a message can be issued (message).

5. The method according to claim 1, wherein a central ticket rule module (4) is operated at the print order manager (1) with which all ticket rules are managed.

6. The method according to claim 5, wherein a job ticket is checked exclusively by means of ticket rules provided by the ticket rule module (4).

7. The method according to claim 5 or 6, wherein a check of the job-related data is carried out by the ticket control module (4).

8. Method according to one of claims 1 to 7, characterized in that, when checking the order-related data, a job ticket contained therein is automatically changed if necessary.

9. Method according to one of claims 1 to 8, characterized in that order-related job data arriving at the print order manager (1) with a print job are combined with a default job ticket.

10. The method according to any one of claims 1 to 9, characterized in that when checking the order accompanying data, the format of a job ticket contained therein is automatically changed if necessary.

11. The method of claim 1, wherein the ticket rules comprise a series of actions.

A method according to claim 11, characterized in that the sequence of actions comprises one or a combination of one or more of the following actions: condition: a value of a control parameter of the job ticket is compared with a predetermined value and if it matches the result is "true" and if differentiated, the result is determined to be "false".

- a value of a control parameter of the order-related data is compared with a predetermined value, and in the case of a match the result is "false" and if the result is "true", setting: With this action, a designation (key) of a control parameter in Job ticket set to a predetermined value.

- variable: With the action variable a variable is defined.

- message: The message action generates a message depending on the value of a particular message

Control parameters of the job-related data, rule: With the action rule, another ticket rule, the sub-ticket rule, is called within a predetermined ticket rule, whereby the call of this sub-ticket rule takes place as a function of one or more control parameters of the job-related data ,

- break: The break action immediately stops the execution of the ticket rule, and if the ticket rule that terminates should be a sub-ticket rule, the parent ticket rule continues. exit: The exit action immediately stops the execution of the ticket rule, and if the ticket rule that terminates should be a sub-ticket rule, a parent ticket rule will not continue.

- exit and stopjob: This action immediately stops the execution of the ticket rule and it does not proceed with a parent ticket rule and the processing of the print job is also terminated. switch / case: This action compares a value of an order-tracking data control parameter with each value specified in a first column of a table, and if there is a match with one of the values, the values of the row of that table automatically become corresponding Data fields, in particular entered in a corresponding table in the ticket rule.

13. A method according to any one of claims 1 to 12, wherein a variable arranged in a sequence of actions provides in operation a control parameter at the location where the variable is located.

14. The method of claim 13, wherein the content of a variable is changed by one of the following variable-changing actions: Field: This divides the content of a variable into fields and a desired field is cut out.

- Replacement: Replaces a predefined string with another string. - Calculation: Changes the value of an integer

Variables or floating-point variables by means of a mathematical operation.

15. A printing system for automatically processing a job ticket, comprising

a print job manager (1), one or more clients (2) on which print jobs are generated, and

- A print server for supplying the print jobs to a printing device, wherein the print job manager (1) for carrying out a method according to one of claims 1 to 14 is provided with a ticket rule module (4).

16. Printing system according to claim 15, characterized in that the ticket rule module (4) is provided with an interface to clients (2) which are provided with a rule editor module with which ticket rules can be edited.

17. A printing system according to claim 16, wherein a rule editor module has a graphical user interface (GUI).

18. A printing system according to claim 16 or 17, characterized in that the ticket rule module (4) and / or the rule editor module are designed such that edited ticket rules are automatically checked for a correct syntax.

19. A printing system according to any one of claims 16 to 18, wherein a ticket rule module (4) and / or the rule editor module are designed such that all edited ones

Ticket rules are stored in the Ticket Rule module and managed there.

A computer program adapted to carry out a method according to any one of claims 1 to 14.

21. Computer program according to claim 20, wherein a computer program is stored on a data carrier.