DE102007009737A1

DE102007009737A1 - Verfahren, Drucksystem und Computerprogramm zum automatischen Bearbeiten von Auftragsbegleitdaten eines Druckauftrages

Info

Publication number: DE102007009737A1
Application number: DE102007009737A
Authority: DE
Inventors: Thomas Dipl.-Phys. Harms; Armin Gnaedig
Original assignee: Oce Printing Systems GmbH and Co KG
Current assignee: Canon Production Printing Germany GmbH and Co KG
Priority date: 2007-02-28
Filing date: 2007-02-28
Publication date: 2008-09-04
Anticipated expiration: 2027-03-01
Also published as: DE102007009737B4; WO2008104496A1

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

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 Océ 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 Spezification 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 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 A1 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 Océ Digital Printing Presses (a.a.a.0.) geht ein mit dem Handelsnamen Océ PRISMAproduction bezeichnetes Serversystem hervor, das eine breite Palette von Datenströmen verarbeitet bzw. konvertiert, die dann auf IPDS-Druckern gedruckt werden. Das Océ PRISMAproduction Serversystem umfasst einen Printjobmanager 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 Printjobmanagers 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.
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 12 und ein Computerprogramm mit dem Merkmal des Anspruchs 17 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 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.
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 (lob-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:
1: wesentliche Teile eines Drucksystems zum Ausführen des erfindungsgemäßen Verfahrens schematisch vereinfacht in einem Blockschaltbild;
2: eine Bildschirmkopie der graphischen Benutzeroberfläche des erfindungsgemäßen Systems;
3 bis 7: Ausschnitte der Bildschirmkopie der graphischen Benutzeroberfläche aus 2, und
8 bis 17: Kopien von Fenstern der graphischen Benutzeroberfläche zum Darstellen und Bearbeiten von Ticket-Regeln.
Mit dem erfindungsgemäßen Verfahren werden an einem Drucksystem eingehende Auftragsbegleitdaten von entsprechenden Druckaufträgen von einem Druckauftragsmanager 1 (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 (Printjob-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.
– else: Die Aktion else 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 „else" ausgeführt werden und die Blätter des Baumes durch Aktionen dargestellt werden, die dann beim Eintreten der jeweiligen Bedingung(en)ausgeführt werden.
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 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 (Rule definition window), eine Regeldefinitionsleiste 8 (Rule definition tool bar) und eine Regelaktivationsliste 9 (Rule activation list).
Die Hauptleiste 5 ist in 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.
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 (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 (8) zum Editieren der Regelbeschreibung. Wird in diesem Fenster auf das Piktogramm „Ok" geklickt, so wird die entsprechende Regelbeschreibung übernommen.
Die Regeldefinitions-Leiste 8 (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 (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 (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 (12).
Das Piktogramm 20 dient zum Öffnen eines Nachrichteneditor-Fensters 29 (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 „else" 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 (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. Variabeln 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 (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 (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_job_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 (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 (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:
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 (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 (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 Variabeln 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 (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 Rule 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 Super-Ticket-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.

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

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

- EP 1197838 A2 [0008]
- US 2002/0080400 A1 [0009]
- US 5718520 [0010]

Zitierte Nicht-Patentliteratur

- www.cip4.org [0005]

Claims

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 Ticket-Regeln zentral am Druckauftragsmanager (1) und Ausgeben eines drucksystemspezifischen Jobtickets, und – Weiterleiten des Druckauftrages mit dem drucksystemspezifischen Jobticket zum Druckserver.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein zentrales Ticket-Regel-Modul (4) am Druckauftragsmanager (1) betrieben wird, mit dem alle Ticket-Regeln verwaltet werden.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Jobtickets ausschließlich mittels vom Ticket-Regel-Modul (4) bereitgestellten Ticket-Regeln überprüft werden.
Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass das Überprüfen der Jobtickets vom Ticket-Regel-Modul (4) ausgeführt wird.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass beim Überprüfen der Auftragsbegleitdaten ein darin enthaltenes Jobticket bei Bedarf automatisch verändert wird.
Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass am Druckauftragsmanager (1) mit einem Druckauftrag eingehende Auftragsbegleitdaten mit einem Vorgabe-Jobticket zusammengeführt werden.
Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass beim Überprüfen der Auftragsbegleitdaten das Format eines darin enthaltenen Jobtickets Bedarf automatisch verändert wird.
Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Ticket-Regeln eine Folge von Aktionen umfassen.
Verfahren nach Anspruch 8, dadurch gekennzeichnet, 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. – else: 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.
Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass eine in einer Folge von Aktionen angeordnete Variable im Betrieb einen Steuerparameter an der Stelle, an der die Variable angeordnet ist, liefert.
Verfahren nach Anspruch 10, dadurch gekennzeichnet, 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.
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 10 mit einem Ticket-Regel-Modul (4) versehen ist.
Drucksystem nach Anspruch 12, dadurch gekennzeichnet, 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.
Drucksystem nach Anspruch 13, dadurch gekennzeichnet, dass das Regel-Editor-Modul eine graphische Benutzeroberfläche (GUI) aufweist.
Drucksystem nach Anspruch 13 oder 14, dadurch gekennzeichnet, 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.
Drucksystem nach einem der Ansprüche 13 bis 15, dadurch gekennzeichnet, 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.
Computerprogramm, das zum Ausführen eines Verfahrens nach einem der Ansprüche 1 bis 11 ausgebildet ist.
Computerprogramm nach Anspruch 17, dadurch gekennzeichnet, dass das Computerprogramm auf einem Datenträger gespeichert ist.