WO2008104496A1 - Verfahren, drucksystem und computerprogramm zum automatischen bearbeiten von auftragsbegleitdaten eines druckauftrages - Google Patents

Verfahren, drucksystem und computerprogramm zum automatischen bearbeiten von auftragsbegleitdaten eines druckauftrages Download PDF

Info

Publication number
WO2008104496A1
WO2008104496A1 PCT/EP2008/052129 EP2008052129W WO2008104496A1 WO 2008104496 A1 WO2008104496 A1 WO 2008104496A1 EP 2008052129 W EP2008052129 W EP 2008052129W WO 2008104496 A1 WO2008104496 A1 WO 2008104496A1
Authority
WO
WIPO (PCT)
Prior art keywords
ticket
job
rule
print
print job
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2008/052129
Other languages
English (en)
French (fr)
Inventor
Thomas Harms
Armin Gnaedig
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Production Printing Germany GmbH and Co KG
Original Assignee
Oce Printing Systems GmbH and Co KG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oce Printing Systems GmbH and Co KG filed Critical Oce Printing Systems GmbH and Co KG
Publication of WO2008104496A1 publication Critical patent/WO2008104496A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1278—Dedicated interfaces to print systems specifically adapted to adopt a particular infrastructure
    • G06F3/1285—Remote printer device, e.g. being remote from client or server
    • G06F3/1288—Remote printer device, e.g. being remote from client or server in client-server-printer device configuration
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1202—Dedicated interfaces to print systems specifically adapted to achieve a particular effect
    • G06F3/1203—Improving or facilitating administration, e.g. print management
    • G06F3/1205—Improving or facilitating administration, e.g. print management resulting in increased flexibility in print job configuration, e.g. job settings, print requirements, job tickets
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1223—Dedicated interfaces to print systems specifically adapted to use a particular technique
    • G06F3/1237—Print job management
    • G06F3/126—Job scheduling, e.g. queuing, determine appropriate device
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]

Definitions

  • the invention relates to a method, a computer program and a printing system for automatically processing order-related data of a print job.
  • OCS order distribution system
  • 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 Print jobs or automatically created in a printing system.
  • Job Definition Format JDF
  • JDF Job message format (Job Messaging Formats or JMF) specified accordingly.
  • JDF Job Messaging Formats or JMF
  • 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.
  • JDF JDF
  • 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.
  • 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.
  • 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.
  • Printj obmanagers is also referred to as a print job manager.
  • 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.
  • 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.
  • 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.
  • job tickets often contain printer names that are not present in the existing printing system.
  • 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.
  • 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 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:
  • 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
  • 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.
  • 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
  • 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.
  • GUI graphical user interface
  • the central checking of the order-related data enables a uniform check of
  • Job-related data from print jobs coming from different sources 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.
  • 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.
  • 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.
  • 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.
  • Print job manager 1 ( Figure 1) automatically processed.
  • Print job manager 1 is connected to several clients 2 (CL).
  • CL Print job manager 1
  • input modules 2/1 input modules 2/1
  • print job client 2/2 print job client 2/2
  • ticket rule client 2/3 ticket rule client
  • 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.
  • 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.
  • the job-related data of the incoming print jobs are supplemented with data, in particular control parameters, from a default job ticket.
  • data in particular control parameters, from a default job ticket.
  • missing, but necessary in the existing printing environment control parameters are added to the job-related data.
  • 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.
  • the so-supplemented pressure system-specific job ticket is taken into account.
  • 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.
  • TRM ticket rule module 4
  • 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.
  • GUI graphical user interface
  • 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.
  • 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
  • - 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).
  • the ticket rules can be freely programmed, analogous to the client-specific scripts mentioned at the beginning.
  • 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.
  • 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.
  • 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 are 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.
  • 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.
  • 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.
  • a function is called, which carries out the processing of the respective print job.
  • 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
  • FIG. 1 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.
  • 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.
  • 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.
  • 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.
  • rule activation list 9 (FIG. 5) all ticket rules are listed in tabular form.
  • 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.
  • the generated description or the self-generated description can be displayed. The manually created description is saved together with a corresponding 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.
  • 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
  • a condition definition window 26 (FIG. 10) is called, with which conditions can be edited. This will be explained below.
  • 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
  • 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.
  • a selected action can be deleted from a sequence of actions.
  • 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.
  • 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.
  • a window pops up listing the names of all ticket rules that use this action and the
  • 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.
  • 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 includes a condition definition menu bar 31 and a condition definition table 32.
  • 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.
  • - is a hexadecimal digit (0-9, A-F, a-f)
  • 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.
  • 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.
  • condition definition table 33 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.
  • 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.
  • variable editor window 28 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 ⁇ .
  • variable definition table 38 includes other columns "Alteration Type" and "Alteration Code".
  • a statement can be defined with which the content of the variable is changed when a control parameter for the variable is incoming
  • variable definition table 37 the corresponding variable is clicked in the variable definition table 37.
  • 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.
  • a field definition window 38 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.
  • 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.
  • 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.
  • This numbering for the string "Testring” is an example of this numbering for the string "Testring":
  • This field definition is primarily used to cut out strings. However, it can also be used to cut certain numeric records.
  • 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.
  • 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".
  • 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
  • a calculation definition window 40 opens (FIG. 15).
  • 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.
  • This window comprises a message definition menu bar 43 and a message definition table 44.
  • 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.
  • Message-ID message identifier
  • Type message type
  • Short Text short message text
  • Long Text long message 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.
  • the message 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.
  • 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.
  • 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.
  • a ticket rule 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:
  • 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.
  • 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.
  • 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 relates to a method, a printing system and a computer program for automatically processing order-related data of a print job.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Economics (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Educational Administration (AREA)
  • Computer Hardware Design (AREA)
  • Data Mining & Analysis (AREA)
  • Accessory Devices And Overall Control Thereof (AREA)

Abstract

Die Erfindung betrifft ein Verfahren, ein Drucksystem und ein Computerprogramm zum automatischen Bearbeiten von Auftragsbegleitdaten eines Druckauftrages. Mit der Erfindung werden eingehende Auftragsbegleitdaten eines Druckauftrages an einem Druckauftragsmanager zentral mittels vorbestimmter Ticket-Regeln überprüft und gegebenenfalls durch weitere Druckparameter ergänzt, so dass aus den Auftragsbegleitdaten ein drucksystemspezifisches Jobticket gebildet wird, mit welchem der Druckauftrag korrekt im jeweiligen Drucksystem ausgedruckt werden kann. Die zentrale Überprüfung der Auftragsbegleitdaten am Druckauftragsmanager erlaubt eine einfache Verwaltung der Ticket-Regeln und durch die Nähe zum Druckserver und den daran angeschlossenen Druckgeräten ist eine sehr drucksystemspezifische Bearbeitung der Jobtickets möglich.

Description

Verfahren, Drucksystem und Computerprogramm zum automatischen Bearbeiten von Auftragsbegleitdaten eines Druckauftrages
Die Erfindung betrifft ein Verfahren, ein Computerprogramm und ein Drucksystem zum automatischen Bearbeiten von Auftragsbegleitdaten eines Druckauftrages.
In Digital Printing, Technology and printing techniques of Oce digital printing presses, 9th edition, February 2005 (ISBN 3-00-001081-5) ist im Kapitel 18.2 ein Order Distribution System (ODS) beschrieben, das auch als Workflow Manager bezeichnet wird. Mit diesem Order Distribution System kann der gesamte digitale Druckprozess gesteuert werden, der eine Druckvorstufe, einen
Hochleistungsdrucker und eine Endbearbeitung umfasst. In der Druckvorstufe werden Bild- und Textdateien aus unterschiedlichen Quellen, wie Scanner, Digitalkamera, Datenträger oder ein Computernetzwerk zusammengeführt und an einer Layoutstation in ihre endgültige Form gebracht. Anschließend wandelt ein Druckertreiber die auf verschiedenen Plattformen erstellten Daten zum Beispiel in Postscript-Dateien um. Diese Dateien können dann zum Druck an einen Printserver weitergegeben werden. Printserver konvertieren die Daten in komprimierte Bitmaps, die voll automatisch ausgeschossen werden und an das Drucksystem weitergeleitet werden. Der Printserver steuert den Druckvorgang. Die Endbearbeitung des Druckproduktes umfasst zum Beispiel das Binden oder Einfügen von Trennblättern. Das Order Distribution System ist außerdem für die zentrale Verwaltung der Produktionsvarianten zuständig. Dazu gehört auch der Druckservice für Intranet- und Internetbenutzer. Das Order Distribution System informiert Anwender über freigegebene Produktionsvarianten, nimmt
Druckaufträge samt digitaler Auftragstasche an, veranlasst die automatische Abarbeitung bis zum Druck. Das Order Distribution System überwacht auch die korrekte Ausführung der ausgewählten Druck- und Nachverarbeitungsoptionen.
Das Order Distribution System arbeitet hier sogenannte Jobtickets ab. Ein Jobticket ist eine Datei, in einem bestimmten Datenformat, die Steuerparameter zum Steuern des Ausdrucks von Druckdaten eines Druckauftrages enthält. Das Jobticket kann vom Anwender beim Erstellen des
Druckauftrages oder automatisch in einem Drucksystem erstellt werden.
Herkömmliche Jobtickets weisen eindeutige Anweisungen auf, die entsprechend umzusetzen sind. Der Druckprozess wird zunehmend umfangreicher, da immer mehr Geräte in einen Druckprozess integriert werden, wodurch die
Funktionsvielfalt zunimmt. Zudem werden durch das Internet und Intranet Druckprozesse zunehmend regional verteilt ausgeführt oder einem Pool von Druckern zugeordnet, die regional verteilt sein können. Außerdem müssen zunehmend Geräte unterschiedlicher Hersteller in einem Prozess zusammen arbeiten. Um diesen gestiegenen Anforderungen gewachsen zu sein, wurde eine einheitliche Spezifikation zum Austausch von Datenformaten im Druckprozess vereinbart, die als Jobdefinitionsformat (JDF) bezeichnet wird. Hierzu gibt es ein korrespondierendes
Jobnachrichtenformat (Job Messaging Formate bzw. JMF), das entsprechend spezifiziert ist. Die Spezifikation von JDF kann von der Internetseite www.cip4.org heruntergeladen werden, die zur Zeit aktuelle Spezifikation ist JDF Specification Release 1.3. JDF ist ein XML-basiertes Format, bei dem die Anweisungen für den Druckprozess in einer Baumstruktur angeordnet sind. Jeder Knoten (node) der Baumstruktur umfasst eine Anweisung oder einen Satz von Anweisungen. Der oberste
Knoten wird als Wurzel bzw. Root bezeichnet. Die Endknoten an Verzweigungen werden als Blattknoten (leaf nodes) bezeichnet .
Die Besonderheit von JDF liegt darin, dass es sogenannte Intent-Knoten geben kann, die eine sehr allgemeine Anweisung für einen Druckprozess enthalten, die präzisiert werden muss, um an einem Gerät ausgeführt werden zu können .
Aus der DE 10 2004 047 327 Al bzw. der korrespondierenden US 2007/0291300 Al geht ein Verfahren hervor, bei dem das JDF-Format zum schrittweisen Präzisieren eines Druckauftrages angewendet wird.
Aus der EP-A2-1 197 838 ist ein Verfahren zum Bearbeiten von Druckaufträgen in einem Netzwerk bekannt, bei dem anhand eines Jobtickets überprüft wird, ob ein Druckdienstleister die zur Bearbeitung des Druckauftrages erforderlichen Ressourcen hat.
Aus der US 2002/0080400 Al geht ein Verfahren für ein Dokumenten-Bearbeitungssystem hervor, in dem ein Dokumenten-Bearbeitungsauftrag (Job) mehrfach auf unterschiedliche Art und Weise bearbeitet werden kann. Wie der Dokumenten-Bearbeitungsauftrag im einzelnen bearbeitet wird, wird durch unterschiedliche Jobtickets gesteuert. Die Besonderheit dieses bekannten Verfahrens liegt darin, dass die unterschiedlichen Jobtickets mittels eines Master-Jobtickets, das auch als Super-Jobticket bezeichnet wird, auf einmal angesteuert werden können, so dass die mehreren Dokumenten-Bearbeitungsaufträge mittels des Master-Jobtickets auf einmal in dem Dokumenten- Bearbeitungssystem aufgegeben werden können.
Aus der US 5,718,520 geht ein Verfahren zum Editieren von Jobtickets hervor, bei dem beim Editieren eines bestimmten Steuerparameters ein Fenster auf einer Anzeigeeinrichtung erzeugt wird, in dem alle möglichen Werte angezeigt werden, die für den Steuerparameter eingesetzt werden können .
Aus Digital Printing Technology, und Printing Techniques of Oce Digital Printing Presses (a. a.a.O.) geht ein mit dem Handelsnamen Oce PRISMAproduction bezeichnetes Serversystem hervor, das eine breite Palette von Datenströmen verarbeitet bzw. konvertiert, die dann auf IPDS-Druckern gedruckt werden. Das Oce PRISMAproduction Serversystem umfasst einen Printj obmanager PJM (siehe Kapitel 15.2.4 und 18.2) mit dem Druckaufträge auf einen beliebigen Kunden-Client erzeugt und in diesem Serversystem bearbeitet und verwaltet werden. Der
Printj obmanagers wird auch als Druckauftragsmanager bezeichnet .
Als „Server" werden Softwaremodule bezeichnet, die eine zentrale Aufgabe erledigen. Als „Clients" werden Softwaremodule bezeichnet die mit einem Server in Verbindung stehen und vom Server Daten empfangen oder an diesen übermitteln. Mit einem Server können gleichzeitig mehrere Clients in Kontakt stehen.
Bei diesem bekannten Client-/Server-System werden Druckaufträge durch die Clients erzeugt. Ein Druckauftrag umfasst die zu druckenden Druckdaten und ein Jobticket, das Steuerparameter zum Steuern des Ausdruckes der Druckdaten beinhaltet. Die Druckaufträge können aus unterschiedlichen Quellen stammen. An den dem Druckauftragsmanager vorgeschalteten Clients werden die eingehenden Druckaufträge kontrolliert und gegebenenfalls angepasst. Diese Anpassung kann den Druckauftrag begleitende Daten oder Informationen umfassen, wobei der Inhalt der Jobtickets an die Druckumgebung angepasst wird. Es ist auch möglich, dass aus den den Druckauftrag begleitenden Daten und einem am Druckmanager vorhandenen Vorgabe-Ticket erstmals ein Jobticket am Druckauftragsmanager erstellt wird. Das Format ggf. eingehender Jobtickets ist meistens in Ordnung, jedoch sind darin oftmals Parameter enthalten, die nicht verwendbar sind oder sogar zu Widersprüchen führen. So enthalten Jobtickets oftmals Druckernamen, die im vorliegenden Drucksystem nicht vorhanden sind. Zur Korrektur derart fehlerhafter Jobtickets sind an den Clients Computerprogramme vorgesehen, die die Jobtickets automatisch kontrollieren und gegebenenfalls korrigieren. Diese Computerprogramme sind als Scripte individuell für die einzelnen Clients und deren Anwendungen programmiert. Es ist auch üblich, dass auf einem Client mehrere derartiger Scripte vorgesehen sind, um beispielsweise unterschiedliche Quellen oder Jobtickets mit Druckdaten in unterschiedlichen Datenformaten jeweils zu überarbeiten. Diese Scripte haben sich an sich sehr bewährt, denn hiermit werden die eingehenden Druckaufträge automatisch kontrolliert und korrigiert, so dass der gesamte Druckprozess ohne Verzögerung ablaufen kann.
Tritt dennoch ein Fehler aufgrund eines falschen
Parameters im Jobticket während des Druckprozesses auf, so ist es bei der vorliegenden Ausgestaltung des Drucksystems schwierig, festzustellen, wo und durch was der Fehler verursacht worden ist. Hierzu muss zum einen nachvollzogen werden, über welchen Client der Druckauftrag dem
Druckauftragsmanager zugeführt worden ist, und dann muss festgestellt werden, mit welchem Script das Jobticket bearbeitet worden ist. Selbst wenn dies feststehen sollte, ist es oftmals schwierig, das Script dahingehend zu analysieren, ob es den Fehler verursacht hat oder ob eventuell der Fehler beim Erzeugen des Druckauftrages beim Kunden oder beim Übertragen des Druckauftrages zum Client verursacht worden ist.
In der DE 102 35 124 Al wird ein Verfahren offenbart, bei dem bereits verwendete und gerasterte Druckjobs erneut verwendet und abgewandelt werden können. Die "alten" Druckjobs liegen an einer Steuereinrichtung einer Druckvorrichtung. Sie können von einem Client abgerufen werden, wobei der Client das entsprechende Jobticket von der Druckvorrichtung anfordert. Dieses Jobticket wird dann vom Client überarbeitet, wobei Anweisungen eingefügt werden, um die geänderten Seiten einzusetzen, so dass an der Druckvorrichtung die unveränderten Seiten aus dem alten Druckjob übernommen werden können und nur die zu ersetzenden Seiten gerastert werden.
Der Erfindung liegt deshalb die Aufgabe zugrunde, ein Verfahren, ein Drucksystem und ein Computerprogramm zum automatischen Bearbeiten von Auftragsbegleitdaten für einen Druckprozess zu schaffen, das ohne Verzögerung des Druckprozesses eine automatische Kontrolle der Jobtickets erlaubt und dennoch einfach nachvollziehbar und handhabbar ist.
Die Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 1, ein Drucksystem mit den Merkmalen des
Anspruchs 15 und ein Computerprogramm mit dem Merkmal des Anspruchs 20 gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in den jeweiligen Unteransprüchen angegeben .
Das erfindungsgemäße Verfahren zum automatischen Bearbeiten von Auftragsbegleitdaten eines Druckauftrages, die Steuerparameter zum Steuern des Druckauftrages beinhalten, in einem Drucksystem mit einem Druckauftragsmanager, einem oder mehreren Clients, an welchen Druckaufträge erzeugt werden, und einem Druckserver zum Zuführen der Druckaufträge an ein Druckgerät, umfasst die folgenden Schritte:
- Empfangen eines Druckauftrages mit
Auftragsbegleitdaten von einem der Clients durch den Druckauftragsmanager, - Überprüfen der Auftragsbegleitdaten nach vorbestimmten, frei programmierbaren Ticket-Regeln und Ausgeben eines drucksystemspezifischen Jobtickets, und
- Weiterleiten des Druckauftrages mit dem Jobticket zum Druckserver.
Das erfindungsgemäße Verfahren zeichnet sich dadurch aus, dass das Überprüfen der Auftragsbegleitdaten nach den vorbestimmten Ticket-Regeln zentral am Druckauftragsmanager ausgeführt wird.
Da die Auftragsbegleitdaten zentral und vorzugsweise ausschließlich am Druckauftragsmanager überprüft bzw. kontrolliert werden, sind die für einen bestimmten Druckauftrag angewandten Ticket-Regeln einfach nachvollziehbar, denn die Ticket-Regeln sind lediglich an einer einzigen Stelle, nämlich dem Druckauftragsmanager, und nicht, wie es im Stand der Technik der Fall ist, an unterschiedlichsten Clients vorhanden und dort jeweils zu untersuchen. Weiterhin ist durch das zentrale Ausführen der Überprüfung der Auftragsbegleitdaten am Druckauftragsmanager sichergestellt, dass alle eingehenden Auftragsbegleitdaten nach den gleichen Ticket-Regeln überprüft bzw. kontrolliert werden und gegebenenfalls entsprechend abgeändert und korrigiert werden. Weiterhin sind durch das zentrale Ausführen des Überprüfens der Auftragsbegleitdaten die Ticket-Regeln zentral zu verwalten, wodurch sie auch zentral kontrollierbar sind und vermieden wird, dass ähnliche Auftragsbegleitdaten bzw. ähnliche Fehler in
Auftragsbegleitdaten unterschiedlich korrigiert werden.
Ein weiterer Vorteil des Überprüfens der Auftragsbegleitdaten zentral am Druckauftragsmanager liegt darin, dass die Überprüfung der Auftragsbegleitdaten in der Prozesskette sehr nahe am konkreten Druckgerät erfolgt, so dass diese Überprüfung sehr spezifisch für das jeweilige Druckgerät durchgeführt werden kann. Hierdurch kann die Qualität der Überprüfung erheblich gesteigert werden. Bei der Ausführung der Überprüfung der
Auftragsbegleitdaten an den Clients besteht das Problem, dass die Clients mit unterschiedlichen
Druckauftragsmanagern kommunizieren können, so dass eine darauf ausgeführte Überprüfung der Auftragsbegleitdaten an die Druckgeräte, die mit den unterschiedlichen
Druckauftragsmanagern erreicht werden können, angepasst sein muss, was wiederum sehr schwierig ist.
Durch die zentrale Verwaltung der Ticket-Regeln ist es auch möglich, dem Operator Werkzeuge zur Verfügung zu stellen, die das Erstellen und Verwalten der Ticket-Regeln erleichtern. Insbesondere ist es zweckmäßig, eine graphische Benutzeroberfläche (GUI) vorzusehen, in welcher die Ticket-Regeln erstellt und verwaltet werden können und ein Softwaremodul vorzusehen, mit dem die Syntax der editierten Ticket-Regeln automatisch auf eine korrekte Syntax überprüft wird.
Das zentrale Überprüfen der Auftragsbegleitdaten ermöglicht eine einheitliche Überprüfung von
Auftragsbegleitdaten von Druckaufträgen, die aus unterschiedlichen Quellen stammen. Zur Erläuterung der vorliegenden Erfindung werden nachfolgend einige Begriffe definiert:
Ein Gesamtauftrag enthält mindestens einen
Dokumentenbearbeitungsauftrag, insbesondere einen Druckauftrag .
Ein Druckauftrag (Job) enthält mindestens eine zu druckende Druckdatei.
Ein Gesamtauftragsticket (order-ticket) enthält Informationen über einen Gesamtauftrag, wie z.B. Auslieferungsadresse, Auftragsdatum, gewünschtes Lieferdatum, etc.
Ein Jobticket enthält alle zur Abarbeitung eines Druckauftrages erforderlichen Daten. Diese Daten umfassen Steuerparameter, die in einem Arbeitsablauf für den Druckauftrag (j ob-workflow) relevant sind. Das Jobticket ist in einem entsprechenden Ticketformat kodiert.
Ein Vorgabe-Jobticket enthält Standard-Daten, die geeignet sind, einen Druckauftrag, der keine weiteren Bearbeitungsinformationen enthält, in einem vorliegenden Drucksystem bzw. einer vorliegenden Druckumgebung auszugeben. Solche Daten sind Steuerparameter und können z.B. Namen oder Adressen von Druckgeräten sein, die an den jeweiligen Druckserver angeschlossen sind.
Unter einem Datenticket werden Informationen verstanden, die von einem einen Druckauftrag erzeugenden System, beispielsweise einem MFS Mainframe-Computer-System erzeugten Druckauftrag zusammen mit den Druckdaten erzeugt werden. Der Umfang derartiger Daten ist systembedingt sehr begrenzt und ihr Format nicht standardisiert, weshalb sie nicht als Jobtickets im obigen Sinne angesehen werden. Die Auftragsbegleitdaten können sowohl ein Gesamtauftragsticket, ein Jobticket und/oder ein Datenticket oder Steuerparameter, die in anderer Form einem Druckauftrag beigefügt sind, umfassen.
Steuerparameter werden öfters in den Dateinamen des Druckauftrages eingefügt.
Ist dem Druckauftrag kein Jobticket beigefügt, so wird am Druckauftragsmanager mittels des Vorgabe-Jobtickets und evtl. weiterer Steuerparameter und der Ticket-Regeln ein drucksystemspezifisches Jobticket erzeugt. Ist dem Druckauftrag hingegen ein Jobticket beigefügt, wird anhand der Ticket-Regeln das Jobticket überprüft, ob es als drucksystemspezifisches Jobticket geeignet ist und ggfs., - was die Regel ist - verändert und insbesondere durch drucksystemspezifische Parameter aus dem Vorgabe-Ticket ergänzt .
Die Erfindung wird nachfolgend beispielhaft näher anhand eines in den Zeichnungen gezeigten Ausführungsbeispiels erläutert. Die Zeichnungen zeigen:
Figur 1: wesentliche Teile eines Drucksystems zum Ausführen des erfindungsgemäßen Verfahrens schematisch vereinfacht in einem Blockschaltbild;
Figur 2: eine Bildschirmkopie der graphischen Benutzeroberfläche des erfindungsgemäßen Systems;
Figuren 3 bis 7: Ausschnitte der Bildschirmkopie der graphischen Benutzeroberfläche aus Figur 2, und
Figuren 8 bis 17: Kopien von Fenstern der graphischen Benutzeroberfläche zum Darstellen und Bearbeiten von Ticket-RegeIn . Mit dem erfindungsgemäßen Verfahren werden an einem Drucksystem eingehende Auftragsbegleitdaten von entsprechenden Druckaufträgen von einem
Druckauftragsmanager 1 (Figur 1) automatisch bearbeitet.
Der Druckauftragsmanager 1 (DAM) ist mit mehreren Clients 2 (CL) verbunden. Im vorliegenden Ausführungsbeispiel sind drei unterschiedliche Typen von Clients vorgesehen, nämlich Inputmodule 2/1, ein Druckauftrag-Client 2/2 und ein Ticket-Regel-Client 2/3.
Üblicherweise sind mehrere Inputmodule 2/1 vorgesehen, die jeweils mit einem oder mehreren Rechnern 3 (RE) zum Erzeugen eines Druckauftrages über Datenleitungen 46 verbunden sind.
Typischerweise sind der Druckauftragsmanager 1 und die Inputmodule 2/1 bei einem Betreiber eines Druckzentrums angeordnet und die Rechner 3 zum Erzeugen der Druckaufträge stehen bei den Kunden des Betreibers des Drucksystems und übermitteln über ein Netzwerk, wie zum Beispiel das Internet, ihre Druckaufträge an die Input- Module .
Die Clients 2 und der Druckauftragsmanager 1 sind jeweils Computerprogrammeinheiten. Sie können auf einem gemeinsamen Computer installiert und ausgeführt werden. Es ist jedoch gleichermaßen möglich und auch bevorzugt, zumindest den Druckauftragsmanager 1 und die Clients 2 auf zumindest zwei separaten Computern zu installieren und dort auszuführen. Zwischen den Clients 2 und dem Druckauftragsmanager 1 sind Schnittstellen 47 vorgesehen, über welche Daten, insbesondere Druckaufträge ausgetauscht werden können.
Der Druckauftragsmanager wird auch als PJM-Server (Printj ob-Manager-Server) bezeichnet. Der zum Druckauftragsmanager 1 korrespondierende Druckauftrags- Client 2/2 dient dazu, dass der Operator des Drucksystems bereits vorliegende Druckaufträge ausführen kann. Derartige Druckaufträge sind zum Beispiel Druckaufträge, die nicht oder nicht korrekt gedruckt werden konnten. Der Operator kann mit Hilfe des Druckauftrag-Clients 2/2 den Druckauftrag und insbesondere das Jobticket eines solchen Druckauftrages verändern und den jeweiligen Druckauftrag zum Druckauftragsmanager 1 übermitteln, um ihn an einem Druckgerät drucken zu lassen.
Am Druckauftragsmanager 1 werden die Auftragsbegleitdaten der eingehenden Druckaufträge mit Daten, insbesondere Steuerparametern, aus einem Vorgabe-Jobticket ergänzt. Insbesondere werden den Auftragsbegleitdaten fehlende, aber bei der vorhandenen Druckumgebung notwendige Steuerparameter hinzugefügt. Falls ein
Gesamtauftragsticket vorhanden sein sollte, werden auch die Daten, insbesondere Steuerparameter des Gesamtauftragstickets im Druckauftragsmanager 1 dem drucksystemspezifischen Jobticket hinzugefügt. Bei der weiteren Bearbeitung wird das derart ergänzte drucksystemspezifische Jobticket berücksichtigt. Im Folgenden wird somit unter dem Begriff Jobticket ein drucksystemspezifisches Jobticket verstanden, das durch Daten aus einem Gesamtauftragsticket oder einem Vorgabe- Jobticket ergänzt ist, falls ein solches vorhanden ist. Der Druckauftragsmanager 1 weist ein Ticket-Regel-Modul 4 (TRM) auf, in dem Ticket-Regeln gespeichert sind. Die Ticket-Regeln werden mittels des Ticket-Regel-Moduls verwaltet und am Druckauftragsmanager zur Ausführung gebracht .
Das Ticket-Regel-Modul 4 weist eine Schnittstelle 48 zum Ticket-Regel-Client 2/3 auf, über die eine bidirektionale Kommunikation möglich ist. Der Ticket-Regel-Client 2/3 umfasst ein Regel-Editor-Modul, mit dem die im Ticket- Regel-Modul gespeicherten Ticket-Regeln editiert werden können. Das Regel-Editor-Modul ist mit einer graphischen Benutzeroberfläche (GUI) versehen, die unten noch näher erläutert wird. Das Ticket-Regel-Modul und/oder das Regel- Editor-Modul sind derart ausgebildet, dass editierte Ticket-Regeln automatisch auf eine korrekte Syntax überprüft werden. Entsprechende Fehler werden auf der graphischen Benutzeroberfläche angezeigt und es wird gegebenenfalls ein Korrekturvorschlag dargestellt.
Das Ticket-Regel-Modul 4 kann auch mit mehreren Ticket- Regel-Clients 2/3 verbunden sein. Es werden jedoch alle Ticket-Regeln ausschließlich im Ticket-Regel-Modul 4 am Druckauftragsmanager 1 gespeichert. Mit den Ticket-Regel- Clients 2/3 kann lediglich auf die im Ticket-Regel-Modul 4 gespeicherten Ticketregeln zugegriffen und diese dort verändert werden.
Das Jobticket enthält eine Liste von Steuerparametern zum Steuern des jeweiligen Druckauftrages. Die
Steuerparameterliste ist in mit jeweils einem Namen versehene Abschnitte unterteilt. Es gibt einen Abschnitt mit der Bezeichnung „files". Dieser Abschnitt kann mehrfach in einem Jobticket auftreten. Die anderen Abschnitte werden jeweils nur einmal vorgesehen. Innerhalb eines jeden Abschnittes sind die Steuerparameter mit einer Bezeichnung, die als „key" bezeichnet wird und einem spezifischen Wert, der als „value" bezeichnet wird vorgesehen. Beispielsweise gibt es im Abschnitt „files" einen Steuerparameter mit dem key „File_Copies", wobei der value des Steuerparameters eine ganze Zahl ist, die die Anzahl der Kopien definiert, die gedruckt werden sollen.
Die Ticket-Regeln umfassen eine Folge von Aktionen, die auf eingehende Auftragsbegleitdaten des empfangenen
Druckauftrages angewandt werden. Die folgenden Aktionen können ausgeführt werden: - condition: Ein Wert („value") der Auftragsbegleitdaten wird mit einem vorbestimmten Wert verglichen und bei Übereinstimmung wird das Ergebnis „wahr" und bei einer Unterscheidung das Ergebnis „falsch" ermittelt. eise: Die Aktion eise entspricht der Aktion condition, wobei bei einer Übereinstimmung das Ergebnis „falsch" und bei einer Unterscheidung das Ergebnis „wahr" ermittelt wird. setting: Mit dieser Aktion wird ein Steuerparameter in den Auftragsbegleitdaten auf einen vorbestimmten Wert gesetzt.
- variable: Mit der Aktion variable kann eine Variable definiert werden.
- message: Die Aktion message erzeugt eine Nachricht in Abhängigkeit von einem bestimmten Steuerparameter der Auftragsbegleitdaten . rule: Mit der Aktion rule wird innerhalb einer vorbestimmten Ticket-Regel eine weitere Ticket-Regel aufgerufen, die im folgenden als Unter-Ticket-Regel bezeichnet wird. Der Aufruf dieser Unter-Ticket-Regel erfolgt in Abhängigkeit eines oder mehrerer Steuerparameter der Auftragsbegleitdaten. - break: Die Aktion break beendet sofort die Ausführung der Ticket-Regel und falls die Ticket-Regel, die beendet wird, eine Unter-Ticket-Regel sein sollte, wird mit der übergeordneten Ticket-Regel fortgefahren . - exit: Die Aktion exit beendet sofort die Ausführung der Ticket-Regel. Hierbei wird nicht mit einer übergeordneten Ticket-Regel weiter fortgefahren.
- exit and stopjob: Diese Aktion beendet sofort die Ausführung der Ticket-Regel. Es wird nicht mit einer übergeordneten Ticket-Regel fortgefahren und die Bearbeitung des Druckauftrages wird auch beendet. switch/case: Mit dieser Aktion wird ein Wert eines Steuerparameters der Auftragsbegleitdaten mit einem jeden Wert verglichen, der in einer ersten Spalte einer Tabelle angegeben ist. Falls eine Übereinstimmung mit einem der Werte vorliegt, werden die Werte der Zeile dieser Tabelle automatisch in entsprechende Datenfelder, insbesondere in eine entsprechende Tabelle in der Ticket-Regel eingetragen. Dies erlaubt das automatische Übertragen von Datensätzen aus Tabellen, wobei die Tabellen außerhalb der Ticket-Regeln mit einem herkömmlichen Tabellenkalkulationsprogramm editiert werden können.
Die Folge von Aktionen einer Ticket-Regel kann wie in einem Baum verzweigt sein, wobei die Zweigstellen jeweils durch die Bedingungen „condition" oder „eise" ausgeführt werden und die Blätter des Baumes durch Aktionen dargestellt werden, die dann beim Eintreten der jeweiligen Bedingung (en) ausgeführt werden.
Mit diesen Aktionen können die Ticket-Regeln frei programmiert werden, analog zu den eingangs erwähnten client-individuellen Scripts. Mit den Ticket-Regeln können Auftragsbegleitdaten korrigiert werden (z.B. mit setting) , d.h., dass für die vorhandene Druckumgebung ungeeignete Parameter in den Auftragsbegleitdaten ersetzt bzw. gelöscht werden können. Diese Aktionen sind somit sehr mächtig, da sie die Parameter in Auftragsbegleitdaten grundsätzlich beliebig verändern können. Es können sogar Druckaufträge abgebrochen werden (exit, stopjob).
Die Ticket-Regeln erlauben eine Überprüfung der Auftragsbegleitdaten auf Korrektheit, d.h., dass geprüft wird, ob der Druckauftrag mit den Auftragsbegleitdaten an dem jeweiligen Drucker bzw. Drucksystem korrekt ausgedruckt werden kann. Diese Überprüfung erfolgt z.B. mit der Aktion condition. Mit den Ticket-Regeln kann eine Nachricht ausgegebene werden (message) , die den Operator bspw. über einen Fehler in den Auftragsbegleitdaten informiert oder eine bestimmte Handlung des Operators am System fordert, die für die weitere Ausführung des Druckauftrages notwendig ist, wie z.B. das Einlegen von Spezialpapier oder das Zuführen von Spezialtoner .
Die Ticket-Regeln können zwar an unterschiedlichen Clients programmiert werden, da sie jedoch zentral gespeichert sind, stehen dem Operator bzw. einer anderen Person, die die Ticket-Regeln beeinflussen kann, immer der gesamte Satz an Ticket-Regeln zur Verfügung. Hierdurch werden Fehler vermieden, wie sie bei herkömmlichen Systemen auftreten, bei denen die entsprechenden Anweisungen zum Beeinflussen der Auftragsbegleitdaten auf unterschiedliche Computer verteilt gespeichert sind und der Operator oftmals keinen Überblick über alle Regeln hat.
Mit einem Satz Ticket-Regeln können somit aus unterschiedlichen Quellen stammende Auftragsbegleitdaten zentral an einer einzigen Stelle überprüft und ggfs. korrigiert werden. Die Ticket-Regeln dienen somit der zentralen und einheitlichen Überprüfung von
Auftragsbegleitdaten unterschiedlicher Druckaufträge.
Der Druckauftragsmanager 1 ist mit seinem Ticket-Regel- Modul 4, in dem die Ticket-Regeln gespeichert sind, möglichst nahe am Drucker bzw. an den Druckern angeordnet, so dass die Ticket-Regeln spezifisch für die jeweilige Druckumgebung definierbar sind. Vorzugsweise ist der Druckauftragsmanager 1 unmittelbar mit einem oder mehreren Druckern verbunden oder es ist lediglich ein Druckserver jeweils zwischen dem Druckauftragsmanager 1 und einem der Drucker angeordnet. Im Rahmen der Erfindung ist es auch möglich, den Druckauftragsmanager in den Drucker zu integrieren .
Bei dem vorliegenden Ausführungsbeispiel wird ein bei einem Client 2 eingehender Druckauftrag an den
Druckauftragsmanager 1 weitergeleitet, wobei bei dieser Weiterleitung bzw. Übermittlung des Druckauftrages vom Client 2 an den Druckauftragsmanager 1 eine Funktion aufgerufen wird, die die Bearbeitung des jeweiligen Druckauftrages vornimmt. Mit dem Aufruf dieser Funktion wird vom Client 2 ein Parameter zu dieser Funktion übergegeben, der einen Verweis auf eine entsprechende Ticket-Regel beinhaltet, mit welcher die Auftragsbegleitdaten des Druckauftrages überprüft werden. Diese Funktion ruft daher in Abhängigkeit von dem übergebenen Parameter die Ticketregel am Druckauftragsmanager 1 auf
Ein Bildschirmausdruck der graphischen Benutzeroberfläche des Ticket-Regel-Clients 2/3 ist in Figur 2 gezeigt.
Die graphische Benutzeroberfläche umfasst eine Hauptleiste 5 (Main tool bar) , ein Aufklappmenü 6 für die Ticket- Regeln (Ticket Rules drop down menu) , ein Regeldefinitions-Fenster 7 (RuIe definition window) , eine Regeldefinitionsleiste 8 (RuIe definition tool bar) und eine Regelaktivationsliste 9 (RuIe activation list) .
Die Hauptleiste 5 ist in Figur 3 in vergrößerter Darstellung nochmals gezeigt. Sie weist sieben Piktogramme 10, 11, 12, 13, 14, 15, 16 auf. Durch Anklicken eines der Piktogramme mit einer Computermaus kann eine bestimmte Funktion ausgelöst werden.
Mit dem Piktogramm 10 wird die aktuelle Konfiguration der Ticket-Regeln gespeichert. Diese Änderungen werden im Ticket-Modul 4 gespeichert. Sollten auf der graphischen Benutzeroberfläche Änderungen an Ticket-Regeln vorgenommen worden sein, so werden sie erst auf eingehende Auftragsbegleitdaten angewandt, wenn das Piktogramm 10 betätigt worden ist, das heißt, wenn sie im Ticket-Regel- Modul 4 gespeichert sind.
Beim Betätigen des Piktogramms 11 werden alle Änderungen verworfen, die seit der letzten Speicherung der Ticket- Regeln vorgenommen worden sind.
Mit dem Piktogramm 12 wird eine neue Regel erzeugt. Der Benutzer wird zunächst nach dem Namen der neuen Regel gefragt. Die neue Regel wird dann an die Regelaktivationsliste 9 angehängt und ist aktiviert. Sie enthält noch keine Aktionen.
Mit dem Piktogramm 13 kann eine bestehende Ticket-Regel auf eine neue Ticket-Regel kopiert werden. Auch hier wird der Benutzer zunächst nach dem Namen der neuen Ticket- Regel gefragt. Alle Aktionen der kopierten Ticket-Regel werden in die neue Ticket-Regel kopiert.
Das Piktogramm 14 dient zum Löschen einer Ticket-Regel. Mit den Piktogrammen 15 und 16 können die in der Regelaktivationsliste 9 aufgeführten Ticket-Regeln nach oben bzw. nach unten um jeweils einen Schritt verschoben werden .
Figur 4 zeigt das Aufklappmenü 6 im aufgeklappten Zustand, in dem die oben anhand der Piktogramme 10 bis 16 erläuterten Funktionen aufgerufen werden können.
In der Regelaktivationsliste 9 (Figur 5) sind alle Ticket- Regeln tabellarisch aufgeführt. In einer ersten Spalte ist der Aktivierungszustand, in einer zweiten Spalte der Regelname und in einer dritten Spalte eine Regelbeschreibung angegeben. Diese Regelbeschreibung kann entweder automatisch aus der vorhandenen Abfolge von Aktionen generiert oder kann über ein eigenes Fenster manuell eingegeben werden. Wahlweise kann die generierte Beschreibung oder die selbst erstellte Beschreibung angezeigt werden. Die manuell erstellte Beschreibung wird zusammen mit einer entsprechenden Regel abgespeichert .
Es gibt drei Aktivierungszustände : (active, inactive) und Unter-Ticket-Regel (sub-rule) .
Ein Benutzer kann festlegen ob eine bestimmte Regel den Modus „aktiv" oder „inaktiv" aufweisen soll. Der Modus „inaktiv" wird verwendet wenn eine bestimmte Regel nicht auf eingehende Job-Tickets angewandt werden soll. Dies ist bei alten Regeln zweckmäßig, die vorübergehend nicht benutzt werden sollen oder bei neuen Regeln, die noch nicht ausreichend getestet sind. Somit ist es möglich eine Ticket-Regel für den späteren Gebrauch zu definieren.
In den Modus „aktiv" kann eine Regel gesetzt werden, wenn sie ausführbar und keine Unter-Ticket-Regel ist. Die einzelnen Regeln werden von dem Regelmodul 4 automatisch auf ihre Ausführbarkeit, das heißt auf die Korrektheit ihrer Syntax geprüft. Diese Überprüfung erfolgt nach jeder Änderung einer Regel. Ist die Regel ausführbar, so wird sie in der Regelaktivationsliste in schwarzer Schrift dargestellt. Ist sie hingegen nicht ausführbar, wird sie in dieser Liste mit einer roten Schrift dargestellt. Im Modus „inaktiv" ist die Schrift jeweils transparent ausgeführt .
Eine Ticket-Regel mit dem Modus „Unter-Ticket-Regel" kann nur als Unter-Ticket-Regel verwendet werden, das heißt, dass sie von einer anderen übergeordneten Regel aufgerufen werden muss. Unter-Ticket-Regeln werden in der Regelaktivationsliste 9 in kursiver Schrift in schwarz für ausführbare und in rot für nicht ausführbare Regeln dargestellt. Durch Doppelklicken auf ein Element in der dritten Spalte (Regelbeschreibung) öffnet sich ein Fenster (Figur 8) zum Editieren der Regelbeschreibung. Wird in diesem Fenster auf das Piktogramm „Ok" geklickt, so wird die entsprechende Regelbeschreibung übernommen.
Die Regeldefinitions-Leiste 8 (Fig. 6) enthält Piktogramme 17, 18, 19, 20, 21, 22, 23, 24, 25 und 14 die zum
Hinzufügen und Löschen von Aktionen zu einer Regeldefinition dienen.
Mit dem Piktogramm 17 wird ein Bedingungsdefinitionsfenster 26 (Figur 10) aufgerufen, mit dem Bedingungen editiert werden können. Dies wird unten näher erläutert.
Mit dem Piktogramm 18 wird ein Setz-Definitions-Fenster 28 (Figur 11) geöffnet. Ein jede Setz-Definition (Setting) umfasst einen Namen, einen Steuerparameter, einen Wert und ein Überschreib-Flag. Eine Setz-Definition dient dazu, einen Steuerparameter im Jobticket auf einen bestimmten Wert zu setzen. Dies ist unten näher erläutert.
Das Piktogramm 19 dient zum Hinzufügen und Editieren von Variablen. Mit Betätigen dieses Piktogramms wird ein Variablen-Editor-Fenster 28 geöffnet (Figur 12) .
Das Piktogramm 20 dient zum Öffnen eines
Nachrichteneditor-Fensters 29 (Figur 16) und erlaubt das Editieren von Nachrichten.
Mit dem Piktogramm 21 können Unter-Ticket-Regeln hinzugefügt werden. Aus einer Liste aller definierten Unter-Ticket-Regeln kann eine ausgewählt werden. Das Piktogramm 22 dient zum Hinzufügen der Bedingung „eise" in eine Folge von Aktionen.
Das Piktogramm 23 dient zum Hinzufügen der Aktion „break" in eine Folge von Aktionen.
Das Piktogramm 24 dient zum Hinzufügen der Aktion „exit" in eine Folge von Aktionen.
Das Piktogramm 25 dient zum Hinzufügen der Aktion „exit and stopJob" zu einer Folge von Aktionen.
Mit dem Piktogramm 14 in der Regeldefinitions-Leiste 8 kann eine ausgewählte Aktion aus einer Folge von Aktionen gelöscht werden.
Es können nicht nur die Ticket-Regeln durch Hinzufügen und/oder Entfernen von Aktionen definiert werden, sondern die Aktionen selbst können verändert, gelöscht bzw. neu erstellt werden. Hierzu sind unterschiedliche
Aktionsdefinitions-Fenster vorgesehen. Diese Fenster zeigen jeweils eine Liste aller vorliegenden Aktionen eines Typs an und erlauben das Editieren, Hinzufügen von neuen Aktionen, Entfernen von Aktionen und Kopieren von Aktionen. Jede Aktion hat einen bestimmten Status. Nur korrekt definierte Aktionen erhalten den Status „wahr" der durch eine schwarze Schrift dargestellt wird. Bei einem Status „falsch" ist die Farbe der Schrift rot. Ein Beispiel einer Aktion mit einem „falschen" Status wäre eine Bedingung ohne einen definierten Steuerparameter.
Es gibt grundsätzlich zwei Möglichkeiten ein Aktionsdefinitions-Fenster zu öffnen.
1. Mit der rechten Maustaste wird eine ausgewählte Aktion im Regeldefinitions-Fenster 7 angeklickt. 2. Nach Auswahl einer Aktion im
Regeldefinitionsfenster 7 wird ein geeignetes Piktogramm zum Hinzufügen einer Aktion (Piktogramm 17 bis Piktogramm 25) in der Regeldefinitionsleiste 8 angeklickt.
Das Aktionsdefinitions-Fenster kann durch Anklicken eines „Cancel" oder „OK" Piktogramms verlassen werden. Das „OK"- Piktogramm kann nur gewählt werden, wenn ein gültiger Eintrag einer Aktion ausgewählt ist. Wenn das
Aktionsdefinitions-Fenster mittels eines geeigneten Hinzufügen-Piktogramms aus dem Regeldefinitions-Fenster 7 aufgerufen worden ist, wird die neue Aktion in die bestehende Folge von Aktionen nach der ausgewählten Aktion hinzugefügt. Wird durch Anklicken einer bestimmten Aktion im Regeldefinitions-Fenster 7 das Aktionsdefinitions- Fenster aufgerufen, so wird die im Regeldefinitions- Fenster 7 ausgewählte Aktion durch die neue definierte Aktion ersetzt.
Aktionen, die momentan von keiner Regel benutzt werden, können gelöscht werden. Wenn eine Aktion editiert wird, die von einer oder mehreren Regeln benutzt wird, öffnet sich ein Fenster, in dem die Namen aller Ticket-Regeln aufgeführt sind, die diese Aktion benutzen und der
Benutzer wird aufgefordert dies zu bestätigen, da dies die Definitionen der entsprechenden Ticket-Regeln verändern wird.
Unten werden die einzelnen Aktionsdefinitions-Fenster genauer erläutert. Einige allgemeine Merkmale und Vereinbarungen gelten für alle Aktionsdefinitions-Fenster . So kann jede Aktion einen bestimmten Namen aufweisen. Dieser Name ist einzigartig für alle Ticket-Regeln und erlaubt es, die Aktionen global in allen Ticket-Regeln aufzurufen. Dies bedeutet, dass wenn eine Aktion mit einem globalen Namen verändert wird, alle Ticket-Regeln die diese Aktion benutzen, verändert werden. Eine Aktion kann jedoch auch ohne Namen vorgesehen sein. Dann kann sie jedoch lediglich in einer einzigen Ticket-Regel aufgerufen werden .
Eine solche „namenlose" Aktion wird nur lokal angewandt. Mit der rechten Maustaste kann ein entsprechendes Aktionsdefinitions-Fenster zum Hinzufügen einer neuen Aktion aufgerufen werden. Dieses Fenster enthält eine Liste aller globalen und lokalen Aktionen. Wird eine derartige lokale Aktion erneut hinzugefügt, so wird sie in dieser Liste zusätzlich aufgeführt, auch wenn in der Liste bereits eine Aktion des gleichen Typs vorhanden sein sollte. Hiermit können die Aktionen mit den jeweiligen Parametern beliebig oft kopiert werden, wobei jede Kopie eine lokale Aktion unabhängig von der ursprünglichen Aktion ist.
Die Aktionsdefinitions-Fenster weisen eine Spalte für Steuerparameter auf. Diese Steuerparameterspalte sieht eine spezielle Combo-Box zum Eingeben eines Ticketabschnittes und eines Steuerparameters (key) vor. Falls die Steuerparameterspalte leer ist und die Combo-Box ausgewählt wird, wird eine Liste aller bekannten Abschnitte angezeigt. Danach kann der Benutzer die Combo- Box erneut aufrufen und eine Liste aller keys des ausgewählten Abschnittes wird angezeigt. Hierdurch kann durch zweimaliges Anklicken der Steuerparameter ausgewählt werden, ohne dass es notwendig ist, eine umfangreiche Liste aller Steuerparameter aufzurufen. Falls ein
Abschnitt und ein Steuerparameter ausgewählt worden sind, wird auch ein Feld „.." angeboten, um zurück in den ersten Modus der Combo-Box zu gehen, die nur die Liste der bekannten Abschnitte anzeigt. Auch hier wird ein leeres Feld angeboten, in dem ein neuer Abschnitt oder ein neuer key eingegeben werden kann. Diese selbst definierten Steuerparameter können von der Liste der bekannten Steuerparameter gelöscht werden.
Das Aktionsdefinitions-Fenster für Bedingungen, das Bedingungsdefinitions-Fenster 26 (Figur 10) umfasst eine Bedingungsdefinitionsmenüleiste 31 und eine Bedingungsdefinitionstabelle 32. Die
Bedingungsdefinitionsmenüleiste 31 umfasst die oben erläuterten Piktogramme 13, 14 und 17 mit den jeweils entsprechenden Funktionen des Hinzufügens, Löschens und Kopierens von Bedingungen.
Jede Bedingung enthält einen Parameter, einen Operator und einen Wert und kann mit einem Namen versehen sein. Der jeweilige Abschnitt und key können aus einem
Aufklappfenster jeweils gewählt werden. Die angebotene Liste von keys hängt von dem jeweils gewähltem Abschnitt ab.
Der Operator kann aus einem Aufklappfenster gewählt werden. Die folgenden Operatoren existieren:
- gleich
- gleich (Groß- und Kleinschreibung ignorieren) - nicht gleich
- nicht gleich (Groß- und Kleinschreibung ignorieren)
- enthält
- enthält (Groß- und Kleinschreibung ignorieren)
- enthält nicht - enthält nicht (Groß- und Kleinschreibung ignorieren)
- beginnt mit
- beginnt mit (Groß- und Kleinschreibung ignorieren)
- endet mit
- endet mit (Groß- und Kleinschreibung ignorieren) - existiert nicht
- kleiner als
- größer als - kleiner oder gleich
- größer oder gleich
- ist nicht gesetzt
- ist gesetzt - ist ganze Zahl
- ist Fließkommazahl
- ist Hexadezimalzahl
- ist ASCII-Code
- ist alphanumerisches Zeichen (A-Z, a-z) - ist Alnum (A-Z, a-z, 0-9)
- ist eine Ziffer
- ist eine Hexadezimalziffer (0-9, A-F, a-f)
- ist regex
Eine Bedingung mit dem Operator „existiert nicht" ist
„wahr" wenn der spezifizierte Key des Abschnittes nicht in den Auftragsbegleitdaten existieren sollte. Diese Bedingung unterscheidet sich von „ist nicht gesetzt", die prüft, ob ein bestimmter, existierender Key leer ist oder nicht existiert. Es genügt, dass eine von diesen beiden Bedingungen erfüllt wird. Der Operator „ist regex" ist wahr, wenn der bestimmte Parameter mit dem Auszug übereinstimmt, der in der entsprechenden Wertespalte in der Bedingungsdefinitionstabelle 33 angegeben ist.
Ein Wert kann sich auf eine Variabel beziehen. Variabein werden mit „$ {Variablenname }" dargestellt. Zum Beispiel ist es möglich, zu prüfen, ob der Druckername (printer name) gleich dem Druckjobnamen (Job name) ist. Die Definition von Variablen wird unten näher beschrieben.
Falls die Variablen definiert sind, ist es auch möglich, den Inhalt von Variablen zu Prüfen. Daher erlaubt der Parameter Combo-Box auch eine spezielle Variablenauswahl. Falls diese gewählt wird, wird eine Liste aller definierten Variablennamen angezeigt. Der Abschnitt „Files" benötigt eine spezielle Behandlung, da er mehrfach vorkommen kann. Eine Bedingung im Abschnitt „Files" ist wahr, wenn sie zumindest auf einen Abschnitt anwendbar ist. Falls eine Setz-Aktion (Setting) dieser Bedingung folgt, dann wird diese Setz-Aktion ausschließlich in den File-Abschnitten ausgeführt, die diese Bedingungen erfüllen. Falls eine Setz-Aktion in einem File-Abschnitt definiert ist, der nicht auf eine den File-Abschnitt verwendenden Bedingungen folgt, dann wird die Setz-Aktion in allen File-Abschnitten ausgeführt.
Die Definition einer Bedingung wird immer auf ihre Korrektheit automatisch geprüft. Falls Fehler vorliegen sollten, wie zum Beispiel eine Bezugnahme auf eine nicht definierte Variable oder auf einen Steuerparameter, der nur einen Key enthält, dann wird die derart definierte Bedingungs-Aktion mit roter Schrift in der Bedingungsdefinitionstabelle 33 dargestellt. Falls die Bedingung korrekt definiert sein sollte, wird sie mit schwarzer Schrift dargestellt.
Setz-Aktionen werden im Setz-Definitions-Fenster 27 (Fig. 11) definiert, das eine Setz-Definitionsmenüleiste 33 (Setting definition menu bar) und eine Setz-Definitions- Tabelle 34 (Setting definition table) umfasst. Die Setz- Definitions-Menüleiste 34 umfasst, die bereits oben erläuterte Piktogramme 18, 13 und 14 zum Hinzufügen, Löschen und Kopieren von Setz-Aktionen aufweisen. Weiterhin umfasst sie ein Piktogramm 35, mit dem Job- Tickets importiert werden können. In einem Fenster werden alle verfügbaren Jobtickets angezeigt. Nach dem Auswählen eines solchen Job-Tickets wird es mit all seinen Aktionen, Keys und Werten importiert und kann nun editiert werden. Diese Funktion ist vor allem dazu vorgesehen, Vorgabe- Jobtickets zu erzeugen, die vom Druckauftragsmanager 1 mit den Auftragsbegleitdaten der eingehenden Druckaufträge verbunden werden und in eingehenden Auftragsbegleitdaten nicht vorhandene Steuerparameter ergänzen.
Jede Setz-Aktion umfasst zumindest einen Parameter, einen Wert und ein Überschreib-Flag und kann mit einem Namen versehen sein. Ein Wert kann sich auf eine Variable beziehen. Ein Wert kann auch als zu „[löschen]" eingestellt sein, was bedeutet, dass der gesamte Eintrag des Steuerparameters bis hin zu den Keys im Jobticket zu Löschen ist. Dies unterscheidet sich von dem Eintrag „", mit dem nichts in den Key eingetragen wird.
Falls die Setz-Aktion einen bereits existierenden Abschnitt bzw. Keyeintrag in den Auftragsbegleitdaten überschreiben soll, dann muss das entsprechende
Überschreib-Flag gesetzt sein. Der Vorgabestatus ist ein gesetztes Überschreib-Flag.
? ?
Der Abschnitt „files" benötigt eine spezielle Behandlung, da dieser Abschnitt mehrfach auftreten kann. Falls eine Setz-Aktion einer Bedingung in einem File-Abschnitt folgt, die wahr ist, wenn sie auf einen solchen File-Abschnitt angewandt wird, dann wird diese Setz-Aktion auch ausschließlich nur in diesem File-Abschnitt durchgeführt. Falls eine Setz-Aktion in einem File-Abschnitt definiert ist, und nicht von einer Bedingung, die den File-Abschnitt verwendet, abhängt, dann gilt die Setz-Aktion für alle File-Abschnitte.
Die Korrektheit der Definitionen einer Setz-Aktion wird immer automatisch geprüft. Falls ein Fehler festgestellt wird, wird die Setz-Aktion in der Setz-Definitionstabelle 35 mit roter Schrift dargestellt. Ansonsten wird sie mit schwarzer Schrift dargestellt. Die in dem Setz-Definitions-Fenster 27 (Figur 11) gezeigten Beispiel von Setz-Aktionen bedeuten folgendes: der Name des Druckauftrages wird auf einen neuen Wert gesetzt, der mit dem Inhalt einer Variablen ($V>new j ob prefix<) beginnt und vom „ " gefolgt wird und mit dem Wert einer weiteren Variablen ($V>new job name<) endet. Da das Überschreib-Flag gesetzt wird, wird diese Setz-Aktion auch ausgeführt, wenn ein entsprechender Eintrag bereits existiert. - Der Wert des Key „Client_Company" des Abschnittes
„client" wird auf „MyCompany" gesetzt, aber nur wenn der Key nicht bereits existiert, da das Überschreib- Flag nicht gesetzt ist.
- Für alle File-Abschnitte, die eine Bedingung erfüllen und die während der Bedingungsprüfung ausgewählt sind wird der Key „file_copies" auf einen neuen Variablenwert gesetzt. Falls die Setz-Aktion nicht von einer Bedingung abhängt, die den File-Abschnitt verwendet, wird der Key „File Copies" in allen Dateien auf diesen Wert gesetzt.
Zum Bearbeiten von Variablen ist das Variablen-Editor- Fenster 28 (Figur 12) vorgesehen. Das Variablen-Editor- Fenster 28 umfasst eine Variablen-Definitions-Menüleiste 36 und eine Variablen-Definitionstabelle 37.
Jede Variabel weist zumindest einen einzigartigen Variablennamen und einen Parameter auf. Der Name ist notwendig, damit man eine Variable aufrufen kann. Alle Variablen stellen globale Einträge dar. Variablen werden in folgender Form $ {Variablenname } aufgerufen.
Eine in einer Folge von Aktionen angeordnete Variable liefert im Betrieb einen Steuerparameter an der Stelle, an der die Variable angeordnet ist. Dieser Steuerparameter kann durch vorangegangene Aktionen bereits verändert worden sein. Die Variablen-Definitions-Tabelle 38 umfasst weitere Spalten „Alteration Type" und „Alteration Code". Hierin kann eine Anweisung definiert werden, mit welcher der Inhalt der Variable verändert wird, wenn ein Steuerparameter für die Variable aus eingehenden
Auftragsbegleitdaten übernommen wird. Es gibt drei Arten von variablenverändernden Aktionen:
- Feld (Field) : Hiermit wird der Inhalt einer Variable in Felder aufgeteilt und ein gewünschtes Feld wird herausgeschnitten.
- Ersetzung (Replacement) : Hiermit wird eine vorbestimmte Zeichenfolge durch eine andere Zeichenfolge ersetzt. -Berechnung (Calculation) : Ändert den Wert einer ganzzahligen Variablen oder Fließkommazahlvariablen mittels einer mathematischen Operation.
Zum Definieren der Veränderungsvorschriften wird in der Variablendefinitionstabelle 37 die entsprechende Variable angeklickt. Durch Anklicken der entsprechenden Felder in den Spalten „Alteration Type" und „Alteration Code" öffnen sich jeweils entsprechende Ausklappmenüs aus welchen geeignete Einträge ausgewählt werden können.
Wird in der Spalte Alteration Type der Wert „Field" eingetragen, so öffnet sich ein Felddefinitionsfenster 38 (Figur 13) mit dem Datenfelder definiert werden. In diesem Fenster wird ein Feldbegrenzer („Delimiter") festgelegt, der ein Zeichen ist, mit welchem die einzelnen Feldeinträge in einer Zeichenfolge voneinander getrennt werden. Falls kein Feldbegrenzer angegeben ist, dann ist dieses Zeichen ein separates Datenfeld. Als Feldbegrenzer kann lediglich ein einzelnes Zeichen eingegeben werden.
Mit den Eingabefeldern „From Field" und „To Field" kann der Bereich der Datenfelder eingegeben werden, die aus einer vorbestimmten Zeichenfolge extrahiert werden sollen. Hierzu sind die Datenfelder zweifach nummeriert, nämlich mit positiven ganzen Zahlen, wobei dem am linken Rand angeordneten Datenfeld der Wert 1 zugeordnet ist und diese Werte von Datenfeld zu Datenfeld um jeweils 1 erhöht werden. Bei der Nummerierung mit ganzen negativen Zahlen endet die Nummerierung am rechts angeordneten Datenfeld mit dem Wert -1 und verringert sich von Datenfeld zu Datenfeld um jeweils 1 in Richtung nach links. Nachfolgend ist ein Beispiel dieser Nummerierung für die Zeichenfolge „Testring" angegeben:
1 2 3 4 5 6 7 8 9 10 T e s t s t r i n g -10 -9 -8 -7 -6 -5 -4 -3 -2 -1
In den Eingabefeldern "From Field" und "To Field" können beide Nummerierungen alternativ verwendet werden. Die positiven Zahlen werden verwendet, wenn man ein bestimmtes Datenfeld bezüglich des linken Randes definieren möchte, und die negativen Zahlen werden verwendet, wenn man ein bestimmtes Datenfeld bezüglich des rechten Randes definieren möchte. In diesem Felddefinitionsfenster 38 werden jeweils ein Datenfeldbeispiel („Example") automatisch angegeben und in der darunter angeordneten Zeile wird dargestellt, was aus diesem Datenfeldbeispiel durch die definierte Aktion wird („becomes").
Diese Felddefinition dient vor allem zum Ausschneiden von Zeichenfolgen. Sie kann jedoch auch zum Ausschneiden bestimmter numerischer Datensätze verwendet werden.
In der Variablen-Definitions-Tabelle 37 kann in der Spalte „Alteration Type" der Eintrag „Replacement" eingetragen werden, mit welchem vorbestimmte Zeichenfolgen durch andere Zeichenfolgen ersetzt werden. Hierzu öffnet sich ein Ersetzen-Definitionsfenster 39, in dem eine gesuchte Zeichenfolge in der Datenfeldzeile „Find" eingegeben wird und die Zeichenfolge, mit welcher die gesuchte Zeichenfolge zu ersetzen ist, in der Datenfeldzeile „Replace" eingegeben wird.
Weiterhin kann die Anzahl der durchzuführenden Ersetzungen in der Datenfeldzeile „Occurances" eingegeben werden. Hierin wird entweder eine ganze positive Zahl oder „all" eingegeben, was bedeutet, dass alle gefundenen Zeichenfolgen ersetzt werden. Durch Setzen eines entsprechenden Flags wird die Zeichenfolge unabhängig von der Groß- und Kleinschreibung ersetzt. Auch in diesem Ersetzen-Definitions-Fenster 39 ist wiederum eine Beispiel-Zeile „Example" vorhanden, in der eine Zeichenfolge angegeben ist, die in der darunter angeordneten Zeile entsprechend der festgelegten
Definition („becomes") verändert wird. In die Beispiel- Zeilen kann ein Benutzer auch eine beliebige Zeichenfolge eintragen, die dann entsprechend umgesetzt wird.
Wird in der Variablendefinitionstabelle 37 in der Spalte „Alteration Type" ein Wert „Calculation" eingetragen, so öffnet sich ein Berechnungsdefinitionsfenster 40 (Figur 15) . In diesem Berechnungsdefinitionsfenster 40 kann in einem Feld 41 ein Operator einer der vier Grundrechenarten „+", „-", „*", oder „/" eingegeben werden und in einem Feld 42 der Berechnungswert, der mit dem entsprechenden Operator auf eine Variable für ganze Zahlen oder Fließkommazahlen angewandt wird.
Das erfindungsgemäße System erlaubt das Ausgeben von Nachrichten, wenn die Ticket-Regeln am
Druckauftragsmanager 1 zur Auswahl gebracht werden. Dies ist in Verbindung mit der zentralen Ausführung aller Ticket-Regeln besonders vorteilhaft, da diese Nachrichten, die vor allem Warnungen und Fehlermeldungen sind, zentral an einer Stelle im Druckauftragsmanager ausgegeben werden und so eine zuverlässige Überwachung derselben möglich ist.
Durch Anklicken des Piktogramms 20 in der Regeldefinitions-Leiste 8 wird das Nachrichten-Editor- Fenster 29 (Figur 16) geöffnet. Dieses Fenster umfasst eine Nachrichten-Definitions-Menüleiste 43 und eine Nachrichtendefinitionstabelle 44. In der Nachrichtendefinitionsmenüleiste 43 sind Piktogramme 20, 14, 13 zum Hinzufügen, Löschen und Kopieren einer Nachricht aufgeführt. Jede Nachricht umfasst eine Nachrichten-Identifikation („Message-ID") , einen Nachrichtentyp („Type"), einen kurzen Nachrichtentext („Short Text"), einen langen Nachrichtentext („Long Text") und einen optionalen Text („Optional Text") . Es muss zumindest ein kurzer und ein langer Nachrichtentext eingegeben sein, damit die Nachricht gültig ist. Im Nachrichtentext können auch Variabein verwendet werden, deren Inhalt beim Aufrufen angezeigt wird.
Nach dem Erstellen einer Nachricht erfolgt immer eine Prüfung auf Korrektheit der Nachricht. Falls die Nachricht nicht korrekt sein sollte, wird sie in roter Schrift dargestellt, ansonsten in schwarzer Schrift.
Beim Anklicken des Piktogramms 21 in der Regeldefinitions- Leiste 8 wird ein Unter-Regel-Fenster 45 (Figur 17) geöffnet, in dem alle Unter-Ticket-Regeln aufgeführt sind. Das Hinzufügen neuer Unter-Ticket-Regeln erfolgt in der Regelaktivations-Liste 9, indem in der Aktivations-Spalte der entsprechende Eintrag für eine bestimmte Regel auf Unter-Ticketregel („Sub-Rule") geändert wird. Deshalb dient das Unter-Regel-Fenster 45 lediglich zur Information und nicht zum Editieren der Unter-Ticket-Regeln.
Bei dem oben erläuterten System zum automatischen Bearbeiten eines Druckauftrages werden die Druckaufträge mit dem damit verbundenen Auftragsbegleitdaten automatisch am Druckauftragsmanager 1 bearbeitet, wobei nach einer vorbestimmten Ticket-Regel ein drucksystemspezifisches Jobticket erzeugt wird.
Im Rahmen der Erfindung ist es auch möglich, dass in den Auftragsbegleitdaten eine Ticket-Regel explizit aufgerufen wird, damit nicht aus Versehen Steuerparameter des Jobtickets bzw. Datenticket geändert werden. Hierzu ist in den Auftragsbegleitdaten folgender Befehl einzutragen:
TicketRule = „Test RuIe 1"
Zwischen den Anführungszeichen steht der Name der aufzurufenden Ticket-Regel.
Das Eintragen der Ticket-Regel in die Auftragsbegleitdaten kann am Client 2 oder bei einer vorgelagerten Bearbeitungsstufe und/oder bei der Erstellung der Auftragsbegleitdaten erfolgen.
Im Rahmen der Erfindung ist es auch möglich, eine SuperTicket-Regel vorzusehen, die grundsätzlich alle eingehenden Auftragsbegleitdaten nach vorbestimmten Kriterien und Parametern überprüft und in Abhängigkeit von der Prüfung eine jeweils geeignete Ticket-Regel aufruft, falls eine solche vorhanden ist, oder ein eingehendes Job- Ticket ohne weitere Überprüfung durch eine Ticket-Regel weiterleitet. Bei einer solchen Ausführungsform der Erfindung sind in den Auftragsbegleitdaten keine entsprechenden Verweise auf Ticket-Regeln einzutragen bzw. beim Aufruf kein entsprechender Parameter mitzugeben.
Die Erfindung ist oben anhand eines Ausführungsbeispiels erläutert worden, bei welchem entweder ein eingehendes Jobticket ergänzt wird oder anhand eines Vorgabe- Jobtickets ein für das Drucksystem spezifisches Jobticket erzeugt wird. Im Rahmen der Erfindung ist es jedoch auch möglich, dass ein eingehendes Jobticket eines bestimmten Formates in das im vorliegendem Drucksystem angewandte Format für Jobtickets umgewandelt wird.
Die Erfindung kann folgendermaßen kurz zusammengefasst werden :
Die Erfindung betrifft ein Verfahren, ein Drucksystem und ein Computerprogramm zum automatischen Bearbeiten von Auftragsbegleitdaten eines Druckauftrages.
Mit der Erfindung werden eingehende Auftragsbegleitdaten eines Druckauftrages an einem Druckauftragsmanager zentral mittels vorbestimmter Ticket-Regeln überprüft und gegebenenfalls durch weitere Druckparameter ergänzt oder geändert, so dass aus den Auftragsbegleitdaten ein drucksystemspezifisches Jobticket gebildet wird, mit welchem der Druckauftrag korrekt im jeweiligen Drucksystem ausgedruckt werden kann.
Die zentrale Überprüfung der Auftragsbegleitdaten am Druckauftragsmanager erlaubt eine einfache Verwaltung der Ticket-Regeln und durch die Nähe zum Druckserver und den daran angeschlossenen Druckgeräten ist eine sehr drucksystemspezifische Bearbeitung der Jobtickets möglich.
Bezugszeichenliste
1 Druckauftragsmanager
2 Client 3 Rechner
4 Ticket-Regel-Modul
5 Hauptleiste
6 Aufklappmenü
7 Regeldefinitions-Fenster 8 Regeldefinitions-Leiste
9 Regelaktionsliste
10 Piktogramm
11 Piktogramm
12 Piktogramm 13 Piktogramm
14 Piktogramm
15 Piktogramm
16 Piktogramm
17 Piktogramm 18 Piktogramm
19 Piktogramm
20 Piktogramm
21 Piktogramm
22 Piktogramm 23 Piktogramm
24 Piktogramm
25 Piktogramm
26 Bedingungsdefinitionsfenster
27 Setz-Definitions-Fenster 28 Variablen-Editor-Fenster
29 Nachrichten-Editor-Fensters 30
31 Bedingungsdefinitionsmenüleiste
32 Bedingungsdefinitionstabelle 33 Setz-Definitionsmenüleiste
34 Setz-Definitionstabelle
35 Piktogramm 36 Variablen-Definitionsmenüleiste
37 Variablen-Definitionstabelle
38 Felddefinitionsfenster
39 Ersetzen-Definitions-Fenster 40 Berechnungs-Definitions-Fenster
41 Feld
42 Feld
43 Nachrichten-Definitions-Menüleiste 44 Nachrichten-Definitions-Tabelle 45 Unter-Regel-Fenster
46 Datenleitung
47 Schnittstelle
48 Schnittstelle

Claims

Patentansprüche
1. Verfahren zum automatischen Bearbeiten von Auftragsbegleitdaten eines Druckauftrages, die Steuerparameter zum Steuern eines Druckvorganges beinhalten, in einem Drucksystem mit einem
Druckauftragsmanager (1), einem oder mehreren Clients (2), an welchen Druckaufträge erzeugt werden, und einem Druckserver zum Zuführen der Druckaufträge an ein Druckgerät, umfassend
- Empfangen eines Druckauftrages mit den
Auftragsbegleitdaten von einem der Clients (2) durch den Druckauftragsmanager (1),
- Überprüfen der Auftragsbegleitdaten nach vorbestimmten, frei programmierbaren Ticket-Regeln zentral am
Druckauftragsmanager (1) und Ausgeben eines drucksystemspezifischen Jobtickets, und
- Weiterleiten des Druckauftrages mit dem drucksystemspezifischen Jobticket zum Druckserver.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t, dass Auftragsbegleitdaten von Druckaufträgen überprüft werden, die aus unterschiedlichen Quellen stammen.
3. Verfahren nach Anspruch 1 oder 2, d a d u r c h g e k e n n z e i c h n e t, dass beim Überprüfen der Auftragsbegleitdaten anhand der Ticket-Regeln ein Druckauftrag abgebrochen werden kann (exit, stopjob).
4. Verfahren nach einem der Ansprüche 1 bis4, d a d u r c h g e k e n n z e i c h n e t, dass beim Überprüfen der Auftragsbegleitdaten anhand der Ticket-Regeln eine Nachricht ausgegeben werden kann (message) .
5. Verfahren nach einem der Anspruch 1 bis 4, d a d u r c h g e k e n n z e i c h n e t, dass ein zentrales Ticket-Regel-Modul (4) am Druckauftragsmanager (1) betrieben wird, mit dem alle Ticket-Regeln verwaltet werden.
6. Verfahren nach Anspruch 5, d a d u r c h g e k e n n z e i c h n e t, dass die Jobtickets ausschließlich mittels vom Ticket- Regel-Modul (4) bereitgestellten Ticket-Regeln überprüft werden .
7. Verfahren nach Anspruch 5 oder 6, d a d u r c h g e k e n n z e i c h n e t, dass das Überprüfen der Auftragsbegleitdaten vom Ticket- Regel-Modul (4) ausgeführt wird.
8. Verfahren nach einem der Ansprüche 1 bis 7, d a d u r c h g e k e n n z e i c h n e t, dass beim Überprüfen der Auftragsbegleitdaten ein darin enthaltenes Jobticket bei Bedarf automatisch verändert wird.
9. Verfahren nach einem der Ansprüche 1 bis 8, d a d u r c h g e k e n n z e i c h n e t, dass am Druckauftragsmanager (1) mit einem Druckauftrag eingehende Auftragsbegleitdaten mit einem Vorgabe- Jobticket zusammengeführt werden.
10. Verfahren nach einem der Ansprüche 1 bis 9, d a d u r c h g e k e n n z e i c h n e t, dass beim Überprüfen der Auftragsbegleitdaten das Format eines darin enthaltenen Jobtickets bei Bedarf automatisch verändert wird.
11. Verfahren nach einem der Ansprüche 1 bis 12, d a d u r c h g e k e n n z e i c h n e t, dass die Ticket-Regeln eine Folge von Aktionen umfassen.
12. Verfahren nach Anspruch 11, d a d u r c h g e k e n n z e i c h n e t, dass die Folge von Aktionen eine oder eine Kombination aus einer oder mehreren der folgenden Aktionen umfasst: condition: Ein Wert eines Steuerparameters des Jobtickets wird mit einem vorbestimmten Wert verglichen und bei Übereinstimmung wird das Ergebnis „wahr" und bei einer Unterscheidung das Ergebnis „falsch" ermittelt.
- eise: Ein Wert eines Steuerparameters der Auftragsbegleitdaten wird mit einem vorbestimmten Wert verglichen und bei einer Übereinstimmung wird das Ergebnis „falsch" und bei einer Unterscheidung das Ergebnis „wahr" ermittelt, setting: Mit dieser Aktion wird eine Bezeichnung (key) eines Steuerparameters im Jobticket auf einen vorbestimmten Wert gesetzt.
- variable: Mit der Aktion variable wird eine Variable definiert .
- message: Die Aktion message erzeugt eine Nachricht in Abhängigkeit vom Wert eines bestimmten
Steuerparameters der Auftragsbegleitdaten, rule: Mit der Aktion rule wird innerhalb einer vorbestimmten Ticket-Regel eine weitere Ticket-Regel, die Unter-Ticket-Regel, aufgerufen, wobei der Aufruf dieser Unter-Ticket-Regel in Abhängigkeit eines oder mehrerer Steuerparameter der Auftragsbegleitdaten erfolgt .
- break: Die Aktion break beendet sofort die Ausführung der Ticket-Regel und falls die Ticket-Regel, die beendet wird, eine Unter-Ticket-Regel sein sollte, wird mit der übergeordneten Ticket-Regel fortgefahren . exit: Die Aktion exit beendet sofort die Ausführung der Ticket-Regel und falls die Ticket-Regel, die beendet wird, eine Unter-Ticket-Regel sein sollte, wird nicht mit einer übergeordneten Ticket-Regel weiter fortgefahren.
- exit and stopjob: Diese Aktion beendet sofort die Ausführung der Ticket-Regel und es wird nicht mit einer übergeordneten Ticket-Regel fortgefahren und die Bearbeitung des Druckauftrages wird auch beendet. - switch/case: Mit dieser Aktion wird ein Wert eines Steuerparameters der Auftragsbegleitdaten mit einem jeden Wert verglichen, der in einer ersten Spalte einer Tabelle angegeben ist und falls eine Übereinstimmung mit einem der Werte vorliegt, werden die Werte der Zeile dieser Tabelle automatisch in entsprechende Datenfelder, insbesondere in eine entsprechende Tabelle in der Ticket-Regel eingetragen .
13. Verfahren nach einem der Ansprüche 1 bis 12, d a d u r c h g e k e n n z e i c h n e t, dass eine in einer Folge von Aktionen angeordnete Variable im Betrieb einen Steuerparameter an der Stelle, an der die Variable angeordnet ist, liefert.
14. Verfahren nach Anspruch 13, d a d u r c h g e k e n n z e i c h n e t, dass der Inhalt einer Variablen durch einer der folgenden variablenverändernden Aktionen verändert wird: - Feld: Hiermit wird der Inhalt einer Variable in Felder aufgeteilt und ein gewünschtes Feld wird herausgeschnitten .
- Ersetzung: Hiermit wird eine vorbestimmte Zeichenfolge durch eine andere Zeichenfolge ersetzt. - Berechnung: Ändert den Wert einer ganzzahligen
Variablen oder Fließkommazahlvariablen mittels einer mathematischen Operation.
15. Drucksystem zum automatischen Bearbeiten eines Jobtickets, umfassend
- einen Druckauftragsmanager (1), - einen oder mehrere Clients (2), an welchen Druckaufträge erzeugt werden, und
- einen Druckserver zum Zuführen der Druckaufträge an ein Druckgerät, wobei der Druckauftragsmanager (1) zum Ausführen eines Verfahrens nach einem der Ansprüche 1 bis 14 mit einem Ticket-Regel-Modul (4) versehen ist.
16. Drucksystem nach Anspruch 15, d a d u r c h g e k e n n z e i c h n e t, dass das Ticket-Regel-Modul (4) mit einer Schnittstelle zu Clients (2) versehen ist, welche mit einem Regel-Editor- Modul versehen sind, mit welchem Ticket-Regeln editiert werden können.
17. Drucksystem nach Anspruch 16, d a d u r c h g e k e n n z e i c h n e t, dass das Regel-Editor-Modul eine graphische Benutzeroberfläche (GUI) aufweist.
18. Drucksystem nach Anspruch 16 oder 17, d a d u r c h g e k e n n z e i c h n e t, dass das Ticket-Regel-Modul (4) und/oder das Regel-Editor- Modul derart ausgebildet sind, dass editierte Ticket- Regeln automatisch auf eine korrekte Syntax überprüft werden.
19. Drucksystem nach einem der Ansprüche 16 bis 18, d a d u r c h g e k e n n z e i c h n e t, dass das Ticket-Regel-Modul (4) und/oder das Regel-Editor- Modul derart ausgebildet sind, dass alle editierten
Ticket-Regeln im Ticket-Regel-Modul gespeichert und dort verwaltet werden.
20. Computerprogramm, das zum Ausführen eines Verfahrens nach einem der Ansprüche 1 bis 14 ausgebildet ist.
21. Computerprogramm nach Anspruch 20, d a d u r c h g e k e n n z e i c h n e t, dass das Computerprogramm auf einem Datenträger gespeichert ist.
PCT/EP2008/052129 2007-02-28 2008-02-21 Verfahren, drucksystem und computerprogramm zum automatischen bearbeiten von auftragsbegleitdaten eines druckauftrages Ceased WO2008104496A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102007009737.0 2007-02-28
DE102007009737A DE102007009737B4 (de) 2007-02-28 2007-02-28 Verfahren, Drucksystem und Computerprogramm zum automatischen Bearbeiten von Auftragsbegleitdaten eines Druckauftrages

Publications (1)

Publication Number Publication Date
WO2008104496A1 true WO2008104496A1 (de) 2008-09-04

Family

ID=39469531

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2008/052129 Ceased WO2008104496A1 (de) 2007-02-28 2008-02-21 Verfahren, drucksystem und computerprogramm zum automatischen bearbeiten von auftragsbegleitdaten eines druckauftrages

Country Status (2)

Country Link
DE (1) DE102007009737B4 (de)
WO (1) WO2008104496A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8488189B2 (en) 2007-08-06 2013-07-16 OCé PRINTING SYSTEMS GMBH Method for the creation of a template
CN110084567A (zh) * 2019-04-26 2019-08-02 深圳前海微众银行股份有限公司 电子印章使用方法、装置、设备及计算机可读存储介质
CN111756799A (zh) * 2020-05-20 2020-10-09 拉扎斯网络科技（上海）有限公司 一种打印信息的处理方法及装置

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2078241A2 (de) 2006-09-22 2009-07-15 Océ Printing Systems GmbH Verfahren und system zum automatischen übertragen von druckdaten und insbesondere zum spiegeln von druckaufträgen
DE102007036986B4 (de) 2007-08-06 2011-06-16 OCé PRINTING SYSTEMS GMBH Verfahren zum automatischen Aufbereiten und Trennen von in einem Dokumentendatenstrom enthaltenen Dokumentenbearbeitungsdaten
DE102007036985B4 (de) 2007-08-06 2010-12-16 OCé PRINTING SYSTEMS GMBH Verfahren, System und Computerprogrammprodukt zum automatischen Aufbereiten von Dokumentenbearbeitungsdaten

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040111430A1 (en) * 2002-12-10 2004-06-10 William Hertling System and method for dynamic sequencing of a requirements-based workflow
US20050004893A1 (en) * 2003-07-02 2005-01-06 Sangroniz James M. Workflow management devices and systems, and workflow assignment and management methods
US20050043845A1 (en) * 2003-08-07 2005-02-24 Hewlett-Packard Development Company, L.P. Managing workflow in a commercial printing environment with high performance prepress rework at print service provider location

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5718520A (en) 1995-05-22 1998-02-17 Xerox Corporation Apparatus and method for modifying a print job ticket
US7242490B1 (en) 2000-10-10 2007-07-10 Hewlett-Packard Development Company, L.P. Internet print managing system and method with print job distribution
US7405836B2 (en) 2000-12-26 2008-07-29 Xerox Corporation Job submission system and method for controlling multiple job renderings with a single master or “super” ticket
JP3947062B2 (ja) * 2002-08-21 2007-07-18 大日本スクリーン製造株式会社 印刷システム、印刷データ作成装置、印刷装置、印刷物の一部変更印刷方法、およびプログラム
DE102004047327A1 (de) * 2004-09-29 2006-04-06 OCé PRINTING SYSTEMS GMBH Verfahren und System zum automatischen Bearbeiten eines Jobtickets für einen Druckprozess

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040111430A1 (en) * 2002-12-10 2004-06-10 William Hertling System and method for dynamic sequencing of a requirements-based workflow
US20050004893A1 (en) * 2003-07-02 2005-01-06 Sangroniz James M. Workflow management devices and systems, and workflow assignment and management methods
US20050043845A1 (en) * 2003-08-07 2005-02-24 Hewlett-Packard Development Company, L.P. Managing workflow in a commercial printing environment with high performance prepress rework at print service provider location

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8488189B2 (en) 2007-08-06 2013-07-16 OCé PRINTING SYSTEMS GMBH Method for the creation of a template
CN110084567A (zh) * 2019-04-26 2019-08-02 深圳前海微众银行股份有限公司 电子印章使用方法、装置、设备及计算机可读存储介质
CN111756799A (zh) * 2020-05-20 2020-10-09 拉扎斯网络科技（上海）有限公司 一种打印信息的处理方法及装置
CN111756799B (zh) * 2020-05-20 2023-04-07 拉扎斯网络科技（上海）有限公司 一种打印信息的处理方法及装置

Also Published As

Publication number Publication date
DE102007009737B4 (de) 2010-09-16
DE102007009737A1 (de) 2008-09-04

Similar Documents

Publication Publication Date Title
EP1155850B1 (de) System und Verfahren zur Darstellung und Steuerung des Druckproduktions-Workflows in der Hochleistungsdruckproduktion
DE69820413T2 (de) Gebraucherschnittstelle für einen drucker/kopierer, an einer entfernten stelle eines internet/intranetzes
DE69725451T2 (de) Drucken in offenen systemen
EP1156437A2 (de) Schnittstelle und Verfahren zur Handhabung von zusammengesetzten Dokumenten
DE10122880A1 (de) Automatische Erzeugung von Druckanweisungen
EP1156412A2 (de) Effektiver Gebrauch von Bearbeitungsvorrichtungen für Druckmedien in einem Druckauftragsdatenfluss
DE102007009737B4 (de) Verfahren, Drucksystem und Computerprogramm zum automatischen Bearbeiten von Auftragsbegleitdaten eines Druckauftrages
EP1565810B1 (de) System und verfahren zur automatisierten erzeugung von druckbaren dateien aus daten
EP1859340A2 (de) Verfahren zum erzeugen von druckaufträgen in einem drucksystem, verfahren zum sortieren von druckjobs in einem drucksystem, computerprogramm- produkt und drucksystem zum ausführen dieser verfahren
DE10252797A1 (de) Verfahren und System zum Erstellen von Dokumentenvorlagen mit Ressourcenverwaltung
DE19849962A1 (de) Vorrichtung und Verfahren zum Aufteilen eines Druckauftrags unter mehreren Druckern
DE102007037032A1 (de) Verfahren zum Erzeugen eines Templates
EP2199908A1 (de) Zugriffsverfahren auf ein Übertragungsmedium
DE102004047327A1 (de) Verfahren und System zum automatischen Bearbeiten eines Jobtickets für einen Druckprozess
EP1156411A2 (de) Flexible Verteilung von Druckaufträgen an Bearbeitungsstationen
DE102007036985A1 (de) Verfahren zum automatischen Aufbereiten von Dokumentenbearbeitungsdaten
EP1282883A2 (de) Verfahren und system zur transformation digitaler druckdatenströme sowie zugehörige drucker und druckerserver
DE102004047326A1 (de) Verfahren und System zum automatischen Auswählen eines Gerätes zum Bearbeiten eines Dokumentenbearbeitungsauftrages
DE10203868A1 (de) Verfahren, Empfangsserver und Computerprogramm-Modul zur automatisierten Annahme und Weiterleitung von Dokumentenbearbeitungsaufträgen
DE102006006060A1 (de) Verfahren und Anordnung zum Archivieren von Dokumentendaten sowie zum Ausgeben von in einem Archiv gespeicherten Dokumentendaten
EP3244298B1 (de) Jobmaker mit zentraler joberfassung
EP1470473A2 (de) Verfahren, computersystem und computerprogramm-modul zum erstellen von dokumentenbearbeitungsauftr gen aus variablen, seiteni ndividuellen daten und aus resourcendaten
EP1282867A2 (de) Verfahren zum erstellen eines ausgabedokuments in einem computersystem
DE102007036986A1 (de) Verfahren zum automatischen Aufbereiten und Trennen von in einem Dokumentendatenstrom enthaltenen Dokumentenbearbeitungsdaten
DE10337837B4 (de) Computergesteuertes Drucksystem, Verfahren zum Ansteuern eines solchen Systems und entsprechendes Computerprogrammprodukt

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08709163

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08709163

Country of ref document: EP

Kind code of ref document: A1