DE69837930T2

DE69837930T2 - Vorrichtung und verfahren zum herstellen von nachverlängten graphischen ergänzungen in einem variablen abbildungssystem

Info

Publication number: DE69837930T2
Application number: DE69837930T
Authority: DE
Inventors: James L. LaGrange WARMUS; Mark G. Aurora DREYER
Original assignee: RR Donnelley and Sons Co
Current assignee: RR Donnelley and Sons Co
Priority date: 1997-10-29
Filing date: 1998-10-29
Publication date: 2008-05-08
Anticipated expiration: 2018-10-30
Also published as: EP1025513B1; WO1999022312A3; DE69837930D1; AU1368099A; WO1999022312A2; EP1025513A2; US6088710A

Description

Verwandte Anträge
Dieser Antrag bezieht sich auf den Gegenstand, der in dem am 2. Februar 1997 eingereichten, gemeinsam mit ihm anhängigen US-Antrag mit der Seriennummer 08/802,337 und dem Titel "Imposition Process and Apparatus for Variable Imaging System" beschrieben ist, wobei Letzterer eine Teilfortsetzung des am 7. Juni 1995 eingereichten US-Antrags mit der Seriennummer 08/478,397 sowie eine Teilfortsetzung des am 2. April 1996 eingereichten US-Antrags mit der Seriennummer 08/627,724 darstellt.
Technisches Gebiet
Die vorliegende Erfindung bezieht sich allgemein auf Wiedergabemethoden und -systeme, genauer gesagt auf eine Methode und ein System zur selektiven Wiedergabe von Bildern.
Hintergrundtechnik
Bei den meisten heute verwendeten Drucksystemen kommen Druckplatten oder Druckzylinder zum Einsatz, welche eingraviert oder photochemisch behandelt werden, um auf ihnen ein Bild zu erzeugen. Auf diese Platten oder Zylinder wird dann Druckertinte aufgebracht, die anschließend auf ein Substrat wie Papier übertragen wird. Bei herkömmlichen Druckerpressen werden eine Anzahl Seiten auf ein Blatt Papier aufgedruckt, das einen Druckbogen bildet, der anschließend gefalzt und mit anderen Druckbögen zusammengelegt wird. Die zusammengelegten Druckbögen werden dann gebunden, beschnitten und mit einer Endbearbeitungsvorrichtung bearbeitet, um fertige Druckerzeugnisse wie Zeitschriften, Kataloge und andere gedruckte und gebundene Produkte herzustellen.
Häufig besteht die Notwendigkeit, in einem einzigen Druckdurchlauf unterschiedliche Versionen von Druckerzeugnissen bzw. kundenspezifisch angepasste Druckerzeugnisse herzustellen. So kann beispielsweise die Herstellung einer Anzahl von Standarddruckerzeugnissen zusammen mit einer Anzahl von Druckerzeugnissen wünschenswert sein, welche zusätzliche bzw. unterschiedliche Druckbögen oder Seiten beinhalten. Auch kann es notwendig oder wünschenswert sein, spezifische Informationen in Form eines Adressetiketts, personenbezogener Daten oder Ähnlichem an der Außenseite oder im Innern der fertigen Druckerzeugnisse anzubringen. In beiden Fällen lassen sich herkömmliche Drucksysteme nur schwer so anpassen, dass sie Druckerzeugnisse dieser Art erzeugen können.
Ein Drucksystem, das in der Lage ist, verschiedene Druckerzeugnisversionen bzw. Druckerzeugnisse mit spezifischen Angaben zu erzeugen, ist in Rileys US-Patent Nr. 4,121,818 beschrieben, welches auf den Übertragungsempfänger der Sofortanwendung übertragen wurde. Das Drucksystem umfasst eine Anzahl von neben einer Bindeanlage angeordneten Beschickungsboxen, wobei jede Beschickungsbox eine Vielzahl von Druckbögen enthält. Für die Steuerung der Beschickungsboxen ist ein Steuerelement vorgesehen, welches die Ketten der Bindeanlage selektiv mit Bögen beschickt, wodurch Druckerzeugnisse unterschiedlichen Inhalts erzeugt werden können. Mithilfe eines vom Steuerelement selektiv betriebenen Tintenstrahldruckers können die Druckbögen mit maßgeschneiderten Daten und Informationen bedruckt werden. Es lassen sich auch andere Arten der Personalisierung wie die Beilage oder das Aufbringen von Karten oder ähnliches bewirken.
Andere Systeme zur Erzeugung individuell angelegter Druckerzeugnisse sind in Abrams et al., US-Patent Nr. 3,899,165 , Wong et al., US-Patente Nr. 4,500,083 und 4,574,052 , Wong, US-Patent Nr. Re 32,690 sowie Berger et al., US-Patente Nr. 4,768,766 und 4,789,147 beschrieben.
Es wurden Bildverarbeitungssysteme entwickelt, die das Sammeln von Bildern in einem Privatumfeld oder einer Büroumgebung erlauben.
So ermöglichen beispielsweise herkömmliche Textverarbeitungsprogramme wie Microsoft^® Word^®, WordPerfect^® und ähnliche Programme dem Anwender, Bilder in eine Seite zu importieren und anschließend Anweisungen zum Druck ausgewählter Seiten eines Dokuments zu geben. Daneben lassen sich in diese Programme Makros (eine Folge von Befehlen) einbauen und innerhalb dieser Programme ausführen, die beispielsweise den Druck bestimmter Seiten des Dokuments in einer bestimmten Reihenfolge zulassen. Darüber hinaus verfügen die meisten Textverarbeitungsprogramme über die Möglichkeit der Zusammenführung, mit welcher ein personalisiertes Bild mit anderen standardisierten Informationen zusammengeführt und gedruckt oder angezeigt wird. So können, um ein Beispiel zu nennen, individuelle Angaben in Form von Adressen und Adressdaten mit standardisierten Rücksendeadressen zusammengeführt und auf einer Serie von Briefumschlägen gedruckt werden.
Bei einer in CAD-Programmen (Computer Aided Design) eingebauten, gelegentlich als "Layering" bezeichneten Kapazität zur Sammlung von Bildern handelt es sich um die Erstellung und Speicherung einer Basisseite sowie einer oder mehrerer Schichtseiten ("Layer-Seiten"). Ein Anwender kann Befehle zur gleichzeitigen Anzeige oder zum Ausdruck der Basisseite und einer oder mehrerer Layer-Seiten übereinander geben, um auf diese Weise einen der Überlagerung von Diapositiven oder Folien ähnlichen Effekt zu erzielen, sodass sich daraus der Anschein einer Verbundseite ergibt.
Zwar verfügen die oben beschriebenen Bildverarbeitungssysteme über eine bestimmte Kapazität für die Erfassung von Bildern, sie sind jedoch zur raschen Herstellung unterschiedlicher Versionen eines Druckerzeugnisses nicht effektiv. Da CAD-Systeme hauptsächlich auf die Darstellung von Linien und nicht für Text oder Grafikbilder ausgelegt sind, haben sie nur einen eingeschränkten Nutzen. Sollte darüber hinaus Textverarbeitungssoftware zur Herstellung von Druckerzeugnisversionen eingesetzt werden, müssten Befehle zum separaten Ausdruck jeder Druckerzeugnisversion unmittelbar vor der Herstellung der betreffenden Version gegeben werden.
Das bedeutet, dass ein Anwender die Seiten einer ersten Druckerzeugnisversion erstellen und speichern und anschließend der Software den Befehl geben müsste, die benötigte Anzahl Exemplare der ersten Version zu drucken. Anschließend müsste der Anwender die Seiten der ersten Version aus dem Speicher abrufen, die Seiten bearbeiten und speichern, um jene Seiten zu erstellen, die in einer zweiten Version des Druckerzeugnisses vorhanden sein sollen, und dann das System anweisen, die erforderliche Anzahl von Exemplaren der zweiten Version des Druckerzeugnisses zu drucken. Für jede weitere Version des Druckerzeugnisses müssten ähnliche Schritte durchgeführt werden. Alternativ könnten die Seiten der verschiedenen Versionen des Duckerzeugnisses erstellt und gespeichert und anschließend gemeinsam gedruckt werden. In beiden Fällen wäre dieser Vorgang zur Erstellung mehrerer Versionen eines Druckerzeugnisses sehr zeitaufwändig. Darüber hinaus sind die im Rahmen von Textverarbeitungsprogrammen zur Verfügung stehenden Import- und Zusammenführungsroutinen nur für den Einsatz in Größenordnungen von weniger als einer Seite ausgelegt und daher im Bereich der Herstellung von Druckerzeugnissen nur von eingeschränktem Nutzen. Ferner sind die von Textverarbeitungssoftware verarbeiteten Daten zum Großteil (wenn nicht zur Gänze) in einem symbolischen Format. Aus diesem Grund müssen für den Druck oder die Anzeige bestimmte Daten zunächst von einem Raster-Image-Prozessor (RIP) in komplexen und zeitaufwändigen Berechnungsvorgängen, welche die Produktionszeit zusätzlich auf ein wirtschaftlich nicht mehr tragbares Niveau verlängern, in Raster umgewandelt werden.
Vor kurzem wurden neue Drucksysteme, so genannte "Demand-Drucker" entwickelt, die in der Lage sind, aus elektronischen Darstellungen heraus mit hoher Geschwindigkeit Bilder zu drucken. Der Demand-Drucker erzeugt in einem elektrofotografischen Prozess mithilfe von schmelzbaren Toner qualitativ hochwertige Farb-(oder Schwarzweiß-) Bilder. Insbesondere wird eine Papierbahn an einer Serie von Trommeln vorbeigeführt, von denen jede dem Bildmuster entsprechend für eine bestimmte, auf die Papierbahn aufzutragende Farbe elektrostatisch aufgeladen wurde.
Die Ladung wird auf das Papier übertragen, anschließend wird ein gegensätzlich geladener Toner der entsprechenden Farbe mit dem Papier in Berührung gebracht. Bahn und Toner mit der jeweiligen gegensätzlichen Ladung ziehen einander an, sodass der Toner am Papier haftet, während die anderen Farben aufgetragen werden. Die Toner und das Papier werden anschließend erwärmt, um die Toner in das Papier einzuschmelzen und so das endgültige Bild zu erzeugen. Die Bahnen werden dann in Blätter (oder "Bögen") geschnitten und die Bögen zur Erzeugung des Endprodukts nach Bedarf weiterverarbeitet.
Dank des Umstands, dass die Bilder durch einen elektrografischen Prozess erzeugt werden, sind Demand-Drucker in der Lage, im Gegensatz zu herkömmlichen Druckmaschinen, bei denen gravierte oder photochemisch aufbereitete Platten oder Zylinder zum Einsatz kommen, Bilder von hoher Qualität und unterschiedlichem Inhalt mit hoher Geschwindigkeit zu drucken.
Soll also ein anderes Bild gedruckt werden, dann bedeutet dies, dass nun nicht mehr Gravurzylinder neu graviert oder mit neuen Platten versehen werden müssen, vielmehr muss für eine solche Änderung lediglich die an den Trommeln des Druckers angelegte Ladung verändert werden. Auf diese Weise können vom selben Drucker unterschiedliche Bilder ohne wesentliche Verzögerungen gedruckt werden. Dieser Vorteil macht den Einsatz von Demand-Druckern in bestimmten Produktionsumgebungen wünschenswert.
Warmus et al. beschreiben im US-Patentantrag Seriennr. 08/478,397 mit der Überschrift "Variable Imaging Using An Electronic Press" eine Vorrichtung und eine Methode zur Steuerung einer elektronischen Druckerpresse, um feste und variable Information auf einfache und effektive Weise zu drucken. Genauer gesagt werden ein erster und ein zweiter Satz Vorlagendaten entwickelt, welche die betreffenden ersten bzw. zweiten Vorlagenseiten darstellen. Jeder Satz Vorlagendaten enthält Rahmendaten, welche feste Information darstellen, und Bereichsdaten, welche einen für variable Informationen bestimmten Blattbereich darstellen.
Auch wird eine Datenbank mit einer Anzahl von Einträgen entwickelt, von denen jeder eine variable Information darstellt. Der Drucker wird den Sätzen von Vorlagendaten und den Datenbankeinträgen entsprechend dergestalt betrieben, dass die ersten und zweiten Vorlagenseiten mit ausgewählter variabler Information angezeigt werden.
Die von Warmus et al. beschriebene Vorrichtung und Methode generiert eine Darstellung jeder einzelnen Seite in Seitendefinitionssprache und generiert anschließend eine Darstellung jeder ausgeschossenen Blattseite, d.h. jeder Seite eines mit zwei oder mehreren Druckseiten zu bedruckenden Papiers, in Seitendefinitionssprache. Dieses Verfahren ist kann rechenaufwändig sein und die Produktivität einschränken.
Bisheriger Stand der Technik von Erfüllungssystemen
Der Vorgang der Zusammenstellung zusätzlicher Informationen in einem spezifisch erstellten Dokument wird als Erfüllung bezeichnet. Bisher wurde Erfüllung üblicherweise durch das Vordrucken aller statischen Erfüllungsstücke im Offline-Betrieb und Lagerung derselben in sortierten Behältern erzielt. Nach Herstellung des spezifisch erstellten Dokuments werden die den zum Versand kommenden spezifisch erstellten Dokumenten entsprechenden statischen Erfüllungsstücke zusammengestellt. Die Zusammenstellung der spezifisch erstellten Dokumente und der Erfüllungsstücke erfolgt meist manuell. Wenn beispielsweise Hans Müller zusammen mit dem spezifisch für ihn erstellten Dokument die statischen Erfüllungsstücke A, B und C erhalten soll, entnimmt ein Produktionsmitarbeiter die statischen Stücke A, B und C den entsprechenden Behältern manuell und stellt sie für den Postversand mit dem spezifisch erstellten Dokument zusammen.
Dieser Erfüllungsvorgang ist anfällig für menschliche Fehler, da die Person, welche die Erfüllungsstücke den Behältern entnimmt, unbeabsichtigt ein Erfüllungsstück einem falschen Behälter entnehmen kann. Daneben kann es vorkommen, dass die für das Auffüllen der Behälter mit den Erfüllungsstücken verantwortliche Person die Behälter mit den falschen Stücken auffüllt, was dazu führen würde, dass die "falschen" Erfüllungsstücke den "richtigen" Behältern entnommen würden. Eine weitere Schwäche des manuellen Erfüllungsvorgangs ist in der Notwendigkeit der Lagerung der vorgedruckten Erfüllungsstücke zu suchen, was Lagerkosten verursachen und zur Veralterung der Erfüllungsstücke führen kann. Darüber hinaus übersteigt in den meisten Fällen die Anzahl der vorgedruckten Stücke den prognostizierten Bedarf; damit soll vermieden werden, dass der Vorrat an Erfüllungsstücken vorzeitig aufgebraucht wird, falls vorgedruckte Stücke beschädigt sind oder Mängel wie Verschmutzung aufweisen. Das Drucken einer zu hohen Anzahl führt bei Beendigung einer Aufgabe zur Entsorgung der überzähligen Erfüllungsstücke in den Abfall.
Da im herkömmlichen Verfahren Erfüllungsstücke auf Offline-Druckern gedruckt werden, müssen sie für jeden, der ein bestimmtes Erfüllungsstück erhalten soll, dieselbe Information enthalten. Das bedeutet, dass bei Erfüllungsstücken keine spezifische Anpassung möglich ist.
Peach et al. beschreiben in US-Patent Nr. 5,053,955 ein Verfahren zur Zusammenführung von Werbeinformation aus verschiedenen Verkaufsförderungsmaßnahmen auf der Grundlage mehrfacher Anforderungen. Diese Information wird zum Drucken in einem gemeinsamen Datenstrom zusammengeführt. Der Druckvorgang lässt sich so anordnen, dass die Stücke in der gewünschten Reihenfolge der Aussendung gedruckt werden.
Hidding beschreibt in US-Patent Nr. 5,519,624 ein Erfüllungssystem, in welchem das Hauptdokument gescannt wird. Auf der Grundlage der vom Scanner gelesenen Daten werden die als Anlage zum Hauptdokument bestimmten Dokumente ausgewählt. Die vom Scanner gelesenen Daten veranlassen die Datenbank, Daten für den entsprechenden Anhang an einen Drucker zu senden. Nach dem Druck der als Anhang vorgesehenen Dokumente werden sie mit dem Hauptdokument für den Postversand zusammengestellt.
Weder das System von Peach et al. noch das System von Hidding sind in der Lage, Erfüllungsstücke mit empfängerspezifischen Inhalten zu liefern. Auch werden in den Systemen von Peach et al. und Hidding die Erfüllungsstücke separat vom Hauptdokument gedruckt und können nicht in einem einzigen Dokument zusammengefasst werden. Daneben erfordert das System von Hidding die Verwendung eines Barcodes auf dem Hauptdokument und eines Scanners zum Lesen des Barcodes. Nach dem Druck der Erfüllungsstücke müssen sie manuell mit dem betreffenden Hauptdokument zusammengefügt werden. Darüber hinaus erfordern die Systeme von Peach et al. und von Hidding für alle Druckerzeugnisse die Verwendung von Papiermaterial gleicher Größe.
In einem Artikel mit der Überschrift "Innovation in Book Printing: Custom Books and Demand Printing" Seybold Report an publishing systems, 11. Mai 1992, USA, Col. 21, Nr. 16 (hiernach "Seybold-Report") wird ein rudimentäres anpassbares Drucksystem offen gelegt. In diesem rudimentären Drucksystem können Schullehrer eine Reihe von Textbuchkapiteln aus einer Vielzahl bereits bestehender Kapitel zur Einfügung in ein maßgefertigtes Buch auswählen. Die ausgewählten Kapitel werden aus einer Datenbank bereits bestehender PostScript-Dateien gesammelt und zur Erstellung des maßgefertigten Buchs gedruckt. Die in dem maßgefertigten Buch enthaltenen variablen Daten sind auf Seitenzahlen, Inhaltsverzeichnisse und Indizes beschränkt. Daneben beschreibt der Seybold-Report die so genannte "Electrobook Press", welche in der Lage ist, variable Daten für die Direct-Mail-Personalisierung in Bildern darzustellen.
Die vorliegende Erfindung beseitigt zahlreiche Einschränkungen des bisherigen Stands der Technik, da sie eine "On-Demand-Erfüllung" oder die Reihenverarbeitung von Erfüllungsstücken erlaubt, die einer hauptsächlichen Postaussendung beigelegt werden sollen. Die vorliegende Erfindung erlaubt die Reproduktion der Erfüllungsstücke nach Bedarf in der Reihenfolge der Aussendung zusammen mit der Hauptaussendung, wodurch eine manuelle Zusammenstellung vermieden wird. Die Erfüllungsstücke können als separate Blätter oder kombiniert mit der Hauptaussendung als komplettes Druckerzeugnis gedruckt werden. Auch bietet die vorliegende Erfindung insofern eine zusätzliche Flexibilität, als die Erfüllungsstücke variable Informationen enthalten und auf unterschiedlichem Papier gedruckt werden können. Außerdem verringert sich durch die vorliegende Erfindung die Verarbeitungszeit, da die überschüssige Verarbeitung statischer Information entfällt.
Zusammenfassung der Erfindung
Entsprechend einem Aspekt der vorliegenden Erfindung besteht eine Methode zur Reproduktion von Druckerzeugnissen und Erfüllungsstücken in der Reihenfolge ihrer Verteilung, bei welcher in jedem Druckerzeugnis und Erfüllungsstück variable Daten enthalten sind, aus folgenden Schritten:

(a) Veränderung einer Datenbank, welche variable Daten für die Seiten im Druckerzeugnis enthält, dahingehend, dass sie Bezüge auf die Erfüllungsstücke enthält, (b) Erstellung von Vorlagenseitendateien, wobei die Seitendateien feste Informationen sowie Platzhalter an jenen Stellen der Seite aufweisen, an denen die variablen Daten einzusetzen sind, (c) Erzeugung einer Druckbefehlsdatei zur Festlegung der Reihenfolge der Verteilung, in welcher die Seiten und die Erfüllungsstücke zu reproduzieren sind, (d) Interpretation der Seiten und der Erfüllungsstücke entsprechend der Druckbefehlsdatei, insbesondere Einfügen der aus der Datenbank gewonnenen variablen Daten in die Seiten an der Position des jeweiligen Platzhalters, sowie (e) Übertragung der Seiten und Erfüllungsstücke in der Reihenfolge ihrer Verteilung an ein Anzeigegerät.

In einem der Ausführungsbeispiele ist das Anzeigegerät ein Demand-Drucker, der die Seiten und Erfüllungsstücke druckt, oder aber ein Computer, der die Seiten und Erfüllungsstücke an ein Computer-Netzwerk überträgt. Auch können die Erfüllungsstücke zur Verteilung an eine Einzeladresse als separate Blätter gedruckt oder an die Seiten angehängt werden. Der Bezug auf das Erfüllungsstück in der Datenbank kann aus einem dem Erfüllungsstück entsprechenden Dateinamen bestehen; die Erfüllungsstücke können als QuarkXPress^® Dateien erstellt werden.
Nach einem weiteren Aspekt der vorliegenden Erfindung besteht eine Methode zur Erstellung von Druckerzeugnissen in der Reihenfolge der Verteilung, bei der jedes Druckerzeugnis aus einer Vielzahl von Seiten mit variabler und statischer Information besteht und die variable Information in einer Datenbank gespeichert wird, in der für jede Person, die ein Druckerzeugnis erhalten soll, ein Datensatz enthalten ist, aus folgenden Schritten: (a) Erstellung von Vorlagenseitendateien, welche die einzelnen Seiten darstellen, in denen die Seitendateien statische Information sowie Platzhalter an jenen Stellen der Seite aufweisen, an denen die variable Information wiedergegeben wird,

(b) Einfügung einer zusätzlichen Anzahl von Datensätzen für jede Person in die Datenbank, wobei die Anzahl der zusätzlichen Datensätze pro Person der Anzahl der Erfüllungsstücke für die betreffende Person entspricht, (c) Eintragung eines Bezugs auf ein Erfüllungsstück für jeden in die Datenbank eingetragenen zusätzlichen Datensatz, sowie (d) Auslesen der einzelnen Datensätze aus der Datenbank, insbesondere Zuordnung der variablen Information in der Datenbank zum entsprechenden Platzhalter in den Seitendateien zur Erstellung eines Druckwerks, sowie Erstellung des Erfüllungsstücks für jeden in der Datenbank vorhandenen Bezug auf ein Erfüllungsstück.

Nach einem noch anderen Aspekt der vorliegenden Erfindung besteht eine Methode zur Erstellung von Druckerzeugnissen und Erfüllungsstücken in der Reihenfolge der Verteilung, bei der jedes Druckerzeugnis aus einer Vielzahl von Seiten mit variabler und statischer Information besteht und die variable Information in einer Datenbank gespeichert ist, in der für jede Person, die ein Druckerzeugnis erhalten soll, ein Datensatz enthalten ist, aus folgenden Schritten: (a) Erstellung von Vorlagenseitendateien, welche die einzelnen Seiten darstellen, in denen die Seitendateien statische Information sowie Platzhalter an jenen Stellen der Seite aufweisen, an denen die variable Information wiedergegeben wird, (b) Einfügen einer Spalte in der Datenbank für jedes einzelne Erfüllungsstück, Einfügen eines Bezugs auf die Erfüllungsstücke der einzelnen Datensätze, (c) Erstellung einer Druckbefehlsdatei für jedes Druckerzeugnis und jedes Erfüllungsstück, Kopieren der Druckbefehlsdatei für das Druckerzeugnis und der Druckbefehlsdatei für jedes angeführte Erfüllungsstück bei jedem in der Datenbank befindlichen Datensatz, sowie Zusammenführung der kopierten Druckbefehlsdateien in eine neue Druckbefehlsdatei, sowie

(d) Interpretation der Seitendateien entsprechend der Druckbefehlsdatei, insbesondere Zuweisung der aus der Datenbank gewonnenen variablen Daten an die entsprechenden Platzhalter in den Seitendateien.

Nach einem noch weiteren Aspekt der vorliegenden Erfindung besteht eine Methode zur Erstellung von Druckerzeugnissen und Erfüllungsstücken in der Reihenfolge der Verteilung, bei der jedes Druckerzeugnis aus einer Vielzahl von Seiten mit variabler und statischer Information besteht und die variable Information in einer Datenbank gespeichert ist, aus folgenden Schritten: (a) Erstellung von Vorlagenseitendateien, welche die einzelnen Seiten darstellen, in denen die Seitendateien statische Information sowie einen Platzhalter an jenen Stellen der Seite aufweisen, an denen die variable Information anzuzeigen ist, (b) Erstellung einer Kontrolldatenbank, welche variable Daten für das Druckerzeugnis, einen Datensatz für jede Person, die das Druckerzeugnis erhalten soll, und eine eindeutige Kennzeichnung für jede Person enthält, (c) Erstellung einer Erfüllungsdatenbank für jedes Erfüllungsstück, wobei jede Erfüllungsdatenbank variable Information für das Erfüllungsstück, einen Datensatz für jede Person und eine eindeutige Kennzeichnung für jede Person enthält, (d) Untersuchung der Kontrolldatenbank auf Kennzeichnungsnummern, sowie bei jeder Kenzeichnungsnummer eine Suche nach Datensätzen mit dieser eindeutigen Kennzeichnung in sämtlichen Erfüllungsdatenbanken sowie nach den einzelnen Datensätzen mit dieser Kennzeichnungsnummer in allen Datenbanken, Kopieren der die Kennzeichnungsnummer betreffenden Druckbefehlsdatei und Zusammenführung der kopierten Druckbefehlsdateien in einer neuen Druckbefehlsdatei, sowie (e) Interpretation der Seitendateien entsprechend der neuen Druckbefehlsdatei, insbesondere Zuweisung der aus den Datenbanken gewonnenen variablen Information an die entsprechenden Platzhalter in den Seitendateien.
Nach einem noch anderen Aspekt der vorliegenden Erfindung besteht eine Methode zur Erstellung von Druckerzeugnissen und Erfüllungsstücken in der Reihenfolge der Verteilung, bei der jedes Druckerzeugnis aus einer Vielzahl von Seiten mit variabler und statischer Information besteht und die variable Information in einer Datenbank gespeichert ist, in der für jede Person ein Datensatz enthalten ist, aus folgenden Schritten: (a) Erstellung von Vorlagenseitendateien, welche die einzelnen Seiten in einem Druckerzeugnis darstellen, in denen die Seitendateien statische Information sowie einen Platzhalter an jenen Stellen der Seite aufweisen, an denen die variable Information anzuzeigen ist, (b) Einfügung einer Anzahl leerer Seitendateien in die Vorlagenseitendateien, wobei die Anzahl der leeren Seitendateien der maximalen Anzahl von Seiten in den Erfüllungsstücken entspricht, (c) Einfügung einer Bildbox in jede hinzugefügte leere Seitendatei, (d) Änderung der Datenbank durch Einfügen eines Bezugs auf die Erfüllungsstück-Seiten für jeden Datensatz, (e) Interpretation der Seitendateien, insbesondere Zuweisung der aus der Datenbank gewonnenen variablen Information an die entsprechenden Platzhalter in den Seitendateien sowie (f) Ausschießen der Seiten des Druckerzeugnisses und der Erfüllungsstück-Seiten der einzelnen in der Datenbank enthaltenen Datensätze in ein Einzel-Druckstück.
Der beanspruchten und offen gelegten Vorrichtung sind noch andere Funktionsmerkmale und Vorteile eigen und werden Personen mit Kenntnis der Technik aus der folgenden detaillierten Beschreibung in Verbindung mit den begleitenden Zeichnungen offen gelegt oder sind ihnen offensichtlich.
Kurzbeschreibung der Zeichnungen
1 ist ein Blockschema, das den bisherigen Stand der Technik in der Methode der Herstellung von Druckerzeugnissen darstellt,
2 ist ein Blockschema einer Methode der Erzeugung von Druckerzeugnissen durch Realisierung der vorliegenden Erfindung,
3 ist ein Blockschema, in dem ein Beispielsystem zur Umsetzung der in 2 dargestellten Methode der vorliegenden Erfindung dargestellt ist,
4 ist ein Blockschema, das die in 3 dargestellten Demand-Drucksysteme in größerem Detail darstellt,
5 ist ein verallgemeinertes Diagramm der Schritte, die durch die Methode der vorliegenden Erfindung umgesetzt werden,
6a und 6b sind Aufrisse von Teilen eines Musters eines mithilfe der vorliegenden Erfindung herstellbaren Druckerzeugnisses,
7a, 7b sowie 8a, 8b sind Aufrisse von Teilen anderer Muster von mithilfe der vorliegenden Erfindung herstellbarer Druckerzeugnisse,
9 ist ein Flussdiagramm, das die Programmierung darstellt, die von einem Anwender an einem Computer zur Erstellung der Vorlagendateien 105 von 5 ausgeführt werden kann,
10a-10f stellen, wenn sie entlang den mit ähnlichen Buchstaben versehenen Linien zusammengefügt werden, die vom Steuergerät 52 von 3 ausgeführte Programmierung dar,
11 ist ein Flussdiagramm, in dem die vom Steuergerät 52 umgesetzte Programmierung zur Erstellung eines Befehlssatzes in Seitenbeschreibungssprache dargestellt ist, mit welchem festgelegt wird, welche Seiten zu drucken und wie die Seiten für den Druck zu positionieren (oder auszuschießen) sind,
12 ist ein Beispielfenster, in dem der Anwender zur Eingabe der zur Erstellung einer Paginierungsdatei erforderlichen Informationen aufgefordert wird,
13 ist ein Flussdiagramm, in dem die in Block 348 von 11 umgesetzte Programmierung im Detail dargestellt ist, mit welcher festgelegt wird, welche Seiten für einen bestimmten Datensatz in der Druckbefehlsdatei gedruckt werden sollen,
14 ist ein Flussdiagramm, in dem die in Block 350 von 11 umgesetzte Programmierung im Detail dargestellt ist, mit welcher festgelegt wird, ob die Seiten des Druckerzeugnisses als linke oder rechte Seiten des Druckerzeugnisses anzulegen sind,
15 ist ein Flussdiagramm, in dem die in Block 352 von 11 umgesetzte Programmierung im Detail dargestellt ist, mit welcher die im Druckerzeugnis enthaltenen Seiten auf ein Vielfaches der Anzahl der auf einem Blatt zu druckenden Seiten aufgefüllt werden sollen,
16 ist ein Beispielfenster, in dem der Anwender zur Eingabe verschiedener Angaben bezüglich des Ausschießens und des Drucksatzes aufgefordert wird,
17 ist ein Flussdiagramm, in dem die zur Durchführung eines RIP von Seitendateien in das Format Tiff zur Verwendung im "Get Tiff"-Ausschießen entsprechend der vorliegenden Erfindung umgesetzte Programmierung beschrieben wird,
18 ist ein Flussdiagramm, in dem die zum Ausschießen von Seiten mithilfe des "Get Tiff"-Ausschießens entsprechend der vorliegenden Erfindung umgesetzte Programmierung beschrieben wird,
19 ist ein detaillierteres Blockdiagramm des (in 4 dargestellten) Drucksystems 79, in dem die dynamischen Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung enthalten sind,
20 ist ein Flussdiagramm, in dem die Standardoperation des Level 2 PostScript^®-Operators showpage dargestellt ist,
21 ist ein Flussdiagramm, in dem die vom umdefinierten PostScript^®-Operator initclip den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
22 ist ein Flussdiagramm, in dem die von den umdefinierten PostScript^® transform Operatoren den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
23 ist ein Flussdiagramm, in dem die von der Prozedur EnableVirtualDevice den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
24 ist ein Flussdiagramm, in dem die von der Prozedur DisablePageDevice den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
25 ist ein Flussdiagramm, in dem die von der Prozedur SetPortrait den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
26A ist ein Diagramm, in dem die Umwandlung einer Hochformat-Seite in eine Querformat-Seite entsprechend der Prozedur SetPortrait von 24 dargestellt ist,
26B ist ein Diagramm, in dem die Umwandlung einer Querformat-Seite in eine Hochformat-Seite entsprechend der Prozedur SetPortrait von 24 dargestellt ist,
25 ist ein Flussdiagramm, in dem die von der Prozedur setvirtualdevice den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
28 ist ein Flussdiagramm, in dem die von der Prozedur ImposeJob den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
29 ist ein Flussdiagramm, in dem die von der Prozedur ImposeFile den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
30 ist ein Flussdiagramm, in dem die von der Prozedur MakeNull den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
31 ist ein Flussdiagramm, in dem die von der umdefinierten Prozedur EndPage den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
32 ist ein Flussdiagramm, in dem die von der umdefinierten Prozedur BeginPage den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
33 ist ein Flussdiagramm, in dem die von der Prozedur Vsave den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
34 ist ein Flussdiagramm, in dem die von der Prozedur Vrestore den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
35 ist ein Flussdiagramm, in dem die von den umdefinierten PostScript^®-Operatoren save den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
36 ist ein Flussdiagramm, in dem die vom umdefinierten PostScript^®-Operator restore den dynamischen Ausschießverfahren der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
37 ist ein Flussdiagramm, in dem die von den umdefinierten PostScript^®-Operatoren grestare und grestoreall den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind,
Beschreibung der Ausführungsbeispiele
1 stellt eine Methode zur Herstellung von Druckerzeugnissen nach dem bisherigen Stand der Technik dar, wie sie beispielsweise im o. g. '818 Patent von Riley et al. gezeigt wird. In einem Veröffentlichungsschritt 20 wird der Inhalt einer oder mehrerer Versionen von Druckerzeugnissen festgelegt.
Jede Version kann beispielsweise aus einem Satz von Standardseiten oder gemeinsamen Seiten bestehen. Daneben können einige Versionen eine oder mehrere zusätzliche Seiten oder andere spezifische Informationen enthalten. Anschließend erfolgt während eines vorläufigen Schritts 22 die Farbkorrektur von Farbbildern, Unterfarbenentfernung und die Auslese von Halbtonbildern. Während eines Druckvorbereitungsschritts 24 erfolgt das Seitenausschießen und die Aufbereitung der Druckzylinder oder Druckplatten. Die Druckplatten oder -zylinder werden dann in einem Druckschritt 26 zur Aufbereitung von Druckbögen eingesetzt, die in Überboxen (nicht dargestellt) abgelegt werden. Wie im o. g. Patent '818 von Riley et al. dargelegt, werden die Druckbögen dann in einem Buchzusammenstellungsschritt 28 selektiv auf einer Sammelkette (nicht dargestellt) gesammelt und die gesammelten Druckbögen zur Herstellung des Druckerzeugnisses gebunden und beschnitten. Die Druckerzeugnisse werden anschließend in einem Schritt 30 über ein oder mehrere Verteilersysteme wie beispielsweise dem U.S. Postal Service an die Anwender verteilt.
Wie aus dem Vorgehenden ersichtlich sein sollte, erfolgt die spezifische Anpassung während des Buchzusammenstellungsschritts 28, sofern die Auswahl der in ein Druckerzeugnis aufzunehmenden speziellen Druckbögen zu jenem Zeitpunkt vorgenommen wird. Daneben können mithilfe eines neben der Sammelkette angeordneten Tintenstrahldruckers individuelle spezifische Informationen auf ausgewählte Druckbögen aufgedruckt werden. So können beispielsweise Anschriftsdaten des Empfängers mithilfe des Tintenstrahldruckers auf zusammengestellte Druckerzeugnisse aufgedruckt werden, womit die Verwendung vorgedruckter Adressetiketten überflüssig wird. Zu diesem Zeitpunkt lassen sich andere Arten der spezifischen Anpassung vornehmen, beispielsweise durch Einlegen von Karten in oder auf einen Stapel gesammelter Druckbögen, Anbringung eines spezialisierten oder individuell angepassten Deckblatts auf einen Stapel gesammelter Druckbögen u. Ä.
Die spezifische Anpassung ist an diesem Punkt des Erzeugungsvorgangs einfacher und preiswerter als beispielsweise der separate Druck der einzelnen Versionen des Druckerzeugnisses mit spezifischer Information.
2 stellt ein Blockdiagramm einer Methode 40 der vorliegenden Erfindung dar, die zur Herstellung von Druckerzeugnissen an Stelle der Methode in 1 angewendet werden kann. Methode 40 umfasst einen Schritt 42, der die Ergebnisse der Veröffentlichungsschritte und der vorläufigen Schritte 36, 38 verwendet und Druckerzeugnisse zur Verteilung entsprechend Schritt 30 der 1 herstellt. Der Schritt 42 erstellt eine oder mehrere Hauptseiten- und variable Seitendateien in beispielsweise einer Seitenbeschreibungssprache (Page Description Language, PDL) wie PostScript^® (PostScript^® ist ein Warenzeichen von Adobe Systems, Inc. für seine Seitenbeschreibungssprache), welche die herzustellenden Seiten darstellt. Daneben, wie in größerem Detail weiter unten ausgeführt, wird eine Druckbefehlsdatei (eine so genannte "Book Ticket" File) entwickelt, die die Art und Weise festlegt, in der die in der Hauptseitendatei und in den variablen Seitendateien enthaltenen Daten zur Herstellung gedruckter Seiten zusammenzuführen sind. Das Format der Druckbefehlsdatei kann beispielsweise der von Barco Graphics in Gent, Belgien, spezifizierten Form entsprechen, die speziell für die Steuerung der von Xeikon in Mortsel, Belgien, erzeugten DCP-1 digitalen Druckerpresse geeignet ist. Alternativ kann das Format der Druckbefehlsdatei die für die Steuerung eines von Xerox Corporation hergestellten DocuPrint-Druckers spezifizierte Form annehmen. Weitere Demand-Drucker sind die Modelle IBM 3900, Siemens 2090 Twin oder 2140 Twin. Hier ist zu bemerken, dass Vorrichtung und Methode der vorliegenden Erfindung nicht auf den Einsatz mit einem bestimmten Demand-Drucker oder einem speziellen System zur Steuerung dieses Druckers beschränkt sind, sondern dass sich die Erfindung vielmehr für den Einsatz mit jeder Art lokaler oder dezentraler Steuerung oder lokalem bzw. dezentralem Drucker adaptieren lässt.
Die Hauptseitendateien, die variablen Seitendateien sowie die Druckbefehlsdatei werden von einem Collator und einem Raster-Image-Prozessor (RIP) in Bitmaps umgewandelt, die in einem Speicher gespeichert werden können. Die gespeicherten Bitmaps werden zur Steuerung eines oder mehrerer Demand-Drucker oder anderer Arten von Anzeigegeräten wie Laserdrucker, CRT- oder LCD-Anzeigen oder ähnliche verwendet, sodass das Gerät Seiten mit festen und variablen Informationen anzeigt. Alternativ können die Hauptseitendatei und die variablen Seitendateien zur Erstellung einer Vielzahl kombinierter Dateien, von denen jede eine aus Hauptinformation und variabler Information bestehende zu reproduzierende Seite darstellt, im Voraus zusammengeführt werden. Die zusammengelegten Dateien können dann an jede beliebige Art von lokalem oder dezentralem Drucker oder Anzeigegerät gesandt werden. Auch können die zusammengelegten Dateien in ein geeignetes Format (z.B. Acrobat^® PDF-Format) umgewandelt und, falls gewünscht, mithilfe eines Telefaxgeräts, per E-Mail, über das Internet/World Wide Web oder ein anderes Übertragungsmittel an einen entfernt gelegenen Standort übertragen werden. Von Vorteil ist, dass sich die zusammengelegten Dateien über das Internet oder über in einem anderen Netzwerk zusammenhängende oder anderweitig wie beispielsweise im Intranet eines Unternehmens verbundene Computer übertragen lassen. In diesem Fall kann eine elektronische Datei mit spezifischen Daten auf der Grundlage von Anwenderdemografien, einer Anwendersuche bzw. anderer feststellbarer Anwenderinteressen über Internet/Intranet an einen Anwender gesandt werden. So kann beispielsweise eine spezifisch angepasste Internetseite mit Links auf andere für den Anwender interessante Websites oder eine speziell angepasste Seite als Reaktion auf eine Anwendersuche nach Information über ein bestimmtes Thema übersandt werden. Alternativ oder zusätzlich lassen sich Werbeanzeigen erstellen und als Webseite auf der Grundlage von Anwenderdemografien an einen oder mehrere Anwender versenden. Als weiteres Beispiel können Personaldaten, die einen bestimmten Mitarbeiter betreffen, als Antwort auf ein Auskunftsersuchen an den Mitarbeiter versandt werden.
Wenn die Seiten durch Wiedergabe auf dem Demand-Drucker angezeigt werden sollen, können die zusammengestellten Druckerzeugnisse gebunden und beschnitten sowie, falls gewünscht, in einem abschließenden Arbeitsschritt weiter personalisiert werden.
3 stellt ein System 50 dar, das die in Methode 40 von 2 dargestellten Schritte 36, 38 und 42 darstellt. Ein Steuergerät 52, das durch einen Personal Computer (PC) oder eine andere Art von Computer realisiert werden kann, umfasst einen Speicher 53, in welchem es Daten speichert, die für den Druck bestimmte Bilder darstellen. Wie weiter unten eingehender beschrieben, können die Daten von einem Veröffentlicher mithilfe eines PC 54 oder einer anderen Art von Computer festgelegt werden und aus einer oder mehreren Vorlagendateien bestehen, in denen die mit gedruckter Hauptinformation oder fester Information (d.h. mit gedruckter Information, die von Druckerzeugnis zu Druckerzeugnis unverändert bleibt) oder mit variabler gedruckter Information (welche sich meist von Druckerzeugnis zu Druckerzeugnis ändert) versehenen Seiten spezifiziert sind. Die variable Information kann in einer vom Veröffentlicher erstellten Datenbank gespeichert werden, während die Vorlagendatei(en) die Lage der in der Datenbank hinterlegten variablen Information auf bestimmten Seiten festlegen, wie weiter unten eingehender ausgeführt wird.
Falls gewünscht, können Bilddaten über andere Gerätearten wie Scanner, welche Eingabetexte scannen, oder aus über ein Netzwerk oder aus einer anderen Quelle gelieferten Daten bezogen werden. Das Steuergerät 52 reagiert des Weiteren auf Steuerungs- und Einrichtdateien und sorgt dafür, dass ein oder mehrere Demand-Drucksysteme 62 die gewünschten Seiten drucken. Zwar sind in 3 drei Demand-Drucksysteme 62a-62c abgebildet, es soll hier jedoch darauf hingewiesen werden, dass das Steuergerät 52 auf Wunsch auch eine beliebige andere Anzahl von Demand-Drucksystemen betreiben kann. Ebenso kann das Steuergerät 52 ein Faxgerät 64 betreiben bzw. mit anderen entfernten Geräten kommunizieren, um auf Wunsch und wie oben angeführt, ordnungsgemäß umgewandelte zusammengelegte Dateien zu übersenden.
Im Fall anderer entfernt liegender Geräte kann vom Steuergerät 52 zur Übermittlung von Daten, welche eine oder mehrere Seiten darstellen, die von einem Anzeigegerät an einem entfernten Standort über Telefonleitungen (Festnetzleitungen oder Mobiltelefon) oder einer Kombination aus Telefonleitungen und Internet angezeigt werden sollen, ein Modem 65 betrieben werden. Alternativ oder zusätzlich dazu können die Daten zumindest teilweise durch eine direkte Anbindung über ein Intranet oder ein anderes Computer-Netzwerk an einen lokalen oder entfernten Standort gesendet werden. Die zusammengelegten Dateien können gedruckt werden, sind möglicherweise in einem anderen Medium reproduzierbar und/oder können aus einem nicht-statischen Bild oder anderen Informationen wie Filmen oder Audio bestehen.
Die vom Demand-Drucksystem 62 gedruckten Seiten können an eine Endbearbeitungsvorrichtung 66 geliefert werden, welche aus verschiedenen Hilfsvorrichtungen für die Produktion und aus Geräteschnittstellen zur Zusammenstellung der Seiten für die Herstellung der fertigen, verteilungsfähigen Druckerzeugnisse besteht. Die Endbearbeitungsvorrichtung 66 kann aus einer oder mehreren Sammelvorrichtungen 70 für die Zusammenstellung von Druckerzeugnissen aus bedruckten Seiten, aus einem oder mehreren Tintenstrahldruckern 72 für den Aufdruck zusätzlicher spezifischer Information wie Adressdaten auf die einzelnen Druckerzeugnisse, aus einem oder mehreren Etikettendruckern 74 für den Druck von Adressetiketten bzw. aus anderen Steuervorrichtungen 76 bestehen. Daneben sind unter Umständen ein oder mehrere Detektoren vorgesehen, welche mangelhafte Druckerzeugnisse entdecken. Das Steuergerät 52 reagiert unter Umständen auf die Ausgabe des Detektors 78 durch erneute Bestellung eines mangelhaften Druckerzeugnisses an einem geeigneten Punkt des Herstellungsvorgangs, damit nach Möglichkeit Portovergünstigungen [bei Mengenversand] ausgenutzt werden können.
Ein oder mehrere Bestandteile der Endbearbeitungsvorrichtung 66 kann sich physisch auf dem Demand-Drucker befinden ("Online-Endbearbeitung").
Alternativ kann die Endbearbeitungsvorrichtung 66 physisch vom Demand-Drucker getrennt sein ("Offline-Endbearbeitung").
4 stellt das Demand-Drucksystem 62a von 3 in größerer Detailtiefe dar, wobei darauf hinzuweisen ist, dass die Systeme 62b und 62c in ihrer Funktion ähnlich sind. Das System 62a umfasst ein Drucksystem 79 mit einer Druckmaschinensteuerung 80, einen Collator 81 und einen Raster Image Prozessor (RIP) 82, welche als Reaktion auf vom Steuergerät 52 generierte Druckmaschinenbefehle betrieben werden können. Ein Collator ist eine elektronische Vorrichtung zur Speicherung von Raster-Image-Prozessor-Dateien (d.h. Bitmap-Dateien) und zur Lieferung ausgewählter Dateien an eine digitale Druckerpresse in Echtzeit dergestalt, dass die digitale Druckerpresse mit voller Geschwindigkeit laufen kann, während sie für jedes von der Presse produzierte Druckerzeugnis spezielle Seitendaten bearbeitet und ausdruckt. Der RIP 82 wandelt die Seitendateien in Bitmap-Format oder in jedes andere Format wie beispielsweise eine Druckersteuerungs-Symbolsprache um. Der Collator 81 beinhaltet Speicherplatz in Form von Massenspeicher-Laufwerken und physischem Speicher und ordnet die Bitmap-Seitendateien zu. Falls gewünscht, können der Collator 81 bzw. der RIP 82 Bestandteile der Druckmaschinensteuerung 80 bilden. Die Steuerung 80 weist den Collator 81 an, Seitendateien an einen Demand-Drucker 84 zu senden. Das Drucksystem 79 kann aus dem von Barco Graphics, Belgien, erzeugten und vertriebenen Printstreamer-System bestehen, während der Demand-Drucker 84 die oben erwähnte Xeikon DCP-1 digitale Farbdruckerpresse beinhalten kann. Alternativ kann der Demand-Drucker 84 ein von Xerox Corporation hergestellter DocuPrint-Drucker sein, der RIP 82 ein Xerox DocuPrint RIP. Hier ist anzumerken, dass alternativ ein anderes Drucksystem bzw. Demand-Drucker wie der von Indigo NV, Maastricht, Niederlande, hergestellte Indigo-Drucker eingesetzt werden kann, falls dies wünschenswert ist.
5 stellt die Methode der vorliegenden Erfindung in generalisierter Diagrammform dar. Für die Zwecke der Erläuterung der vorliegenden Erfindung wird beispielsweise angenommen, dass das Demand-Drucksystem 62a zur Herstellung einer Anzahl mehrseitiger Hefte mit mehreren Seiten in Form einer Broschüre im Duplexformat (oder "Heftstichformat") betrieben wird. 6a und 6b stellen 4 Seiten P1-P4 dar, die auf einem einzigen Bogen Papier 100 gedruckt wurden und in eine Broschüre aufgenommen werden sollen. Der Papierbogen 100 umfasst eine erste Bogenseite 100a mit den darauf befindlichen gedruckten Seiten P1, P4 sowie eine zweite Bogenseite 100b mit den darauf befindlichen gedruckten Seiten P2, P3. (Wie weiter unten in diesem Dokument deutlich wird, soll die Verwendung der Bezeichnungen P1-P4 nicht bedeuten, dass diese Seiten unbedingt die Seiten 1, 2, 3 und 4 des fertigen Heftes werden.) Daneben werden die Seiten P1-P4 dergestalt ausgeschossen, dass die Seite P1 in einem rechten Teil 100a-r der Bogenseite 100a, die Seite P4 hingegen in einem linken Teil 100a-1 der Bogenseite 100a angeordnet wird. Darüber hinaus wird die Seite P2 in einem linken Teil 100b-1 der Bogenseite 100b angeordnet, während die Seite P3 in einem rechten Teil 100b-r der Bogenseite 100b abgelegt wird. Auf diese Weise erscheinen die Seiten P1-P4 in der richtigen Reihenfolge, wenn der Papierbogen 100 entlang einer Falzlinie 102 mit den Seiten P1 und P4 nach außen gefalzt wird. (Das in 6A und 6B abgebildete Format wird meist als "Heftstich-Format" bezeichnet und wird häufig beim Ausschießen für Zeitschriften verwendet.) Da jedes in diesem Beispiel erzeugte Buch/Heft mehrere Papierbögen umfasst, von denen jeder entlang einer Falzlinie gefalzt ist, berücksichtigt der Vorgang des Ausschießens Aufschuppungseffekte, jedoch keine Flascheneffekte. Es ist darauf hinzuweisen, dass generell diese beiden Effekte berücksichtigt werden müssen, wenn mehr als 2 Seiten auf derselben Papierbogenseite gedruckt, anschließend mehrfach gefalzt und mit anderen mehrfach gefalzten bedruckten Papierbögen zur Herstellung eines Druckerzeugnisses zusammengestellt werden.
Neben Obigem wird im ersten Beispiel angenommen, dass die Seiten P1 und P4 als Deckblatt bzw. Rückblatt eines fertig gestellten Druckerzeugnisses eingesetzt werden und dass sie feststehende und variable Information enthalten. Des Weiteren wird vorausgesetzt, dass P2 und P3 die Innenseiten des Deckblatts bzw. des Rückblatts bilden (wie dies der Fall sein muss, wenn P1 und P4 die Außenseiten des Deckblatts bzw. Rückblatts sind) und nur feststehende Information enthalten. So kann beispielsweise die Seite P1 in einem Bereich 110 variable Information in Form einer personalisierten Nachricht, ein variables Bild oder Ähnliches enthalten, die Seite P4 hingegen andere variable Information in einem Bereich 112, z.B. postalische Angaben für den Versand der Broschüre an einen Empfänger.
Die entsprechenden Deckblätter und Rückblätter der verbleibenden Druckerzeugnisse können abweichende variable Informationen enthalten. Die verbleibende gedruckte Information auf den Seiten P1-P4 kann mit der gedruckten Information der entsprechenden Seiten anderer Druckerzeugnisse identisch sein.
Die herzustellenden Druckerzeugnisse können aus derselben oder einer unterschiedlichen Anzahl von Bögen bestehen und gleich oder unterschiedlich viele Seiten aufweisen. So können beispielsweise die Seiten P1-P4 mit einer Anzahl anderer, aus zwölf zusätzlichen Seiten bedruckten Bögen zusammengestellt werden, woraus ein erstes, aus sechzehn Seiten bestehendes Druckerzeugnis hergestellt wird. Ein anderes, im gleichen Durchlauf herzustellendes Druckerzeugnis kann aus einigen oder allen Seiten P1-P4 und einer zweiten Anzahl von Bögen bestehen, welche mit zwanzig anderen Seiten bedruckt sind, von denen einige mit den zwölf zusätzlichen Seiten des ersten Druckerzeugnisses identisch sein können, jedoch nicht sein müssen. Um zu erreichen, dass dieses Druckerzeugnis bzw. diese Druckerzeugnisse eine bestimmte Anzahl von Seiten aufweisen, können in einige oder alle Druckerzeugnisse Füllseiten eingefügt werden. Dies mag erforderlich oder wünschenswert sein, um eine Länge des Druckerzeugnisses zu erreichen, die (in jenen Fällen, in denen Seiten im doppelseitigen Format ausgeschossen werden) ohne Rest durch vier teilbar ist, bzw. um zu gewährleisten dass eine oder mehrere bestimmte Seiten im fertig gestellten Druckerzeugnis auf der linken bzw. auf der rechten Seite erscheinen.
Tatsächlich können sich die im selben Drucklauf herzustellenden Druckerzeugnisse im Seiteninhalt bzw. im Aussehen der Seiten, in der Länge, der Größe (durch Veränderung der Parameter für das Ausschießen der Seiten), in der Version usw. des Druckerzeugnisses unterscheiden. Insbesondere können beispielsweise die Seiten der 7a, 7b und 8a, 8b in verschiedenen Druckerzeugnisversionen zusammen mit der Druckversion, welche die Seiten von 6a und 6b enthält, im selben Produktionslauf oder Produktionsauftrag hergestellt und zusammengestellt werden. Die Seiten P5-P8 in 7a und 7b sind identisch mit den Seiten P1-P4 in 6a und 6b mit der Ausnahme, dass auf Seite P5 neben den Bereichen 110 und 112 ein zusätzlicher Bereich 113 zur Platzierung variabler Information vorgesehen ist. Wegen der Einfügung des Bereichs 113 unterscheidet sich die in einem Bereich 114 angezeigte verbleibende Hauptinformation von der in einem Bereich 116 der Seite P1 in 6a angezeigten Hauptinformation.
Die Druckerzeugnisversion von 8a und 8b, welche acht Seiten P9-P16 enthält, unterscheidet sich von den Druckerzeugnisversionen, die die Seiten von 6a, 6b sowie 7a, 7b enthalten, nicht nur bezüglich des Inhalts der Hauptinformation und der variablen Information sondern auch bezüglich der Seitenanzahl und -größe.
Insbesondere sind die Seiten P9, P12, P13 und P16 auf der ersten Blattseite 117a eines Papierblatts 118 zu drucken, die verbleibenden Seiten P10, P11, P14 und P15 auf der zweiten Blattseite 117b des Blatts 118. Darüber hinaus werden die Seiten P11-P14 im Verhältnis zu den übrigen Seiten auf den Kopf gestellt gedruckt, sodass nach dem Falzen des Blatts 118 zunächst entlang einer Falzlinie 119a und anschließend entlang einer Falzlinie 119b die entstehenden Seiten P9-P16 in der richtigen Reihenfolge erscheinen.
Anschließend wird das gefalzte Blatt 118 zur Trennung der Seiten P9-P16 beschnitten. Wie offensichtlich sein sollte, sind die Seiten P9-P16 nur halb so groß wie die Seiten P1-P8 und enthalten darüber hinaus unterschiedliche Hauptinformation und variable Information. Der Demand-Drucker kann auch mit mehreren Papierschächten zur Auswahl unterschiedliche Papiergrößen, Papierarten und -farben usw. sowie vorgedruckter Blätter zur Aufnahme in das fertige Druckerzeugnis ausgestattet sein.
Unter Bezug auf 5 werden von einem Veröffentlicher eine oder mehrere Vorlagendateien 106 entwickelt, in denen der Inhalt (einschließlich des Erscheinungsbildes) der feststehenden Information sowie die Positionierung sämtlicher (feststehender und variabler) Information in den verschiedenen Druckerzeugnissen oder Versionen der Druckerzeugnisse festgelegt sind. Auch wird vom Veröffentlicher mit Hilfe eines PC 54 eine Datenbank 108 entwickelt, in welcher der Inhalt der variablen Information festgelegt ist, die in die für die variable Information bestimmten Bereiche einzusetzen ist, beispielsweise in die Bereiche 110, 112 auf den Seiten P1 bzw. P4 von 6a und 6b. Die Datenbank 108 enthält darüber hinaus Steuerungsinformation, wie weiter unten in größerem Detail ausgeführt ist.
Die Vorlagendateien 106 enthalten Daten, welche die Position und den Inhalt der feststehenden Information auf den zu druckenden Seiten bestimmen. Insbesondere sind in den Vorlagendateien 106 die Vorlagenseiten definiert, in welchen die einzelnen Vorlagenseiten Daten enthalten, welche eine feststehende Information darstellen, die auf den entsprechenden Seiten der Druckerzeugnisse oder der Versionen der Druckerzeugnisse angezeigt werden sollen, sowie Bereichsdaten, welche den Bereich/die Bereiche auf den entsprechenden Seiten darstellen, in denen die variable Information anzuzeigen ist. Zur Erzeugung von Arbeitsdateien werden die Vorlagendateien dupliziert. Aus einem Satz Arbeitsdateien werden sämtliche Bereichsdaten entfernt, die sich auf die Positionierung von variabler Information beziehen, um entleerte Hauptseitendateien 120 zu erstellen, welche Vorlagenseiten definieren, die nur feststehende Information enthalten. Die entleerten Hauptseitendateien werden dann zu PDL-Hauptseitendateien 122 umgewandelt, die in einer Seitenbeschreibungssprache wie PostScript^® ausgedrückt sind.
Optional können die PDL-Hauptseitendateien 122 von einem Layoutprogramm wie QuarkXPress^® in ein doppelseitiges Layout umgewandelt werden. Vorzugsweise sollten jedoch die PDL-Hauptseitendateien 122 dem Drucksystem 79 den Ausschießungsverfahren der vorliegenden Erfindung entsprechend geliefert werden, wie weiter unten im Detail ausgeführt.
Aus einem weiteren Satz von Arbeitsdateien wird die gesamte feststehende Information gelöscht, um entleerte variable Seitendateien 126 zu schaffen, welche Vorlagenseiten definieren, aus denen die feststehende Information gelöscht wurde, und welche darüber hinaus über die Bereichsdaten verfingen, mit denen die Bereiche 110, 112 definiert werden. Die Daten, welche Vorlagenseiten mit variabler Information darstellen, werden in einem Satz zwischengeschalteter Seitendateien erweitert. Im Beispiel der 6a und 6b und unter der Annahme, dass drei Druckerzeugnisse zu drucken sind, werden auf diese Weise zwei zwischengeschaltete Seitendateien 130, 132 erzeugt. In der Datei 130 ist ein Dateiteil P1-a enthalten, der die Position der variablen Information definiert, die auf der Seite P1 des ersten Druckerzeugnisses darzustellen ist. Zwei andere Dateiteile P1-b und P1-c definieren die Position der variablen Information, welche auf den äußeren vorderen Deckblättern der verbleibenden zwei Druckerzeugnisse herzustellen ist. Auf die gleiche Art stellen Dateiteile P4-a, P4-b und P4-c die Position der variablen Information dar, welche auf den äußeren hinteren Deckblättern der drei Druckerzeugnisse darzustellen ist. Zu diesem Zeitpunkt sind auch Daten in jeder der Dateien 130, 132 enthalten, welche die Einträge in der Datenbank 108 definieren, die während des Druckvorgangs in die Bereiche 110, 112 einzufügen sind.
Die Dateien 130, 132 werden anschließend in variable Seitendateien 134, 136 umgewandelt. Die Dateien 134, 136 sind identisch mit den Dateien 130 bzw. 132, außer dass die in den einzelnen Dateien befindlichen Daten, welche Einträge in die Datenbank definieren, durch die in diesen Einträgen gespeicherten tatsächlichen Daten ersetzt werden.
Die Dateien 134, 136 werden dann in Dateien 137, 138 in einem PDL-Format wie beispielsweise PostScript^® umgewandelt.
Wie die PDL-Hauptdateien 122 können die variablen PDL-Dateien 137, 138 von einem Layoutprogramm wie QuarkXPress^® in ein doppelseitiges Layout umgewandelt werden. Vorzugsweise sollten jedoch die variablen PDL-Dateien 137, 138 dem Drucksystem 79 den Ausschießungsverfahren der vorliegenden Erfindung entsprechend geliefert werden, wie weiter unten im Detail ausgeführt.
Das Drucksystem 79 funktioniert als Reaktion auf Druckmaschinenbefehle in einer Druckbefehlsdatei 140 und führt die PDL-Hauptseitendateien 122 mit den variablen PDL-Dateien 137, 138 zur Erstellung fertig gestellter Druckerzeugnisse oder Versionen von Druckerzeugnissen zusammen. Alternativ können die Hauptseitendateien 122 mit den variablen PDL-Dateien 137, 138 im Voraus zusammengeführt werden, bevor diese Dateien an das Drucksystem 79 geliefert werden.
9 stellt das Flussdiagramm einer Programmierung dar, welche auf dem PC 54 zur Erstellung der Vorlagendatei(en) 106 von 5 ausgeführt wurden. Die Programmierung kann als Erweiterung von QuarkXPress^®, einem von Quark, Inc., Denver, Colorado, USA vertriebenen Layoutprogramm geschrieben werden. Das Programm QuarkXPress^® kann für den Betrieb im Betriebssystem Apple^® Macintosh^® oder in jedem anderen Betriebssystem wie Microsoft Windows^® adaptiert werden. Alternativ kann auf Wunsch ein anderes Programm zur Erstellung von Seitenlayouts verwendet werden.
Während des Aufmachungsvorgangs für ein Dokument, welches aus einer oder mehreren Seiten besteht, wird für jede herzustellende Druckerzeugnisversion eine Vorlagendatei erstellt oder es kann, wenn ein Druckerzeugnis aus zwei oder mehreren Teilen (hiernach in diesem Dokument "Abschnitten") bestehen soll, für jeden Abschnitt eine Vorlagendatei erstellt werden.
An einem Block 150 kann ein Anwender einen Seitenbereich für die Reproduktion variabler Information auswählen, an welchem Punkt ein Linienobjekt, ein Textobjekt oder ein Bildobjekt selektiert werden kann. Dies wird dann von einem Block 152 überprüft, um festzustellen, welcher Objekttyp selektiert wurde. Falls ein Textobjekt selektiert wurde, durch welches angezeigt wird, dass an einem durch die aktuelle Cursorposition am Computer-Display definierten Punkt ein variabler Text einzufügen ist, wird an dem durch die aktuellen Cursorposition definierten Einfügepunkt der Vorlagendatei von einem Block 154 der Name des betreffenden Feldes in der Datenbank 108 oder ein Hinweis auf dasselbe eingefügt. Falls der Anwender für variable Information (Block 156) weitere Bereiche zuweisen will, kehrt die Steuerung zu Block 150 zurück und wartet dort auf die Auswahl des Anwenders. Wählt der Anwender dann ein Bildobjekt aus, wird vom Anwender eine Box definiert, in welcher das Bild an der gewünschten Stelle einer ausgewählten Seite angezeigt werden soll. Hiernach geht die Kontrolle von Block 152 an einen Block 158 über, der eine Bild-Blinddatei und eine Anzeige des ordnungsgemäßen Datenbank-Feldnamens der Seite an der von der aktuellen Cursorposition angezeigten Stelle in die Vorlagendatei einfügt. Hiernach sieht der Anwender, wenn die Seite angezeigt wird, die Bild-Blinddatei am Einfügepunkt auf dem Display des Computers 54. Die Bild-Blinddatei zeigt einen Hinweis auf jenes Feld der Datenbank an, das zur Einfügung der betreffenden Seiten benützt wird.
Im Anschluss an den Block 158 wird der Anwender von einem Block 160 zur Eingabe eines Hinweises darauf aufgefordert, ob das Bildobjekt in einem von mehreren Anzeigenformaten angezeigt werden soll. Falls das Bild in einer anderen Größe als in Originalgröße angezeigt werden soll, setzt ein Block 162 einen untergeordneten Namen zur "Passung" des Bildes fest und zeigt damit an, dass das Bild auf die Größe der Box skaliert werden soll. Soll das Bild in seiner Originalgröße angezeigt werden, wird der Anwender von einem Block 153 aufgefordert, eine Position für das Bild an einer bestimmten Position in der hierfür definierten Box auszuwählen, wie zum Beispiel in der linken oberen Ecke, der rechten unteren Ecke usw.
Falls der Anwender keine Position auswählt, wird das Bild in der linken oberen Ecke der Bildbox angeordnet. Hiernach geht die Kontrolle auf Block 156 über.
Wenn Block 152 feststellt, dass ein Linienobjekt selektiert wurde, kehrt die Kontrolle direkt zum Block 150 zurück, da variable Information nicht in ein Linienobjekt eingegeben werden kann. Die daraus resultierende(n) Seitenvorlagendatei(en) wird/werden auf einem Speichermedium wie beispielsweise einer Optical Disk oder auf einem anderen Speichergerät gespeichert und/oder die Dateien werden zusammen mit der Datenbank auf das Steuergerät 52 heruntergeladen.
An jedem beliebigen Punkt des Seitenerstellungsvorgangs können zur Herstellung der fertigen Seiten sowohl für die Hauptteile als auch für die variablen Teile andere Funktionsaspekte des Programms QuarkXPress^® nach Bedarf aufgerufen werden.
Die Datenbank 108 wird durch die Erstellung einer ASCII-Datei mit einer Vielzahl von Datensätzen erstellt, wobei in jedem Datensatz ein oder mehrere Felder enthalten sind, welche in die Datenbank im Tabulator-begrenzten Format (d.h., in jedem Datensatz werden die Felder voneinander durch Drücken der Tabulatortaste, die Datensätze voneinander durch Zeilenvorschub getrennt) eingegeben und in welcher die Felder unter den Feldnamen einer Kopfzeile angeordnet werden. Jedes Feld kann Text enthalten, der auf einer Seite wiederzugeben ist, oder den Namen einer in Speicher 53 gespeicherten und auf einer Seite wiederzugebenden und ein Bild definierenden Bilddatei.
Neben den vorher genannten Daten kann die Datenbank 108 ein optionales Feld enthalten, welches die Anzahl der Exemplare der einzelnen herzustellenden Druckwerke enthält, sowie ein optionales Bilderfeld Sortierung nach Ort, ein Versionskennzeichnungsfeld, in dem im Falle der Erzeugung mehrerer Druckerzeugnisversionen die Versionsnummer des Druckerzeugnisses angezeigt wird, ein optionales Verteilungslistenfeld, Kontrolldaten und Ähnliches.
Unten ist eine Beispieldatenbank mit einer aus zwölf Feldern ("version", "addressline1", "addressline2" usw) bestehenden Kopfzeile und einer Anzahl von Datensätzen ausgeführt, von denen neun, davon jedes mit 12 Feldern, angezeigt werden:
Im Beispiel von 6a und 6b können die Feldnamen ADDRESSLINE1 bis einschließlich ADDRESSLINE5, BARCODE und TOWNSORT im Bereich 112 und ein oder mehrere Feldnamen PRICE1, IMAGE1 und PRICE2 im Bereich 110 angezeigt werden. Das Feld COPIES kann als Steuercode zur Auswahl der Anzahl der herzustellenden Exemplare des Druckerzeugnisses verwendet werden.
Wenn die Vorlagendatei(en) 106 und die Datenbank 108 zusammengestellt sind, kann vom Steuergerät 52 die Programmierung von 10a-10f zur Erstellung der Hauptseitendatei 122, der endgültigen variablen Seitendateien 137 und 138 und der Druckbefehlsdatei 140 ausgeführt werden. Wenn wir zunächst 10a betrachten, fordert ein Block 170 einen Anwender zur Auswahl einer Vorlagendatei 106 auf, während ein Block 172 die Datenbank 108 öffnet. Ein Block 174 liest dann eine Liste der Feldnamen in der Datenbank und speichert sie zur späteren Verwendung, während ein Block 176 einen Anwender zur Eingabe von Information aufruft, welche eine Abschnittsnummer angibt, sowie zur Angabe, ob die Seiten im Simplex-Format (das heißt einseitig) oder in Duplex-Format (das heißt doppelseitig) gedruckt werden sollen. Die Abschnittsnummer kennzeichnet die Reihenfolge, in welcher mehrere Abschnitte für ein bestimmtes Druckerzeugnis abgearbeitet werden sollen. Möglicherweise wird der Anwender auch zur Eingabe eines selektiven Verarbeitungscodes aufgefordert, mit dem eine bestimmte Druckerzeugnisversion für die Verarbeitung gekennzeichnet wird, falls innerhalb desselben Druckdurchlaufs mehrere Versionen hergestellt werden sollen.
Im Anschluss an Block 176 beginnt ein Block 177 den Prozess der Entfernung variabler Information aus den von Block 170 geöffneten Vorlagendateien, um die entleerte Hauptdatei 120 aus 5 zu erhalten. Der Block 77 wählt eine erste Seite für die Verarbeitung aus, während ein Block 176 überprüft, ob in der Vorlagendatei Bilder vorhanden sind; falls Bilder gefunden werden, wählt ein Block 180 ein erstes Bild aus.
Ein Block 182 ermittelt den Dateinamen für das Bild, während ein Block 184 die Liste der Felder überprüft, um festzustellen, ob in ihnen der Dateiname enthalten ist.
Falls der Dateiname des Bildes in der Liste der Felder enthalten ist, dann besteht das Bild aus variabler Information und ein Block 186 löscht den Bildblock. Anschließend identifiziert und speichert ein Block 187 die Lage der Bildbox auf der Seite, die Eigenschaften der Bildbox wie Größe, Versatz, Hintergrundfarbe, Unterbezeichnung und Ähnliches und speichert auch den Feldnamen des Bildes aus der Datenbank 108. Auch wird ein Zähler im Speicher 53, der die Anzahl der auf der Seite befindlichen variablen Bildboxen verfolgt, um 1 erhöht.
Wenn der Block 184 andernfalls feststellt, dass der Dateiname nicht in der Feldliste aufzufinden ist, dann enthält das Bild nur Hauptinformation. Ein Block 188 speichert dann auch die Position der Bildbox auf der Seite sowie die Eigenschaften der Bildbox. Ebenso wird ein Zähler im Speicher 53, der die Anzahl der auf der Seite befindlichen Hauptbildboxen verfolgt, um 1 erhöht.
Ein Block 189 prüft dann, ob alle Bilder verarbeitet wurden. Falls nicht, wählt ein Block 190 ein nächstes Bild aus, die Kontrolle geht an Blocks 182-189 zurück. Die Kontrolle verbleibt bei diesen Blocks, bis Block 189 feststellt, dass alle Bilder verarbeitet wurden; die Kontrolle ergeht dann an einen Block 192. Die Kontrolle geht auch an Block 192 von Block 178, wenn letzterer feststellt, dass in der Vorlagendatei keine Bilder vorhanden sind. Der Block 192 stellt fest, ob in der offenen Vorlagendatei Textboxen vorhanden sind. Falls mindestens eine (1) Textbox vorhanden ist, wählt und parst ein Block 194 eine erste Textbox, während ein Block 196 (10b) überprüft, ob in der Textbox mindestens einer der Feldnamen der Datenbank 108 enthalten ist. Ist dies der Fall, dann wurde festgestellt, dass die Textbox variable Information enthält; sie wird daraufhin von einem Block 198 gelöscht.
Ein Block 199 speichert dann die Lage der Textbox, die Einfügepunkte in der Textbox, an welchen variable Information zu drucken ist, sowie die Eigenschaften der Textbox und die in dieser Textbox in Speicher 53 festgelegten Feldnamen der Datenbank 108. Darüber hinaus wird ein Zähler der variablen Textboxen um 1 erhöht und zeigt damit die Anzahl der auf den einzelnen Seiten erscheinenden variablen Textboxen an.
Falls Block 196 andererseits feststellt, dass in der Textbox keine Feldnamen aus der Datenbank enthalten sind, dann enthält die Textbox nur Hauptinformationen. Ein Block 200 speichert die Position der Textbox im Speicher 53. Darüber hinaus wird ein Zähler der Haupttextboxen um 1 erhöht und zeigt damit die Anzahl der auf den einzelnen Seiten erscheinenden Haupttextboxen an.
Die Kontrolle geht dann auf einen Block 202 über, welcher prüft, ob alle Textboxen in den Vorlagendateien verarbeitet wurden. Falls nicht, wählt und parst ein Block 204 die nächste Textbox in der Vorlagendatei; die Kontrolle kehrt zu den Blocks 196-202 zurück. Die Kontrolle verbleibt bei diesen Blocks, bis alle Textboxen verarbeitet wurden, worauf ein Block 206 feststellt, ob alle Seiten verarbeitet wurden. Falls nicht, wählt ein Block 208 eine nächste Seite aus; die Kontrolle geht an Block 178 (10a) zurück. Andernfalls speichert ein Block 210 die resultierende Datei als entleerte Hauptdatei.
Alternativ, falls eine Seite eine große Menge an Formatierungsdaten (wie Tabulatoren, Schriftarten usw.) enthält, kann offline aus der Datenbank eine so genannte Rich-Text-Datei (rtf-Datei) erstellt werden (in welcher diese Formatierungsdaten enthalten sind). Die Textbox kann dann die Rich-Text-Datei öffnen und die Information in der Datei lesen. Die Verwendung von Rich-Text-Dateien verkürzt die Verarbeitungszeit.
Wenn nun ein Platzhalter auf einer Seite mit Informationen aus dem Feld der Datenbank "ausgefüllt" wurde, kann das Programm die entsprechende Textbox oder Bildbox als "abgetastet" kennzeichnen. Wenn daher eine Textbox oder Bildbox "unabgetastet" ist, kann das Programm die Bearbeitung der betreffenden Textbox oder Bildbox überspringen, wodurch ebenfalls die Verarbeitungszeit verkürzt wird.
Auch überspringt die Kontrolle die Blocks 194-202 und setzt direkt bei Block 192 bis Block 206 fort, wenn Block 192 feststellt, dass in der offenen Vorlagendatei keine Textboxen vorhanden sind.
Im Anschluss an Block 210 wandelt ein Block 212 die entleerte Hauptdatei in die PDL-Hauptseitendatei 122 von 5 um. Gleichzeitig kann eine Initialisierungsdatei (INI-Datei) erstellt werden. Format und Vorhandensein der INI-Datei hängt von der Art des verwendeten Demand-Druckers ab. So benötigt beispielsweise der DocuPrint Demand-Drucker die Verwendung einer INI-Datei nicht. Der Barco RIP hingegen benötigt eine INI-Datei.
Die INI-Datei (in ASCII-Code)für den Barco RIP wird entsprechend folgendem Format erstellt:
name: [Datenpfad\Name]
psx: [Abmessung]
psy: [Abmessung]
ssx: [Abmessung] ssy: [Abmessung]
posx: [Abmessung]
posy: [Abmessung]
Duplex: [null oder eins]
orientation: [null oder eins] output: [Dateiname]
copies: [Anzahl]
Während mit "psx" und "psy" die Größe der fertigen Seiten in Richtung x und y bezeichnet wird, beziehen sich "ssx" und "ssy" auf die Größe des geschnittenen Bogens in Richtung x und y, "posx" und "posy" bezeichnen den Offset in Richtung x und y und setzen damit die Position der einzelnen Seiten auf dem geschnittenen Bogen fest, während mit "duplex" einseitiger oder doppelseitiger Druck bezeichnet wird, "orientation" bezieht sich auf den Druck im Hoch- oder Querformat, "output" verweist auf den Namen der Ausgabedatei und "copies" zeigt die Anzahl der auszudruckenden Exemplare an. Eine INI-Musterdatei, welche die Parameter für den Druck einer Datei namens MYJOB.PS festlegt, sieht folgendermaßen aus:
Name: C:\jobs\myjob.ps
psx: 8000
psy: 11000
ssx: 11500
ssy: 9000
posx: 150
posy: 150
duplex: 1
orientation: 1
output: myjob.ps
copies: 1
Im vorhergehenden Beispiel soll ein Exemplar der Datei MYJOB.PS im Duplex- und im Hochformat mit einem Offset von 0,15 × 0,15 Zoll von einer Ecke eines fertigen Papierbogens von 8 × 11 Zoll geschnitten werden, der aus einem Bogen mit der ursprünglichen Abmessung 9 × 11,5 Zoll ausgeschnitten wurde.
Für den DocuPrint (oder jeden anderen Demand-Drucker, der keine INI-Datei benötigt) wird eine Warteschlange erstellt, welche dieselben Parameter wie die INI-Datei (und potenzielle zusätzliche Parameter, durch welche die Funktionalität eines In-live-Endbearbeitungsgeräts oder einer anderen Vorrichtung aufgerufen wird) enthält.
Anschließend an Block 212 öffnet ein Block 214 erneut die gleiche Vorlagendatei, welche ursprünglich von Block 117 geöffnet wurde, und löscht alle Haupt-Bildboxen und Haupt-Textboxen. Ein Block 216 speichert dann die resultierende Datei als entleerte variable Datei 126 von 5.
Anschließend erstellt ein Block 218 eine temporäre Datei, die eine Tabelle der aktuellen Seitennummern und eine Nummer enthält, welche den Namen des von Block 154 am Einfügungspunkt eingefügten Datenbankfelds darstellt. Die Datei wird beispielsweise *.VARS genannt (wobei * einen vom Anwender gewählten Dateinamen darstellt).
Die Datei *.VARS enthält daher Seitenzahlenpaare und Paare von Datenbankspaltennummern, durch die angezeigt wird, woher in der Datenbank die variable Information für die betreffende Seite kommt. So kann die Datei *.VARS beispielsweise folgende Angaben enthalten:

1 7

8 43

9 44

10 45

11 46

11 47

13 50

14 52

15 50

15 51
In obigem Beispiel enthält Seite 1 variable Daten aus Spalte 7 der Datenbank, Seite 8 enthält variable Daten aus Spalte 43, und Seite 11 enthält variable Daten aus den Spalten 46 und 47. Darüber hinaus kann die Datei *.VARS separate Paarungen für Bilder und Text enthalten.
Die Kontrolle geht dann auf Block 242 (10c) über, welcher eine Arbeitskopie der entleerten variablen Datei 126 erstellt. Eine erste Seite, welche variable Daten enthält, wird ausgewählt, wobei die Daten, welche die verbleibenden Seiten in der Datei darstellen, von einem Block 244 gelöscht werden. Im Beispiel von 6a und 6b erstellt der Block 244 eine Datei, welche das vordere Deckblatt eines Druckerzeugnisses, von dem alle feste Information gelöscht wurde, sowie einen für die variable Information reservierten Bereich festlegt. Im Anschluss an Block 244 wählt ein Block 245 einen ersten Datensatz in der Datenbank 108 aus, worauf ein Block 248 den Datensatz liest. Ein optionaler Block 250 prüft, ob vom Anwender ein selektiver Verarbeitungscode eingegeben wurde, durch den angezeigt wird, dass die Seite selektiver Seitenverarbeitung unterzogen werden soll. Wie oben angemerkt, können die Vorrichtung und die Methode der vorliegenden Erfindung zur Herstellung nicht nur von Druckerzeugnissen einer einheitlichen Version (d.h., bei welcher sich die entsprechenden Seiten nur an Hand der in der Datenbank gespeicherten variablen Information unterscheiden) sondern auch zur Herstellung von Druckerzeugnissen verschiedener Versionen verwendet werden. In letzterem Fall weisen die Druckerzeugnisse der verschiedenen Versionen unterschiedliche feste und variable Informationen auf. So kann sich in den verschiedenen Versionen die feste und/oder variable Information oder beide nach Inhalt oder Aussehen (Stil, Lage, Rotation, Position usw.) unterscheiden.
Wenn der Block 250 feststellt, dass eine selektive Seitenverarbeitung durchzuführen ist, dann prüft ein Block 252, ob der in der Datenbank von Block 248 gelesene Datensatz auf der aktuell in Erwägung gezogenen Seite zu verwenden ist. Der Block 252 erreicht dies durch Überprüfung des Versionsidentifikationsfelds in der Datenbank zur Feststellung, ob diese Version aktuell verwendet wird. Ist dies nicht der Fall, dann prüft ein Block 253, ob es sich bei dem aktuell in Erwägung gezogenen Datensatz um den letzten in der Datenbank handelt. Falls ja, geht die Kontrolle auf Block 294 von 10e über. Andernfalls wählt ein Block 254 einen nächsten Datensatz in der Datenbank 108; die Kontrolle kehrt zu Block 248 zurück, wo der nächste Datensatz der Datenbank gelesen wird.
Wenn der Block 250 feststellt, dass keine selektive Seitenverarbeitung durchzuführen ist, oder wenn der Block 252 feststellt, dass der von Block 243 gelesene Datensatz in der gegenwärtig in Erwägung gezogenen Seite zu verwenden ist, dupliziert ein Block 256 die Daten, welche nach der Ausführung durch den Block 244 zur Einleitung der Entwicklung einer der Dateien 130 oder 132 die verbleibende Seite darstellen. Im ersten Durchlauf des Programms von 10c und in Verbindung mit dem Muster von 6a und 6b erstellt der Block 256 die Datei 130, entwickelt Seitendaten, welche eine erste Version der Seite P1-a darstellen, und fügt während der unmittelbar darauf folgenden Durchläufe durch das Programm weitere variable Informationen in diese Seitendaten ein.
Anschließend werden Daten erstellt, welche die verbleibenden Seiten P1-b, P1-c und P4-a bis einschließlich P4-c darstellen; in den nachfolgenden Durchläufen wird variable Information seriell in diese Seiten eingefügt.
Ein Block 258 prüft, ob sich auf der Seite Bildboxen befinden; ist dies der Fall, dann wählt ein Block 260 die erste Bildbox. Ein Block 262 fügt dann das vom Datenbankfeld identifizierte Bild in die Bildbox ein. Ein Block 264, 10d, prüft die Unterbezeichnung, um festzustellen, ob Block 152 von 9 angezeigt hat, dass die Größe des Bildes verändert werden muss, damit es in die Bildbox passt. Falls dies zutrifft, wird die Größenveränderung von einem Block 266 durchgeführt. Andernfalls positioniert ein Block 268 das Bild in die Bildbox an der vom Anwender festgelegten Position, und ein Block 270 prüft, ob alle Bildboxen verarbeitet wurden. Auch geht die Kontrolle von Block 266 direkt zum Block 270 über und überspringt dabei Block 268. Falls nicht alle Bildboxen verarbeitet wurden, wählt ein Block 272 eine nächste Bildbox auf der Seite aus; die Kontrolle kehrt zu den Blocks 262-270 zurück, so dass die verbleibenden Bildboxen hintereinander verarbeitet werden.
Wenn Block 270 feststellt, dass alle Bildboxen verarbeitet wurden oder, falls auf der Seite keine Bildboxen gefunden werden, unmittelbar im Anschluss an den Block 258 von 10c, prüft ein Block 274, ob sich auf der Seite Textboxen befinden; falls ja, wählt ein Blockpaar 276, 278 eine erste Textbox und einen ersten Einfügepunkt in dieser Box aus. Die Blocks 280, 282 und 284 fügen dann die in der Datenbank 108 gespeicherten Textdaten an den entsprechenden Einfügepunkten seriell in die Textbox ein. Sobald alle variablen Textdaten in die Textbox eingefügt wurden, setzt ein Block 286 sämtlichen Text in der Textbox neu zusammen, so dass der Text ein sauberes und endgültiges Erscheinungsbild erhält.
Dieser Vorgang des erneuten Umbruchs wird vom Programm QuarkXPress^® automatisch vorgenommen, sobald die variable Information in jede Textbox eingefügt wurde. Der Vorgang des erneuten Umbruchs reagiert auf Anwenderbefehle, welche an der Textbox oder am Objekt der Vorlagendatei angewendet werden, beispielsweise linksbündiger, rechtsbündiger, zentrierter Satz oder Blocksatz, Silbentrennung und Ähnliches. Im Anschluss an Block 286 prüft ein Block 288, 10e, ob sich auf der Seite noch weitere zu verarbeitende Textboxen befinden; falls ja, wählt ein Block 290 die nächste Textbox auf der Seite aus; zur Einfügung von Textdaten in diese Textboxen kehrt die Kontrolle zu den Blöcken 278-288 zurück.
Sobald der Block 288 feststellt, dass alle Textboxen der Seite verarbeitet wurden, ist die erforderliche Programmierung zur Herstellung einer der Seiten der Datei 134 von 5, auf welcher sich ausschließlich variable Informationen befindet, abgeschlossen. Ein Block 292 prüft dann, ob alle Datensätze in der Datenbank für den Einschluss in zusätzliche variable Seiten der zu erzeugenden Datei 134 berücksichtigt wurden. Falls nicht alle Datensätze berücksichtigt wurden, kehrt die Kontrolle zum Block 254, 10c zurück, wo der nächste Datensatz der Datenbank ermittelt und gelesen wird. Andererseits, falls unter Berücksichtigung sämtlicher Datensätze in der Datenbank 108 sämtliche Seiten der Datei 134 hergestellt wurden, wandelt ein Block 294 die Dateidaten zur Herstellung der variablen Seitendatei 137 von 5 in PostScript^® oder in ein anderes PDL-Format um. Auch wird wie vorher eine INI-Datei erstellt, jedoch wird der Parameter "duplex" oder "twinplex" auf den Befehl Nur Simplexdrucken eingestellt. Falls notwendig oder erforderlich, kann die Programmierung, wenn die Länge des Druckdurchlaufs eine gewisse Grenze überschreitet, dahingehend geändert werden, dass für jede variable Seite der Vorlagendatei mehrere variable Seitendateien erstellt werden.
Im Anschluss an Block 294 prüft ein Block 296, ob in der zu verarbeitenden entleerten variablen Seitendatei andere variable Seiten vorhanden sind. Ist dies der Fall, ruft ein Block 298 eine Kopie der entleerten variablen Datei ab, wählt darin die nächste variable Seite aus und löscht die verbliebenen Seiten. Die Kontrolle kehrt dann zu Block 246 von 10c zurück. Im Beispiel der 6a und 6b sind nun das hintere Deckblatt P4 und die entsprechenden Seiten der verbleibenden Druckerzeugnisse für die Verarbeitung ausgewählt. Auf die oben angeführte Art wird durch Entwicklung der Datei, welche die Seiten P4-a bis einschließlich P4-c darstellt, und durch Einfügen der Datenbankinformation in diese Datei für die Erlangung der variablen Seitendatei 136 und der PDL-Version 138 eine Datei erzeugt, welche die variablen Anteile dieser Seite darstellt.
Nach Erstellung der variablen Seitendateien 134, 136 und 137, 138 geht die Kontrolle auf einen Block 300 über, welcher überprüft, ob bereits eine Druckbefehlsdatei erstellt wurde. (Der Begriff "Druckbefehlsdatei", wie er in diesem Dokument verwendet wird, bezieht sich auf jede Datei oder Kombination von Dateien, welche zur Steuerung eines Demand-Druckers oder einer elektronischen Druckerpresse verwendet werden.) Falls nicht, wird von Block 302 eine Datei mit Platzhaltern erstellt, welche anzeigen, an welcher Stelle in der Druckbefehlsdatei die einzelnen Druckmaschinenbefehle für die jeweils herzustellenden Druckerzeugnisse zu platzieren sind. Zur Hilfe bei der erneuten Herstellung von Druckerzeugnissen, welche mangelhaft sind, oder zur Herstellung von Musterdruckerzeugnissen kann die Druckbefehlsdatei auch Daten aus einem oder mehreren Feldern der Datenbank 108 enthalten, welche den beabsichtigten Empfänger der einzelnen Druckerzeugnisse anzeigen. An diesem Punkt kann die Druckbefehlsdatei für das Beispiel von 6a und 6b wie folgt aussehen (wenn Daten von den oben dargestellten Musterdatenbanken verwendet werden):
;RECORD1
;: WILLIAM DOE:606248923
;ENDRECORD
;RECORD2
;:HUGH JORGENSEN:606248923
;END RECORD
;RECORD3
;:JAY P. MORGAN:606248924
;END RECORD
Anschließend an Block 300 (falls die Druckbefehlsdatei bereits existiert) oder an Block 302 wählt ein Block 304 den ersten Datensatz der Datenbank und einen entsprechenden ersten Datensatz in der Druckbefehlsdatei aus. Ein Block 306 prüft dann, ob die aktuell in Verarbeitung befindliche Vorlagendatei den gewählten Datensatz aus der Datenbank enthält. Falls nicht, prüft ein Block 308, ob alle Seiten verarbeitet wurden; ist dies nicht der Fall, werden der nächste Datensatz in der Datenbank 108 sowie ein entsprechender Datensatz in der Druckbefehlsdatei ausgewählt. Die Kontrolle kehrt dann zu Block 306 zurück. Wenn der Block 306 feststellt, dass der gewählte Datensatz in der Vorlagendatei enthalten ist, fügt ein Block 312 eine Anzeige der Abschnittsnummer an einem geeigneten Punkt in der Druckbefehlsdatei ein, sofern die Abschnittsnummer nicht bereits vorhanden ist. Ist die Abschnittsnummer bereits vorhanden, wird der Druckbefehl, der durch die vom Anwender am Block 176 eingegebene Abschnittsnummer identifiziert wird, für die Überschreibung zu einem späteren Zeitpunkt gekennzeichnet. Die Druckbefehlsdatei erscheint nun in den Beispielen von 6a und 6b wie folgt:
;RECORD1
;:WILLIAM DOE:S06248923
;SECTION 1
;ENDSECTION
;ENDRECORD
;REC0RD2
;:HUGH JORGENSEN:6062488923
;SECTION 1
;ENDSECTION
;END RECORD
;RECORD3
;:JAY P. MORGAN:606248924
;SECTION 1
;END SECTION
;END RECORD
Anschließend an Block 312 wählt ein Block 314, 10f eine erste Seite des Abschnitts, und ein Block 316 prüft den Status einer in Speicher 53 gespeicherten Markierung, um festzustellen, ob eine Simplex- oder eine Duplex-Aufgabe angefordert wurde. Falls eine Simplexaufgabe angefordert wurde, werden von einem Block 318 Dateiname und Seitenzahl der Hauptseitendatei sowie, falls auf der Seite variable Informationen angezeigt werden soll, Dateiname und Seitenzahl der variablen Seitendatei für die ausgewählte Seite als Einzelsatzpaar in Speicher 53 gespeichert. Die Feststellung, ob auf der gewählten Seite variable Information angezeigt werden soll, geschieht durch Summenbildung der Inhalte des Zählers der variablen Bildbox und des Zählers der variablen Textbox, wie sie von den Blocks 220 und 234 von 10b erhöht werden.
Ein Block 320 prüft, ob alle Seiten verarbeitet wurden; ist dies nicht der Fall, wird von einem Block 322 die nächste Seite gewählt und die Kontrolle kehrt für die Verarbeitung dieser Seite zu Block 316 zurück. Wenn alle Seiten verarbeitet wurden, geht die Kontrolle zu einem Block 324 über, von dem festgestellt wird, ob alle Datensätze der Datenbank und der Druckbefehle verarbeitet wurden. Die Kontrolle geht auch dann auf den Block 324 über, wenn der Block 308 feststellt, dass alle Seiten verarbeitet wurden.
Falls an diesem Punkt nicht alle Datensätze verarbeitet wurden, kehrt die Kontrolle zum Block 310 zurück, wo die nächsten Datensätze aus der Datenbank und aus der Druckbefehlsdatei ausgewählt werden.
Wenn der Block 324 feststellt, dass alle Datensätze des aktuellen Abschnitts verarbeitet wurden, ermittelt ein Block 326, ob ein anderer Abschnitt zu verarbeiten ist; falls ja, kehrt die Kontrolle zum Block 170 von 10a zurück. Ist kein weiterer Abschnitt zu verarbeiten, dann wurde die Druckbefehlsdatei vollständig zusammengesetzt und der Vorgang endet daher.
Wenn der Block 316 feststellt, dass eine Duplex-Aufgabe auszuführen ist, geht die Kontrolle auf einen Block 328 über, welcher im Speicher 53 einen Befehl speichert, mit dem die Dateinamen und Seitenzahlen der Hauptseitendatei (wie auch, falls variable Information angezeigt werden soll, die entsprechende Information bezüglich der variablen Seitendateien) als zweisätzige Paare gekennzeichnet werden. Die Kontrolle geht dann von Block 328 auf den oben beschriebenen Block 320 über.
Das Ergebnis der Programmierung von 10a-10f ist eine Druckbefehlsdatei mit einer Sequenz von Druckmaschinenbefehlen, welche den Druck von Seiten in der gewünschten Reihenfolge auslösen. Für den Druck der Musterseiten von 6a und 6b, würde die Druckbefehlsdatei wie folgt aussehen:
BOOK A
;RECORD1
;:WILLIAM DOE:606248923
;SECTION 1
"file.m"1@"file.v1"1|"file.m"2
"file.m"3|"file.m"4@"file.v4"1
;ENDSECTION
;ENDRECORD
;RECORD2
;:HUGH JORGENSEN:606248923 35
;SECTION 1
"file.m"1@"file.v1"2|"file.m2
"file.m"3|"file.m"4@"file.v4"2
;ENDSECTION
;ENDRECORD ;RECORD3
;:JAY P. MORGAN:60624892 4
;SECTION 1
"file.m"1@"file.v1"3|"file.m"2
"file.m"3|"file.m"4@"file.v4"3
;ENDSECTION
;ENDRECORD
ENDBOOK
PRINTRUN R
BOOK A
ENDPRINTRUN
Im vorgehenden Beispiel ist "file.m" ein Dateiname, mit dem die Hauptseitendatei 122 gekennzeichnet wird, "file.v1" und "file.v4" sind Dateinamen, die die variablen Seitendateien 137 bzw. 138 kennzeichnen. Die dem Dateinamen folgende Zahl kennzeichnet eine bestimmte Seite der durch den Dateinamen gekennzeichneten Datei. So wird beispielsweise mit dem Namen "file.m"1 die erste Seite der Hauptdatei "file.m" gekennzeichnet, während "file.v1"2 die zweite Seite der variablen Seitendatei "file.v1" bezeichnet. Das Zeichen @ dient dem Zweck, die Seiten der durch dieses Zeichen verknüpften Dateien miteinander in Verbindung zu setzen (d. h., die variablen Seiten über die Hauptseiten zu legen). Die vertikale Linie in den Befehlen zeigt an, dass die Seite(n) auf der linken Seite der vertikalen Linie auf der Vorderseite eines Papiers, die Seite(n) rechts der vertikalen Linien hingegen auf der Rückseite des betreffenden Papiers zu drucken sind. Im Falle eines Simplex-Drucks würde auf der rechten Seite der vertikalen Linie eines Befehls kein Dateiname angezeigt werden.
Erfüllung on-Demand
Die "Erfüllung on-Demand" der vorliegenden Erfindung, welche allgemein die Handhabung der Datenbank und der Druckbefehlsdateien involviert, lässt sich am besten anhand eines Beispiels erläutern. In unserem Beispiel sollen drei verschiedene Versicherungskunden (Jim, Mark und Pete) ihre persönlichen Leistungsbeschreibungen erhalten (in denen variable Information enthalten ist).
Aufgrund der Lage ihrer jeweiligen Wohnungen passen auf Jim, Mark und Pete verschiedene Versicherungsangebote. Genauer gesagt passt Angebot A auf Jim, Angebot B auf Mark und Jim, während Angebot D für Pete geeignet ist. Für jedes Versicherungsangebot (A, B und D) gibt es eine Broschüre, in der die jeweilige Versicherungsart und ihre Leistungen beschrieben sind. Diese Broschüren sollen als Erfüllungsstücke zusammen mit den personalisierten Leistungsbeschreibungen an die Personen ausgesendet werden, auf die die jeweiligen Versicherungsangebote passen. Zusätzlich zu ihrer personalisierten Leistungsbeschreibung werden ihnen folgende Broschüren übersandt: Jim erhält Broschüre A und B, Mark erhält Broschüre B und Pete erhält Broschüre D. Die Erfüllungsstück-Broschüren A, B und D können personalisierte oder variable Informationen oder lediglich statische Information enthalten. Die Erfüllungsstücke können auch im laufenden Betrieb paginiert werden, so dass das gleiche Erfüllungsstück für zwei Kunden eine unterschiedliche Anzahl von Seiten aufweisen kann.
Die Versicherungsgesellschaft stellt eine Originaldatenbank mit Namen und Adressen der Kunden zur Verfügung; ein Beispiel für eine solche Datenbank ist unten dargestellt. (Die Datenbank kann auch zusätzliche Felder mit variabler Information beinhalten.)

Xname Xaddress

Jim 123 Easy St St.

Mark 234 Grove St.

Pete 345 Lucky Ln.

Originaldatenbank
Die Versicherungsgesellschaft verfügt auch über Dateien, welche die zu reproduzierenden und zu versendenden Leistungsbeschreibungen und Erfüllungsbroschüren darstellen. Diese werden vorzugsweise mit Hilfe von DTP-Software wie beispielsweise QuarkXPress^® erstellt. Eine repräsentative Dateiliste würde wie folgt aussehen:

Druckerzeugnis Dateiname

Personalisierte Leistungsbeschreibung Leistungen

Broschüre A BfileA

Broschüre B BfileB

Broschüre D BfileD
Die vorliegende Erfindung legt für die Reproduktion der entsprechenden Druckerzeugnisse und Erfüllungsstücke in der Reihenfolge ihrer Aussendung vier unterschiedliche Methoden offen.
Erfüllungsmethode Nr. 1
Die erste Erfüllungsmethode wird vor allem dann genutzt, wenn die Erfüllungsstücke variable Informationen enthalten. Die erste Methode verändert die Originaldatenbank nach folgenden Kriterien: (1) Einfügen eines Datensatzes (Zeile) für jedes Druckstück (z.B. Leistungsbeschreibung oder Broschüre), die eine Person erhalten soll, sowie (2) Einfügen einer Spalte entsprechend den Dateinamen jener Dateien, welche die an die einzelnen Personen zu versendenden Druckstücke darstellen. Die eingefügte Spalte kann beispielsweise "Xversion" genannt werden. Die veränderte Datenbank der ersten Methode ist im Wesentlichen eine Kombination aus der Originaldatenbank und der von der Versicherungsgesellschaft zur Verfügung gestellten Dateiliste.

Wie aus der veränderten Datenbank unten ersichtlich, wären für Jim 3 Datensätze vorhanden, weil an ihn seine Leistungsbeschreibung sowie die Broschüren A und B versendet würden. Daher würde in der dritten Spalte des ersten Datensatzes für Jim der Name jener Datei angezeigt, welche die Leistungsbeschreibung für Jim darstellt. In gleicher Weise würden in der dritten Spalte des zweiten und dritten Datensatzes für Jim die Namen jener Dateien angezeigt, welche die Broschüren A und B darstellen.

Xname	Xaddress	Xversion
Jim	123 Easy St.	Leistungen
Jim	123 Easy St.	BfileA
Jim	123 Easy St.	BfileB
Mark	234 Grove St.	Leistungen
Mark	234 Grove St.	BfileB
Pete	345 Lucky Ln.	Leistungen
Pete	345 Lucky Ln.	BfileD

Geänderte Datenbank

Der Schritt zur Änderung der Datenbank würde zwischen den Blöcken 172 und 173 von 10a erfolgen. Nach Zusammenführung der ursprünglichen Datenbank und der entsprechenden Dateinamen in der geänderten Datenbank werden die Seiten den Flussdiagramm in 10a-10f entsprechend verarbeitet. Daher würden in unserem Beispiel alle Leistungsbeschreibungs-Broschüren ("Benefits") verarbeitet, anschließend alle Druckerzeugnisse BfileA, dann BfileB und zuletzt BfileD. Zum Zeitpunkt der Erstellung der Druckbefehlsdatei werden die Druckerzeugnisse in der Reihenfolge der Verteilung oder des Postversand erneut sortiert.
Erfüllungsmethode Nr. 2
Die zweite Erfüllungsmethode wird vor allem dann genutzt, wenn die Erfüllungsstücke lediglich statische Informationen enthalten. Wie bei der ersten Methode wird auch in der zweiten Methode aus der Originaldatenbank eine geänderte Datenbank erstellt. Die geänderte Datenbank ist eine Version der ursprünglichen Datenbank mit einer zusätzlichen Anzahl von Spalten, welche der Höchstzahl der Erfüllungsstücke entspricht, die eine Person erhalten kann. In den Spalten sind die Dateinamen der Erfüllungsstücke eingetragen, die die einzelnen Personen erhalten sollen.
In unserem Beispiel kann eine Person neben der Leistungsbeschreibung eine maximale Anzahl von drei Erfüllungsstücken erhalten, daher werden drei Spalten in die Datenbank eingefügt. Die geänderte Datenbank sieht wie folgt aus:

Xname Xaddress Xfull Xful2 Xful3

Jim 123 Easy St. BfileA BfileB

Mark 234 Grove St. BfileB

Pete 345 Lucky Ln. BfileD

Geänderte Datenbank
Wie in der ersten Methode erfolgt die Änderung der Datenbank zwischen den Blöcken 172 und 174 von 10a. Die Datenbank gibt jene Dateien vor, welche zur Erstellung einer dem Druckauftrag entsprechenden Druckbefehlsdatei erforderlich sind.
Die Druckbefehlsdateien, welche die Erfüllungsstücke darstellen (unter der Annahme, dass diese Stücke keine variable Information enthalten), sehen wie folgt aus:

BfileA
;Book
"MasterBfileA"1|"MasterBfileA"2
"MasterBfileA"3|"MasterBfileA"4
"MasterBfileA"5|"MasterBfileA"6
"MasterBfileA"7|"MasterBfileA"8

BfileB
;Book
"MasterBfileB"1|"MasterBfileB"2
"MasterBfileB"3|"MasterBfileB"4
"MasterBfileB"5|"MasterBfileB"6
"MasterBfileB"7|"MasterBfileB"8

BfileD
;Book
"MasterBfileD"1|"MasterBfileD"2
"MasterBfileD"3|"MasterBfileD"4
"MasterBfileD"5|"MasterBfileD"6
"MasterBfileD"7|"MasterBfileD"8
Die Druckbefehlsdateien für die Leistungsbeschreibungen von Jim, Mark und Pete lassen sich wie folgt darstellen:

Benefits
;Jim
;Begin Record
"MasterQxP" 1@"Variable.V01"2|"MasterQxP"2@ Variable.V02"2
"MasterQxP" 3@"Variable.V03"2|"MasterQxP"4@ Variable.V04"2
"MasterQxP" 5@"Variable.V05"2|"MasterQxP"6@ Variable.V06"2
"MasterQxP" 7@"Variable.V07"2|"MasterQxP"8@ Variable.V08"2
;End Record

;Mark
;Begin Record
"MasterQxP" 1@"Variable.V01"3|"MasterQxP"2@ Variable.V02"3
"MasterQxP" 3@"Variable.V03"3|"MasterQxP"4@ Variable.V04"3
"MasterQxP" 5@"Variable.V05"3|"MasterQxP"6@ Variable.V06"3
"MasterQxP" 7@"Variable.V07"3|"MasterQxP"8@ Variable.V08"3
;End Record

;Pete
;Begin Record
"MasterQxP" 1@"Variable.V01"4|"MasterQxP"2@ Variable.V02"4
"MasterQxP" 3@"Variable.V03"4|"MasterQxP"4@ Variable.V04"4
"MasterQxP" 5@"Variable.V05"4|"MasterQxP"6@ Variable.V06"4
"MasterQxP" 7@"Variable.V07"4|"MasterQxP"8@ Variable.V08"4
;End
In der zweiten Methode werden die Druckbefehlsdateien für die Erfüllungsstücke mit den Druckbefehlsdateien für die Leistungsbeschreibungen in einer einzigen Druckbefehlsdatei zusammengefasst. Dies wird durch Auswertung der geänderten Datenbank und Verkettung der entsprechenden Druckbefehlsdateien erreicht. Um genauer zu sein, der erste Datensatz in der Datenbank ist "Jim";
die Methode kopiert daher die mit "Jim" verbundenen Druckmaschinenbefehle aus der Druckbefehlsdatei "Benefits" in eine neue Druckbefehlsdatei. Der Datensatz für Jim in der Datenbank zeigt an, dass Broschüre A (BfileA) und Broschüre B (BfileB) an ihn ausgesandt werden. Die Methode hängt daher die Druckbefehlsdateien für BfileA und BfileB an die neue Druckbefehlsdatei an, welche die Informationen für Jim enthält.
Die Methode geht dann zum zweiten Datensatz (Mark) weiter und wiederholt den Kopiervorgang, wobei sie die Information an die neue Druckbefehlsdatei anhängt, in welcher sich bereits die Information für Jim befindet. Das Muster einer fertig gestellten Druckbefehlsdatei ist unten dargestellt.

Jim
;Begin Record
"MasterQxP" 1@"Variable.V01"2|"MasterQxP"2@ Variable.V02"2
"MasterQxP" 3@"Variable.V03"2|"MasterQxP"4@ Variable.V04"2
"MasterQxP" 5@"Variable.V05"2|"MasterQxP"6@ Variable.V06"2
"MasterQxP" 7@"Variable.V07"2|"MasterQxP"8@ Variable.V08"2

"MasterBfileA"1|"MasterBfileA"2
"MasterBfileA"3|"MasterBfileA"4
"MasterBfileA"5|"MasterBfileA"6
"MasterBFileA"7|"MasterBfileA"8

"MasterBfileB"1|"MasterBfileB"2
"MasterBfileB"3|"MasterBfileB"4
"MasterBfileB"5|"MasterBfileB"6
"MasterBfileB"7|"MasterBfileB"8
;End Record

;Mark
;Begin Record
"MasterQxP" 1@"Variable.V01"3|"MasterQxP"2@ Variable.V02"3
"MasterQxP" 3@"Variable.V03"3|"MasterQxP"4@ Variable.V04"3
"MasterQxP" 5@"Variable.V05"3|"MasterQxP"6@ Variable.V06"3
"MasterQxP" 7@"Variable.V07"3|"MasterQxP"8@ Variable.V08"3

"MasterBfileB"1|"MasterBfileB"2
"MasterBfileB"3|"MasterBfileB"4
"MasterBfileB"5|"MasterBfileB"6
"MasterBfileB"7|"MasterBfileB"8
;End Record

;Pete
;Begin Record
"MasterQxP" 1@"Variable.V01"4|"MasterQxP"2@ Variable.V02"4
"MasterQxP" 3@"Variable.V03"4|"MasterQxP"4@ Variable.V04"4
"MasterQxP" 5@"Variable.V05"4|"MasterQxP"6@ Variable.V06"4
"MasterQxP" 7@"Variable.V07"4|"MasterQxP"8@ Variable.V08"4

"MasterBfileD"1|"MasterBfileD"2
"MasterBfileD"3|"MasterBfileD"4
"MasterBfileD"5|"MasterBfileD"6
"MasterBfileD"7|"MasterBfileD"8

;End Record
Die Leistungsbeschreibung und die Erfüllungsbroschüren werden in der richtigen Verteilungs-/Versandreihenfolge hergestellt, wie von der neuen Druckbefehlsdatei vorgegeben. Wenn man annimmt, dass die Erfüllungsstücke lediglich statische Information enthalten, müssen die den Stücken entsprechende Dateien nur einmal interpretiert (mit dem RIP bearbeitet) werden, was zu einer kürzeren Verarbeitungszeit beiträgt. Darüber hinaus können die Erfüllungsbroschüren als separate Broschüren erzeugt oder an die Leistungsbeschreibung angehängt werden.
Erfüllungsmethode Nr. 3
Die dritte Methode wird vorzugsweise dann eingesetzt, wenn in den Erfüllungsstücken variable Information enthalten ist. Diese Methode verändert die Originaldatenbank dergestalt, dass eine Anzahl kleiner Datenbanken erstellt wird, in denen Informationen für den Druck der personalisierten Leistungsbeschreibungen und der personalisierten Erfüllungsbroschüren enthalten sind.
Jede modifizierte Datenbank entspricht einer Komponente des Auftrags, der erzeugt werden soll. In unserem Beispiel werden daher vier veränderte Datenbanken erstellt: eine für die Leistungsbeschreibung und je eine für die drei Erfüllungsbroschüren.
Für jede Person, welche das betreffende Stück erhalten soll, enthält jede Datenbank einen Datensatz (oder eine Zeile). Die Anzahl der Spalten in der jeweiligen Datenbank hängt von der variablen Information ab, die zur Fertigstellung des personalisierten Druckstücks erforderlich ist. Wenn beispielsweise Broschüre A ein variables Feld (wie den vom Kunden für medizinische Dienstleistungen ausgegebenen Betrag) enthält, ist für die Eintragung der variablen Dollar-Information eine zusätzliche Spalte (beispielsweise mit der Bezeichnung "XDollars") erforderlich. Wenn Broschüre B zwei variable Felder (beispielsweise Dollarbetrag und Name des Leistungsberaters) enthält, werden zwei zusätzliche Spalten (beispielsweise mit dem Namen "XDollars" und "XAdvisor") hinzugefügt.
Jeder Datensatz in den einzelnen Datenbanken hat eine eindeutige Identifikationsnummer. Jede geänderte Datenbank enthält auch eine Spalte (beispielsweise "XuniqueID" genannt), die die zutreffende Identifikationsnummer enthält. Wie weiter unten ausgeführt, wird dieses Identifizierungsfeld zur Erstellung von Druckbefehlsdateien verwendet, mit denen die Erzeugnisse in der richtigen Reihenfolge der Verteilung reproduziert werden. Die Identifizierungsnummer kann auch zur erneuten Bestellung ausgewählter Stücke verwendet werden und ist je nach Anwendung individuell anpassbar.
Die modifizierten Datenbanken für die Leistungsbeschreibungen und die Erfüllungsexemplare in unserem Beispiel sind wie folgt:

Xname Xaddress XuniqueID

Jim 123 Easy St. 0001

Mark 234 Grove St. 0002

Pete 345 Lucky Ln. 0003

Geänderte Datenbank für Leistungen

Xname Xaddress XuniqueID XDollars

Jim 123 Easy St. 0001 134.50

Geänderte Datenbank für Broschüre A (BfileA)

Xname Xaddress XuniqueID XAdvisor XDollars

Jim 123 Easy St. 0001 Dr. Jones 134.50

Mark 234 Grove St. 0002 Dr. Pepper 132.75

Geänderte Datenbank für Broschüre B (BfileB)

Xname Xaddress XuniqueID

Pete 345 Lucky Ln. 0003

Geänderte Datenbank für Broschüre D (BfileD)
Bei der Verarbeitung einer Aufgabe werden für das Druckerzeugnis über die Leistungen und für jedes Erfüllungsstück separate Druckbefehlsdateien erstellt. Die dritte Erfüllungsmethode erstellt dann eine neue Druckbefehlsdatei durch Zusammenlegung der Information aus den vorher generierten Druckbefehlsdateien.
Die neue Druckbefehlsdatei wird durch Zuweisung der in den einzelnen geänderten Datenbanken befindlichen Identifikationsnummernfelder ("XuniqueID") erstellt. Genauer gesagt durchsucht diese Methode die Identifizierungsnummern aller Datensätze in der steuernden Datenbank in einer von der steuernden Datenbank vorgegebenen Sortierreihenfolge, welche in diesem Fall das Druckerzeugnis über die Leistungen ist. Durch diese Methode wird die Leistungs-Datenbank mit den Datenbanken BfileA, BfileB bzw. BfileD in Bezug gesetzt So werden beispielsweise beim ersten Durchlauf des korrelierenden Unterprogramms alle Jim betreffenden Datensätze (XuniqueID 0001) gefunden.
Jedes Mal, wenn die richtige Identifikationsnummer in einer bestimmten Datenbank gefunden wird, wird die diesem Eintrag oder dieser Identifikation entsprechende Druckbefehlsdatei per Pufferkopie in die neue Druckbefehlsdatei übernommen. Nach Assimilierung aller Datenbanken durch Kopieren der entsprechenden Information enthält die neue Druckbefehlsdatei die unten dargestellte Information:
;Jim:0001
;Begin Record
"MasterQxP"1@"Variable.V01"2|"MasterQxP"2@"Variable.V02"2
"MasterQxP"3@"Variable.V03"2|"MasterQxP"4@"Variable.V04"2
"MasterQxP"5@"Variable.V05"2|"MasterQxP"6@"Variable.V06"2
"MasterQxP"7@"Variable.V07"2|"MasterQxP"8@"Variable.V08"2
;End Record
;Jim:0001
;Begin Record
"MasterBfileA"1@"VariableA.V01"2|"MasterBfileA"2@"VariableA.V02"2
"MasterBfileA"3@"VariableA.V03"2|"MasterBfileA"4@"VariableA.V04"2
"MasterBfileA"5@"VariableA.V05"2|"MasterBfileA"6@"VariableA.V06"2
"MasterBfileA"7@"VariableA.V07"2|"MasterBfileA"8@"VariableA.V08"2
;End Record
; Jim: 0001
; Begin Record
"MasterBfileB"1@"VariableA.V01"2|"MasterBfUeB"2@"VariableA.V02"2
"MasterBfileB"3@"VariableA.V03"2|"MasterBfileB"4@"VariableA.V04"2
"MasterBfileB"5@"VariableA.V05"2|"MasterBfileB"6@"VariableA.V06"2
"MasterBfileB"7@"VariableA.V07"2|"MasterBfileB"8@"VariableA.V08"2
;End Record
;Mark:0002
;BeginRecord
"MasterQxP"1@"VariableB.V01"3|"MasterQxP"2|"VariableB.V02"3
"MasterQxP"3@"VariableB.V03"|"MasterQxP"4@"VariableB.V04"3
"MasterQxP"5@"VariableB.V05"3|"MasterQxP"6@"VariableB.V06"3
"MasterQxP"7@"VariableB.V07"3|"MasterQxP"8@"VariableB.V08"
;End Record
;Mark:0002
;Begin Record
"MasterBfileB"1@"VariableB.V01"3|"MasterBfileB"2@"VariableB.V02"3
"MasterBfileB"3@"VariableB.V03"3|"MasterBfileB"4@"VariableB.V04"3
"MasterBfileB"5@"VariableB.V05"3|"MasterBfileB"6@^>"VariableB.V06"3
"MasterBfileB"7@"VariableB.V07"3|"MasterBfileB"8@"VariableB.V08"3
;End Record

;Pete:0003
;Begin Record
"MasterQxP"1@"Variable.V01"4|"MasterQxP"2@"Variable.V02"4
"MasterQxP"3@"Variable.V03"4|"MasterQxP"4@"Variable.V04"4
"MasterQxP"5@"Variable.V05"4|"MasterQxP"6@"Variable.V06"4
"MasterQxP"7@"Variable.V07"4|"MasterQxP"8@"Variable.V08"4

;Pete:0003
;Begin Record
"MasterBfileD"1@"VariableD.V01"2|"MasterBfileD"2@"VariableD.V02"2
"MasterBfileD"3@"VariableD.V03"2|"MasterBFleD"4@"VariableD.V04"2
"MasterBfileD"5@"VariableD.V05"2|"MasterBfileD"6@"VariableD.V06"2
"MasterBfileD"7@"VariableD.V07"2|"MasterBfileD"8@"VariableD.V08"2
;End Record
Wie in der zweiten Methode werden die Leistungsbeschreibung und die Erfüllungsbroschüren in der richtigen Verteilungs-/Versandreihenfolge hergestellt. Auch können die Erfüllungsbroschüren als separate Broschüren erzeugt oder an die Leistungsbeschreibung angehängt werden.
Erfüllungsmethode Nr. 4 (Einfügen während des Ausschießens)
In der vierten Erfüllungsmethode kommen die weiter unten in größerem Detail beschriebenen Ausschießverfahren ("GetTiff Imposition" oder "Imposition-on-the-Fly") zum Einsatz. Generell behandelt die vierte Methode jede Erfüllungsseite als ein vollseitiges variables Bild und verändert die Datenbank dergestalt, dass sie die einzufügenden Erfüllungsseiten enthält. Auf diese Weise werden die Erfüllungsseiten als zusätzliche Seiten zur Bildung eines vollständigen Druckerzeugnisses behandelt und werden automatisch in das Druckerzeugnis ausgeschossen. Diese Methode wird vorzugsweise dann benützt, wenn die Erfüllungsseiten variable Informationen enthalten, und wenn die Erfüllungsstücke in ein Druckerzeugnis gebunden und nicht als separate Stücke behandelt werden.
In unserem Beispiel wäre die personalisierte Leistungsbeschreibung, welche Jim, Mark und Pete zugesandt werden soll, in einer QuarkXPress^®-Datei namens "Leistungen" gespeichert. Wir nehmen einmal an, dass jede Broschüre (A, B und D) vier Seiten enthält und auf jeder Seite variable (personalisierte) Information enthalten ist. Vorzugsweise wurde jede Seite dieser Broschüren in QuarkXPress^® erstellt und im EPS-(Encapsulated PostScript^®) Format gespeichert. Die Dateien der Broschürenseiten könnten wie folgt benannt werden:

Broschüre A Broschüre B Broschüre D

BfileA.1 BfileB.1 BfileD.1

BfileA.2 BfileB.2 BfileD.2

BfileA.3 BfileB.3 BfileD.3

BfileA.4 BfileB.4 BfileD.4
Wenn eine Person alle drei Erfüllungsbroschüren erhalten soll, dann würde diese Person (bei angenommenen vier Seiten pro Broschüre) 12 (zwölf) zusätzliche Seiten erhalten. Die Höchstanzahl von Erfüllungsseiten ist 12, daher werden in der Leistungsdatei zwölf zusätzliche Seiten eingefügt. (Wenn jedoch bekannt ist, dass eine Person maximal nur zwei Erfüllungsbroschüren erhält, dann müssen natürlich nur acht zusätzliche Seiten in das Druckerzeugnis Leistungen eingefügt werden.)
Wenn die erforderliche Anzahl von Seiten in die Leistungsdatei eingefügt wurde, wird jeder Seite eine vollseitige, mit Namen versehene Bildbox hinzugefügt. Die Namen in den einzelnen Bildboxen würden den Spaltennamen in der Datenbank entsprechen, in welcher die Informationen über die Erfüllungsseiten gespeichert sind. So könnte zum Beispiel die Bildbox der ersten Seite "XFPage1" genannt werden, die Bildbox der zweiten Seite "XFPage2", der dritten Seite "XFPage3" usw.
Als Nächstes wird die Datenbank wie folgt verändert: (1) Durch Hinzufügen von der Maximalanzahl der Erfüllungsseiten entsprechenden Spalten, (2) Durch Benennung der Spalten entsprechend den mit Namen versehenen Bildboxen, sowie (3) Auffüllen der Datenbankfelder mit den Dateinamen, die mit den Erfüllungsseiten verbunden sind. Die (teilweise) geänderte Datenbank sieht wie folgt aus:

Xname Xaddress XFPage1 XFPage2 ... XFPagel2

Jim 123 Easy St. BfileA.1 BfileA.2 ...

Mark 234 Grove St. BfileB.1 BfileB.2 ...

Pete 345 Lucky Ln. BfileD.2 BfileD.2 ...
Wie in 11 dargestellt, werden bei der Erstellung des Anweisungssatzes, in welchem festgelegt wird, welche Seiten zu drucken und wie die Seiten für den Druck zu positionieren (oder auszuschießen) sind, die Erfüllungsseiten berücksichtigt. Die Erfüllungsseiten werden daher verarbeitet (und ausgeschossen), als wenn sie Teil des Druckerzeugnisses wären.
Daneben lässt sich diese Methode mit allen anderen Aspekten des Ausschießens im laufenden Betrieb, wie beispielsweise der linken/rechten Seitenausrichtung, der Seitennummerierung, der Barcodierung von Blättern und Ähnlichem einsetzen.
Ausschießverfahren
11 stellt die vom Steuergerät 52 umgesetzte Programmierung zur Erstellung eines Befehlssatzes in Seitenbeschreibungssprache dar, mit dem festgelegt wird, welche Seiten zu drucken und wie die Seiten für den Druck zu positionieren (oder auszuschießen) sind. Der Befehlssatz der Seitenbeschreibungssprache kann in die Druckbefehlsdatei 140 aufgenommen oder dem Drucksystem 79 als separate Datei geliefert werden.
Für Darstellungszwecke wird der Befehlssatz der Seitenbeschreibungssprache in PostScript^® in dem vom Xerox DocuPrint-Drucker vorgegebenen Format geschrieben. Darüber hinaus richtet sich der Befehlsatz an Druckerzeugnisse, die im "Heftstich"-Ausschießformat (d.h. 2 Seiten auf jeder Blattseite) gedruckt werden, wie in Verbindung mit 6-8 erläutert. Es wird jedoch darauf hingewiesen, dass die Erfindung problemlos für den Einsatz mit einem anderen Demand-Drucker (z.B. dem Xeikon Barco Drucker) und oder einem anderen Ausschießformat (z.B. vier Seiten auf jeder Blattseite) angepasst werden kann.
Wie in 11 dargestellt, beginnt die Programmierung bei einem Block 340, der den Anwender auffordert, bestimmte Informationen zu spezifizieren, welche zur Paginierung des Druckerzeugnisses verwendet werden kann. Eine Variable ("MAXPGS"), welche die maximale Anzahl von gelieferten Seiten darstellt, die im Laufe der Aufgabe in einem Druckerzeugnis zusammengefasst oder nicht zusammengefasst werden können, wird zusammen mit der Identifizierung der Füllseite(n) festgelegt, welche gedruckt oder nicht gedruckt und am Ende des Druckerzeugnisses entweder im linken Teil oder im rechten Teil zusammengestellt werden können. Gleichzeitig wird der Anwender aufgefordert, für jede einzelne Seite festzulegen, ob diese Seite zwangsweise auf der linken Seite eines Druckerzeugnisses, der rechten Seite eines Druckerzeugnisses oder nicht unbedingt auf einer bestimmten Seite des Druckerzeugnisses erscheinen muss. Für den Fall, dass eine Seite zwangsweise auf einer bestimmten Seite anzuzeigen ist, wird der Anwender aufgefordert, den Seitendateinamen und die Seitenzahl für eine Füllseite anzugeben, welche der zwangsweise angeordneten Seite vorausgehen soll. Darüber hinaus wird der Anwender aufgefordert, für jede Seite anzugeben, ob diese Seite:

1) eine Hauptseite ist – sie enthält dieselbe Information und scheint in jedem Druckerzeugnis auf,
2) eine immer variable Seite ist – sie enthält unter Umständen variable Information und scheint in jedem Druckerzeugnis auf,

3) eine selektiv variable Seite ist – sie enthält variable Information und ist nur selektiv in bestimmten Druckerzeugnissen enthalten.

Durch diese Angaben erstellt der Anwender eine Paginierungsdatei (welche beispielsweise *.PAG genannt wird, wobei * den vom Anwender gewählten Dateinamen darstellt). In 12 ist ein von Block 340 generiertes Beispielfenster dargestellt, in welchem der Anwender zur Eingabe der für die Erstellung der Paginierungsdatei erforderlichen Information aufgefordert wird.
Ebenfalls in 11 öffnet ein Block 342 im Nachgang zu Block 340 die Druckbefehlsdatei, während Block 344 die entsprechenden Datenbankdateien auswählt, insbesondere die variable Informationsdatei (*. VARS), die Paginierungsdatei (*. PAG), sowie (optional) eine Barcode-Datei. Wie oben ausgeführt, handelt es sich bei der Datei *.VARS um eine temporäre Datei von Paaren von Seitennummern und Datenbank-Spaltennummern, mit denen angezeigt wird, von woher in der Datenbank die variable Information für die Seiten stammt.
Bei der Barcode-Datei handelt es sich um eine Seitenbeschreibungssprachdatei (beispielsweise um eine PostScript^®-Datei), welche Anweisungen für den Druck der Reihenfolge von Seitennummern und/oder eines Nachverfolgungs-Barcodes auf den Seiten des fertig gestellten Druckerzeugnisses enthält. Die Barcode-Datei wird weiter unten eingehender erläutert.
Die Programmierung schreitet dann weiter zur Schleife, welche die Blocks 346, 348, 350, 352 und 354 umfasst. Der Block 346 arbeitet jeden Datensatz (oder jedes Druckerzeugnis) in der Druckbefehlsdatei 140 in sequenzieller Reihenfolge ab.
Bei jedem Datensatz stellt der Block 348 fest, welche Seiten zur Herstellung des betreffenden Druckerzeugnisses gedruckt werden sollen. Im nächsten Schritt legt der Block 350 fest, ob die zu druckenden Seiten zwangsweise auf der rechten oder auf der linken Seite des Druckerzeugnisses erscheinen sollen, während der Block 352 die zu druckenden Seiten durch das Einfügen entsprechender. Füllseiten so auffüllt, dass ihre Anzahl ein Vielfaches der Anzahl von Seiten beträgt, die auf ein Blatt gedruckt werden sollen (in unserem Beispiel 4). Als nächstes generiert der Block 354 den PostScript^® Befehlssatz; die Programmierung kehrt für den Abruf des nächsten Datensatzes in der Druckbefehlsdatei 140 zu Block 346 zurück. Die Schleife wird für jeden in der Druckbefehlsdatei 140 vorhandenen Datensatz durchlaufen.
13 stellt im Detail die von Block 348 der 11 implementierten Programmierschritte dar, mit deren Hilfe festgelegt wird, welche Seiten für einen bestimmten Datensatz in der Druckbefehlsdatei 140 gedruckt werden sollen. Ein Block 360 ruft die erste Seite im Datensatz ab. Ein Entscheidungsblock stellt dann fest, ob die Seite aus einer neuen Datei stammt, welche "im laufenden Betrieb mit Offsets auszuschießen" ist. (Ausschießen im laufenden Betrieb mit Offsets ist eines der Ausschießformate der vorliegenden Erfindung und wird weiter unten in größerer Detailtiefe erläutert.) Falls ja, berechnet ein Block 364 die Offsets für alle Seiten in der Datei und speichert diese. Nachdem der Block 364 die Offsets berechnet und gespeichert hat, oder wenn Block 362 auf False gesetzt ist, ermittelt ein Entscheidungsblock 366, ob es sich bei der Seite um eine Hauptseite handelt (d.h., dass auf ihr keine variable Informationen und keine Platzhalter enthalten sind). Wenn es sich bei der Seite um eine Hauptseite handelt, muss die Seite immer gedruckt werden, daher wird diese Seite als zu druckenden Seite "markiert".
Der Block 368 kann die Seite dadurch "markieren", dass er sie in eine Seitendruckmatrix einfügt. Die Seitendruckmatrix enthält die Seitennummer und eine Markierung zur Anzeige der Anordnung dieser Seite. So werden beispielsweise Seiten, die nicht gedruckt werden sollen, mit "0" gekennzeichnet, Hauptseiten (werden immer gedruckt) mit "1" sowie zu druckende variable Seiten mit "2".
Wenn Block 366 feststellt, dass es sich bei einer Seite nicht um eine Hauptseite handelt (d.h., dass sie eine variable Seite ist), ermittelt ein Entscheidungsblock 370, ob die variable Seite zu allen Zeiten zu drucken ist. (Dies wurde vom Anwender bei der Erstellung der Paginierungsdatei am Block 340 in 11 angegeben.) Ist dies der Fall, dann markiert der Block 368 die Seite als zu druckende Seite. Falls nicht, stellt ein Entscheidungsblock 372 fest, ob auf der Seite variable Platzhalter mit gültigen Daten vorhanden sind. Mit anderen Worten, Block 372 stellt fest, ob eine variable Information aus der Datenbank auf dieser Seite gedruckt werden soll. Falls ja, dann markiert der Block 358 die Seite als zu druckende Seite. Das Programm kehrt dann zu Block 360 zurück, um die nächste Seite aus dem Datensatz abzurufen, bis alle entsprechenden Seiten für den Druck markiert sind.
14 ist eine detaillierte Darstellung der in Block 350 von 11 umgesetzten Programmierungsschritte, mit denen festgelegt wird, ob die Seiten des Druckerzeugnisses linksbündig oder rechtsbündig anzulegen sind. Ein Block 380 initialisiert zunächst eine Links/Rechts-Zählervariable auf den Standardwert rechts, da angenommen wird, dass die erste Seite des Druckerzeugnisses auf der rechten Seite angeordnet sein wird. Im nächsten Schritt ruft ein Block 382 die erste Seite aus dem Datensatz mit der Markierung "zu drucken" ab; ein Block 384 stellt dann fest, ob der Anwender angegeben hat, dass die Seite rechts oder links anzuordnen ist. (Dies wurde vom Anwender bei der Erstellung der Paginierungsdatei am Block 340 in 11 angegeben.) Falls der Anwender nicht angegeben hat, dass die Seite eine bestimmte Position einnehmen muss, kippt ein Block 386 den Links/Rechts-Zähler dergestalt, dass er auf links gestellt wird, wenn er auf rechts gestellt war, und dass er auf rechts gestellt wird, wenn er auf links gestellt war; das Programm kehrt zum Block 382 zurück und ruft die nächste Seite "zu drucken" im Datensatz ab.
Alternativ, wenn der Block 384 feststellt, dass der Anwender die Anordnung einer Seite auf die linke oder rechte Seite festgelegt hat, stellt ein Block 388 fest, ob die Vorgaben des Anwenders mit der Ausrichtung der Seite übereinstimmt (d.h. den Links/Rechts-Zähler entspricht). Falls ja, schaltet Block 386 den Links/Rechts-Zähler um und kehrt zu Block 382 zurück, um die nächste Seite "zu drucken" im Datensatz abzurufen. Andernfalls kennzeichnet ein Block 390 eine entsprechende Füllseite (die vom Anwender bei der Erstellung der Paginierungsdatei festgelegt wurde) für den Druck; das Programm kehrt zu Block 382 zurück, um die nächste Seite "zu drucken" im Datensatz abzurufen.
15 stellt im Detail die Programmierschritte dar, die von Block 352 der 11 umgesetzt werden, um die in Druckerzeugnis enthaltenen Seiten auf ein Vielfaches der Anzahl der auf einem Blatt zu druckenden Seiten "aufzufüllen". In unserem Beispiel werden mithilfe des Ausschießens mit "Heftstich" vier Seiten auf ein Blatt (2 Seiten pro Blattseite) gedruckt. Um sicherzugehen, dass die Gesamtanzahl der Seiten im Druckerzeugnis ein Vielfaches von 4 darstellt, ist daher unter Umständen das Einfügen von Füllseiten erforderlich.
Ein Block 392 zählt zunächst die Anzahl der Seiten im Datensatz, welche für den Druck markiert wurden. Dazu zählen sämtliche Hauptseiten und variablen Seiten, die vom Block 368 in 13 markiert wurden, sowie alle Füllseiten, die von Block 390 in 14 markiert wurden. Im nächsten Schritt prüft ein Block 394, ob die Gesamtanzahl der Seiten ein Vielfaches von 4 ist. Falls nicht, fügt ein Block 396 die entsprechende Anzahl von Füllseiten ein, damit die Gesamtanzahl Seiten ein Vielfaches von 4 beträgt. Wenn beispielsweise Block 392 feststellt, dass 18 Seiten für den Druck markiert sind, fügt Block 396 zwei (2) Füllseiten hinzu, damit die Gesamtanzahl von Seiten im Druckerzeugnis der Zahl 20 (einem Vielfachen von 4) entspricht. Das Programm kehrt dann zu Block 354 in 11 zurück, der den PostScript^®-Befehlssatz erstellt.
Der PostScript^®-Befehlssatz legt fest, wie die für den Druck markierten Seiten für den Druckvorgang zu positionieren (oder auszuschießen) sind. In unserem Beispiel generiert Block 354 für ein Ausschießformat mit Heftstich und unter Annahme eines 12seitigen Druckerzeugnisses eine Anweisung, in der festgelegt wird, dass die Seiten wie in der folgenden Tabelle gezeigt anzuordnen sind:

Bogen Nr. Blattseite Nr. Linke Seite Rechte Seite

1 1 Seite 12 Seite 1

1 2 Seite 2 Seite 11

2 1 Page 10 Page 3

2 2 Seite 4 Seite 9

3 1 Seite 8 Seite 5

3 2 Seite 6 Seite 7
Es könnte jedoch ein anderer Befehlssatz (durch ein Ausschießprogramm) erzeugt werden, um die Seiten in einem unterschiedlichen Format (d.h. vier Seiten pro Blattseite) oder alternativ eine andere Gesamtzahl von Seiten auszuschießen und zu drucken.
Nachdem der Block 354 den Befehlssatz für das Ausschießen generiert hat, werden die Seiten entsprechend einem Ausschießverfahren der vorliegenden Erfindung ausgeschossen und gedruckt. Das erste Ausschießverfahren der vorliegenden Erfindung setzt einen künstlichen PostScript^® Operator namens "GetTIFF" ein, der vom Xerox DocuPrint RIP erkannt wird und in welchem die Seitendateien im TIFF-Format ("Tagged Image File Format") vorbearbeitet werden, bevor sie an den RIP ergehen. Bei dem (als "Ausschießen im laufenden Betrieb" bezeichneten) zweiten Ausschießverfahren der vorliegenden Erfindung werden Ausschießprogramme in den RIP heruntergeladen; sie definieren verschiedene PostScript^®-Operatoren um, um automatisch Seiten zu positionieren, während die einzelnen Seiten interpretiert werden.
Ein Anwender wird aufgefordert, verschiedene für das Ausschießen und den Druck erforderlichen Angaben festzulegen, insbesondere Angaben zu Blattgröße (d.h. 11 × 17), Art des Ausschießens (Ausschießen im laufenden Betrieb oder GetTIFF), Art der Endbearbeitung (Online oder Offline), Ausgabegerät (d.h. Xerox DocuPrint oder Barco Xeikon) sowie Namen des Verzeichnisses, in welchem die Hauptdateien und die variablen Seitendateien gespeichert sind. Ein Beispielfenster für die Aufforderung an den Anwender zur Lieferung dieser Angaben ist in 16 dargestellt.
GetTIFF Ausschießen
Bei einer TIFF-Datei (Tagged Image File Format) handelt es sich um eine Bitmap-Darstellung einer Seite im selben Bildschirmformat wie die Druck-Engine. Eine Reihe im Handel erhältlicher RIPs (wie beispielsweise Image Alchemy PS oder TranverterPro) verarbeiten Seiten, welche im Format einer Seitenbeschreibungssprache dargestellt sind, in das TIFF-Format.
Der Xerox DocuPrint RIP erkennt einen künstlichen PostScript^® Operator namens "Get-TIFF", der eine festgelegte TIFF-Datei abruft und sie rasch für die Verarbeitung durch den DocuPrint Demand-Drucker verarbeitet. (Auch andere Demand-Drucker RIPs, insbesondere der Barco Xeikon, lassen sich so ändern, dass sie einen Operator der GetTIFF-Art erkennen).
In einem Ausführungsbeispiel der vorliegenden Erfindung werden die PDL-Dateien 122 der Hauptseiten sowie die PDL-Dateien 137, 138 der variablen Seiten vorher in das TIFF-Format umgearbeitet. Da das Xerox DocuPrint-System lediglich einen Eingangs-Datenstrom zulässt (im Gegensatz zum Barco Xeikon-System, welches zwei Datenströme – Hauptstrom und variablen Strom – erlaubt), können die PDL-Dateien 122 der Hauptseiten und die PDL-Dateien 137, 138 der variablen Seiten im Voraus zusammengeführt werden. Dies wird dadurch erreicht, dass sämtliche Hauptdaten in die Dateien mit den variablen Vorlagen hineingezwungen werden. Nach der Zusammenführung von Hauptseiten und variablen Seiten werden die Seiten mithilfe des Befehlssatzes und des GetTIFF-Operators rasch für den Druck ausgeschossen und verarbeitet.
Alternativ lassen sich der Hauptdatenstrom und der variable Datenstrom im Overlay aufbringen, indem zunächst die Hauptseiten verarbeitet und dann variable Seiten und Hauptseiten im Overlay aufgebracht werden.
17 stellt die Programmierung dar, die zur Umwandlung der Seitendateien in das TIFF-Format durchgeführt werden kann. Die Programmierung beginnt bei einem Block 397, der die im Speicher 53 gespeicherte Druckbefehlsdatei öffnet. Ein Block 398 fordert anschließend den Anwender auf, die zur Verfügung stehenden Optionen festzulegen. Zu den Optionen zählt die Möglichkeit, die Umwandlung in das Bitmap-Format nur an Hauptseitendateien, nur an variablen Seitendateien oder sowohl an Hauptseitendateien wie auch an variablen Seitendateien vorzunehmen. Ein Block 399 wählt dann die erste Zeile der Druckbefehlsdatei, in welcher sich mindestens ein Dateiname befindet.
Anschließend wählt ein Block 400 einen ersten Dateinamen und ein Block 401 prüft in einer in Speicher 53 hinterlegten Dateiliste, ob dieser Dateiname bereits früher in die Liste eingetragen wurde. Ist das nicht der Fall, dann ist dies das erste Mal, dass der Dateiname in der Programmierung von 17 aufgetaucht ist. Daher fügt ein Block 402 den Dateinamen in die Dateiliste ein, während ein Block 403 die von Block 398 gesetzten, vom Anwender spezifizierten Optionen dahingehend prüft, ob die Datei in das TIFF-Format umgewandelt werden soll oder nicht. Falls ja, wird eine in Speicher 53 gespeicherte RIP-Liste durch Einfügen eines Dateinamens (Block 404) aktualisiert, die Kontrolle geht zu einem Block 405 über. Die Kontrolle geht auch von Block 403 (unter Umgehung von Block 404) auf Block 405 über, wenn die Datei nicht in das TIFF-Format umgewandelt werden soll, und von Block 401, falls sich der aktuell in Betrachtung stehende Dateiname bereits in der Dateiliste befindet.
Der Block 405 überprüft, ob das Ende der aktuellen Zeile in der Druckbefehlsdatei erreicht wurde. Falls nicht, wählt ein Block 406 den nächsten Dateinamen in der Zeile aus, worauf die Kontrolle zu Block 401 zurückkehrt.
Wenn Block 405 feststellt, dass das Ende der aktuellen Zeile in der Druckbefehlsdatei erreicht ist, prüft ein Block 407, ob das Ende der Druckbefehlsdatei erreicht ist. Falls nicht, wählt ein Block 408 die nächste Zeile in der Druckbefehlsdatei, in welcher sich mindestens ein Dateiname befindet, die Kontrolle kehrt zu Block 400 zurück. Falls jedoch das Ende der Datei erreicht ist, veranlasst ein Block 409 den RIP 82 (oder einen anderen RIP), die in der RIP-Liste aufgeführten Dateien in das TIFF-Format umzuwandeln.
Auf diese Weise erleichtert die Programmierung von 17 die Umwandlung der Dateien in das TIFF-Format, wie vom Drucksystem 79 erfordert.
Wie in 18 dargestellt, wenn der Anwender GetTIFF-Ausschießen spezifiziert hat und sobald die Seitendateien durch die Programmierung von 17 mithilfe von RIP in das TIFF-Format umgearbeitet wurden, ruft ein Block 410 die erste Seitenpaarung aus dem Befehlssatz (in unserem Beispiel Seite 12 als linke Seite und Seite 1 als rechte Seite) ab. Ein Block 412 ruft dann einen Bezug auf die Seitenbeschreibung der linken Seite im TIFF-Format aus der Seitendatei und gibt sie an den RIP 82 weiter. Unter der Annahme, dass der Standard-Offset auf die linke Blattseite gesetzt ist, wird die linke Seite auf die linke Blattseite positioniert.
Ein Block 414 verschiebt dann den Offset, um die nächste Seite auf die rechte Blattseite zu positionieren. Ein Block 416 ruft aus der Seitendatei den Bezug auf die Seitenbeschreibung im TIFF-Format auf der rechten Blattseite ab und liefert sie an den RIP 82. Im nächsten Schritt kann ein Block 418 Seitenzahlen und/oder einen Nachverfolgungs-Barcode auf dem Bogen aufbringen, wie weiter unten erläutert. Das Programm kehrt dann zum Block 410 zurück, um das nächste Seitenpaar aus dem Befehlssatz abzurufen; das Programm wiederholt dies, bis sämtliche Seiten und sämtliche Druckerzeugnisse verarbeitet sind.
Nachdem alle Seiten verarbeitet wurden, werden sie mit RIP verarbeitet und vom Demand-Drucker 84 entsprechend der von Block 212 (10b) erstellten Initialisierungsdatei (INI-Datei) gedruckt.
Wenn beispielsweise der Demand-Drucker ein DocuPrint ist (d.h., keine INI-Datei erstellt wurde), werden die Seiten in die (dieselben Parameter wie die INI-Datei enthaltende) Schlange zur Verarbeitung durch den RIP und zum Druck eingereiht.
Ein partieller PostScript^®-Befehlssatz zum Druck der 12-seitigen Broschüre entsprechend der Tabelle oben unter Umsetzung des GetTIFF-Ausschießens nach 18 ist hier ausgeführt:
Im Befehlssatz weist "VERON*.*_dir/VERON*.* auf die Namen des Verzeichnisses und der Datei hin, in welcher sich die Seitenbeschreibungen befinden.
Das Suffix ".M" weist darauf hin, dass es sich um eine Hauptseite (Main Page) handelt, während das Suffix ".V_" eine variable Seite anzeigt (samt Versionsnummer der zu druckenden variablen Seite). Das Suffix "*_.tiff" ist der vom RIP bei der Umwandlung der Seitendateien in TIFF-Dateien erzeugte Dateiname; er zeigt an, dass dies Dateien im TIFF-Format sind. Der künstliche PostScript^® "GetTIFF" Operator interpretiert die TIFF-Dateien. Der Befehl "612 0 translate" verschiebt den Offset zur rechten Blattseite (Block 414), während der PostScript^®-Operator showpage die Seite zum Druck an den Demand-Drucker 84 überträgt, sich auf die Interpretation der nächsten Seitenbeschreibung vorbereitet und den Offset auf die linke Blattseite zurücksetzt.
Optional kann der Block 418 Seitenzahlen und/oder einen Nachverfolgungs-Barcode auf die vom Demand-Drucker 84 gedruckten Bögen aufbringen. Dies wird durch Einfügen des folgenden zusätzlichen PostScript^®-Codes vor dem Operator showpage in dem oben dargestellten Befehlssatz erreicht:
Der erste Abschnitt des Codes liefert den Befehl für den Druck eines Barcodes (der beispielsweise die Seitenzahl und die Gesamtanzahl der Seiten im Druckerzeugnis anzeigt). Der zweite Abschnitt des Codes druckt Seitenzahlen zentriert am unteren Ende einer jeden Seite.
Eine ähnliche Methode könnte zur Vornahme nachträglicher Seitenänderungen wie zum Beispiel die Einfügung von Wasserzeichen, Muster oder Qualitätskontroll-Druckerzeugnissen, die Einfügung variabler Druckmarkierungen oder Ähnliche eingesetzt werden.
Ausschießen im laufenden Betrieb (Imposition-on-the-Fly)
Der Anwender kann auch festlegen, dass die Seiten mit Hilfe der Methode des Ausschießens im laufenden Betrieb der vorliegenden Erfindung ausgeschossen und gedruckt werden sollen. Bei dieser Methode werden die Seiten positioniert, während sie vom RIP interpretiert werden. 19 ist ein detaillierteres Blockdiagramm des in 4 dargestellten Drucksystems 79. Die PDL-Dateien 122 der Hauptseiten und die PDL-Dateien 137, 138 der variablen Seiten können in zusammengeführte PDL-Dateien (wie zum Beispiel zusammengeführte PostScript-Datei(en) 450) zusammengelegt werden, welche anschließend an das Drucksystem 79 weitergegeben werden, das sich aus dem RIP 82, dem Collator 81, der Druckmaschinensteuerung 80 und dem Demand-Drucker 84 zusammensetzt. Die Druckbefehlsdatei 140, in der der Befehlssatz für die Festlegung des Ausschießens der Seiten enthalten ist, wird ebenfalls dem Drucksystem 79 weitergegeben.
Alternativ können, wie oben beschrieben, die Hauptseitendateien 22 und die variablen Seitendateien 137, 138 separat an das Drucksystem 79 weitergegeben und im Overlay angewandt werden.
Das Drucksystem 79 kann auch einen Rasterspeicher 452 umfassen, der mit dem RIP 82 und dem Demand-Drucker 84 verbunden ist. Der RIP 82 generiert eine Rasterbeschreibung der "aktuellen Seite", die gerade interpretiert wird; diese kann im Rasterspeicher 452 gespeichert oder an den Demand-Drucker 84 zur Darstellung weitergegeben werden. Der Demand-Drucker 84 stellt die Seiten 454 aus der zusammengeführten PostScript^®-Datei auf einer "Blattseite" (oder einem anderen Medium) 456 dar.
Zu Darstellungszwecken wird angenommen, dass der RIP 82 die vielfach verwendete PostScript^® PDL-Sprache interpretiert. (PostScript^® ist ein eingetragenes Warenzeichen von Adobe Systems, Inc.) Die Sprache PostScript^® ist im Handbuch PostScript^® Language Reference Manual, Second Edition (1990) von Adobe Systems, Inc., welches hiermit Bestandteil dieses Dokuments wird, vollständig beschrieben. Bestimmte Verfahren zum Ausschießen im laufenden Betrieb 454 der vorliegenden Erfindung werden in den RIP 82 heruntergeladen. (Zu den Verfahren 454 zählen beispielsweise ImposeJob, ImposeFile und verschiedene umdefinierte PostScript^®-Operatoren, welche weiter unten eingehend beschrieben sind.) Die Verfahren zum Ausschießen im laufenden Betrieb 454 werden vom RIP 82 zur Verarbeitung des Befehlssatzes und der Seitenbeschreibungen verwendet, welche in den zusammengeführten PostScript^®-Dateien 450 enthalten sind, um die Seiten effizient zur Darstellung durch den Demand-Drucker 84 zu übermitteln. (Zur Erleichterung in der Darstellung wird davon ausgegangen, dass die Hauptseitendateien und die variablen Seitendateien im Voraus in der Datei 450 zusammengeführt wurden. Gleichzeitig sollte jedoch beachtet werden, dass die Hauptseitendateien und die variablen Seitendateien auch im Overlay angewandt werden können.)
Hintergrundinformation zu PostScript^®
Um die Erläuterung der Verfahren zum Ausschießen im laufenden Betrieb der vorliegenden Erfindung zu erleichtern, folgt hier Hintergrundinformation über die PostScript^®-Sprache. Weitere Details sind im Handbuch PostScript^® Language Reference: Manual, Second Edition (1990) von Adobe Systems, Inc., zu finden, welches bereits weiter oben zum Bestandteil dieses Dokuments deklariert wurde.
Der RIP 82 verwaltet vier verschiedene Stapel, bei denen es sich um so genannte "last-in-first-out" (LIFO-) Datenstrukturen handelt. Zu diesen Stapeln zählen:

(1) Ein Operandenstapel, in dem (i) die Eingabeoperanden der verschiedenen PostScript^®-Operatoren sowie (ii) die Ergebnisse der Operationen enthalten sind,
(2) Ein vom RIP 82 gesteuerter Ausführungsstapel, der ausführbare Objekte (d.h. Prozeduren und Dateien) enthält, die sich im Stadium der Ausführung befinden,
(3) Ein Dictionary-Stapel, bestehend aus (i) einem Nur-lesen-Dictionary ("systemdict"), das die Implementierung der verschiedenen PostScript^®-Operatoren definiert, (ii) einem schreibbaren Dictionary ("userdict"), welches alle anderen Definitionen speichert, sowie (iii) aus vom Anwender erstellten spezialisierten Dictionaries (z.B. einem Ausschieß-Dictionary), und
(4) Ein grafischer Zustandsstapel, in dem Grafikdaten wie zum Beispiel die Parameter des Demand-Druckers 84 gespeichert werden.

Die PostScript^®-Sprache ist geräteunabhängig, sodass die in der zusammengeführten PostScript^®-Datei 450 enthaltenen Seitenbeschreibungen in einem Koordinatensystem (namens "user space", Anwenderraum) festgelegt sind, das unabhängig von dem bestimmten Demand-Drucker 84 funktioniert. Das vom Demand-Drucker 84 verwendete Koordinatensystem (namens "device space", Geräteraum) ist je nach dem für die Wiedergabe der aktuellen Seite bestimmten Demand-Drucker 84 ("current device", aktuelles Gerät) unterschiedlich. Damit die in der zusammengeführten PostScript^®-Datei 450 beschriebenen Seiten wiedergegeben werden können, ist es möglich, die (im Anwenderraum festgelegten) Seitenbeschreibungen in den so genannten "current device space" (aktuellen Geräteraum) durch eine Current Transformation Matrix ([CTM]) zu transformieren.
Die PostScript^®-Sprache verwendet die Current Transformation Matrix ([CTM]) zur Beschreibung der Skalierung, der Drehung und der Übersetzung der Seite vom Anwenderraum zum Geräteraum. Zuweisung des Punkts (x, y) im Anwenderraum zum Punkt (x', y') im Geräteraum: [CTM] = [a b c d tx ty],wobei

x': = ax + cy + t_x
y': = bx + dy + t_y

_x

_y

Der RIP 82 erhält auch eine als "graphics state" (Grafikstatus) bezeichnete Datenstruktur aufrecht, in welchem verschiedene grafische Steuerparameter wie die [CTM] enthalten sind. Der Grafikstatus umfasst auch (i) einen Beschneidungspfad, welcher für die aktuelle Seite den Wiedergabebereich im Rasterspeicher 452 definiert, (ii) Definitionen von Schriftart und Linien, (iii) einen Farbbereich (wie beispielsweise DeviceGray, RGB, CMYK oder CIE), sowie (iv) andere Parameter der grafischen Steuerung.
Die PostScript^®-Sprache umfasst auch einige Operatoren für die Einrichtung des aktuellen Demand-Druckers 84 zur Erfüllung der Verarbeitungsvorgaben der in der zusammengeführten PostScript^®-Datei 450 enthaltenen Seitenbeschreibungen. Zur aktuellen Geräteeinrichtung zählt die Festlegung der Current Transformation Matrix ([CTM]) für den aktuellen Demand-Drucker 84. Die Standard-Umformung vom Anwenderraum zum Geräteraum für das aktuelle Gerät wird von einer Systemstandardmatrix ("system default matrix") festgelegt. Die Systemstandardmatrix kann durch die PostScript^®-Sprache beispielsweise über einen Operator defaultmatrix generiert werden.
Die [CTM] kann als Abänderung der Systemstandardmatrix betrachtet werden.
Sobald der aktuelle Demand-Drucker 84 eingerichtet ist, kann der RIP 82 mit der Interpretation der Seitenbeschreibungen in der zusammengeführten PostScript^®-Datei 450 beginnen. Nacheinander wird für jede Seite alles, was auf dieser Seite erscheinen soll (Text, grafische Elemente und Bilder) in den Rasterspeicher 452 "gemalt" und gespeichert und/oder vom Demand-Drucker 84 wiedergegeben.
In der zusammengeführten PostScript^®-Datei 450 ist in jeder Beschreibung einer wiederzugebenden Seite ein PostScript^®-Operator showpage enthalten. Der Operator showpage, welcher sich generell am Ende einer Seitenbeschreibung befindet, wird zur Übertragung der Rasterbeschreibung der (im Rasterspeicher 452 gespeicherten) aktuellen Seite an den Demand-Drucker 84 zur physischen Wiedergabe der aktuellen Seite verwendet. Im Allgemeinen überträgt der Operator showpage den Inhalt des Rasterspeichers 452 an den Demand-Drucker 84, löscht dann die aktuelle Seite aus dem Rasterspeicher 452 und führt einen partiellen Reset des Grafikstatus als Vorbereitung für die Interpretation der nächsten Seitenbeschreibung in der zusammengeführten PostScript^®-Datei 450 durch.
In PostScript^®-Implementierungen Level 2 wird die Funktion des Operators showpage durch eine Prozedur EndPage und eine Prozedur BeginPage gesteuert, welche dem aktuellen Demand-Drucker 84 entsprechend definiert sind. Allgemein legt die Prozedur EndPage die Disposition der aktuellen Seite im Rasterspeicher 452 fest, während die Prozedur Begin-Page den Beginn der nächsten zu interpretierenden Seitenbeschreibung einrichtet und kennzeichnet. Diese Prozeduren können beispielsweise durch einen Level 2 Operator setpagedevice definiert werden, der den Grafikstatus für den aktuellen Demand-Drucker 84 einrichtet ("aktueller Grafikstatus").
Während des Normalbetriebs liefert ein Level 2 Operator showpage der Prozedur Endpage zwei Operanden: einen Ursachencode (reason code) sowie Pagecount. Der Operand reason code legt fest, ob die Prozedur EndPage vom Operator showpage, von einem Operator copypage oder während der Deaktivierung eines Geräts aufgerufen wird. Bei Aufruf der Prozedur Endpage durch den Operator showpage wird der Ursachen-Operand auf 0 gesetzt. Beim Operand Pagecount handelt es sich um die Anzahl der Durchführungen des Operators showpage, welche seit der Aktivierung des aktuellen Geräts eingetreten sind, ausschließlich der aktuellen Ausführung. Daher entspricht Pagecount der Anzahl von Seiten, welche vor der aktuellen Seite dargestellt wurden. Nach Ausführung der Prozedur EndPage wird Pagecount um eins erhöht und als Operand der Prozedur BeginPage zur Verfügung gestellt.
Die Operation des Level 2 Operators showpage ist im Flussdiagramm von 20 dargestellt. Ein Block 500 setzt zunächst den Operanden reason code gleich Null, um festzulegen, dass vom Operator showpage die Prozedur EndPage aufgerufen wird. Ein Block 502 ruft dann die Prozedur EndPage auf, die die Operanden reason code und PageCount verarbeitet und ein Boolesches Ergebnis ausgibt, welches die Disposition der aktuellen Seite im Rasterspeicher 452 festlegt. Im Normalbetrieb gibt die Prozedur EndPage bei der Ausführung der Operatoren showpage oder copypage True zurück (veranlasst damit die Herstellung einer physischen Seite), während die Deaktivierung eines Geräts jedoch False zurückgibt. Ein Entscheidungsblock 504 prüft, ob das von der Prozedur EndPage zurückgegebene Ergebnis True oder False ist.
Falls die Prozedur EndPage als Ergebnis "True" zurückgibt, übermittelt ein Block 506 den Inhalt des Rasterspeichers 452 an den Demand-Drucker 84 zur Wiedergabe. Ein Block 508 leert dann den Rasterspeichers 452 durch Ausführung einer Prozedur, welche einem PostScript^®-Operator erasepage ähnlich ist. Im Normalbetrieb gibt die Prozedur EndPage "True" zurück, wenn sie vom Operator showpage oder copypage aufgerufen wird. Auf diese Weise veranlassen die Operatoren showpage und copypage, dass der Inhalt des Rasterspeichers 452 an den Demand-Drucker 84 zur Wiedergabe übertragen wird.
Falls die Prozedur EndPage "Falle" zurückgibt, führt der Operator showpage keine der Funktionen der Blocks 506 und 508 aus (d.h., es wird keine Seite wiedergegeben), sondern springt zu einem Block 510. Der Block 510 führt eine Prozedur ähnlich einem PostScript^®-Operator initgraphics aus, welche die [CTM], den Beschneidungspfad und die anderen Grafikparameter auf die Standardwerte des aktuellen Demand-Druckers 84 zurücksetzt und damit den Grafikstatus für die Zusammenstellung der nächsten Seite einrichtet. Der Beschneidungspfad definiert den in Rasterspeicher 452 gespeicherten Wiedergabebereich der aktuellen Seite.
Ein Block 512 erhöht dann den Operanden Pagecount um 1, während ein Block 514 die Prozedur BeginPage mit Pagecount als Operand aufruft. Die Prozedur BeginPage kennzeichnet den Beginn der nächsten Seite in der zusammengeführten PostScript^®-Datei 450, welche vom RIP 82 interpretiert werden soll.
Die Standardoperation des in 2 dargestellten Level 2 Operators lässt sich durch folgenden PostScript^®-Pseudocode darstellen:
Die Verfahren zum Ausschießen im laufenden Betrieb (Imposition-On-The-Fly)
Die Verfahren der vorliegenden Erfindungen zum Ausschießen im laufenden Betrieb erstellen einen Layer über den Demand-Drucker, der als "virtuelles Gerät" (virtual device) bezeichnet wird. Die gewünschte Position (Skalierung, Ausrichtung und Größe) einer vom Demand-Drucker zu druckenden Seite wird von einer Prozedur (namens "setvirtualdevice") spezifiziert, welche das virtuelle Gerät für die betreffende Seite festlegt. Daher ist die [CTM] aus Sicht des PostScript^®-Programms dasselbe wie die Systemstandardmatrix, und jedes Seite beginnt mit einer [CTM], welche die Koordinaten des Anwenderraums an der linken unteren Ecke des Ausgabegerätes ausrichtet. Die [CTM] kann ausdrücklich manipuliert werden, als wäre jede PostScript^®-Seite auf einer eigenen, jedoch identischen physischen Seite abgebildet.
Daher wird beim Ausschießen und bei der Wiedergabe einer ausgewählten Seite aus der zusammengeführten PostScript^®-Datei 450 das aktuelle Ausgabegerät (d.h. der Demand-Drucker 84) als das virtuelle Gerät definiert. Allgemein ist das virtuelle Gerät für eine ausgewählte Seite von derselben Größe wie die Seite und wird an jener Stelle auf der Blattseite 456 positioniert, an welcher die Seite wiedergegeben werden soll.
Das virtuelle Gerät wird eingerichtet, indem die aktuelle Transformationsmatrix (Current Transformation Matrix) ([CTM]) so eingestellt wird, dass sie die Seite ordnungsgemäß positioniert. Um den Rand der Seite wird dann ein Beschneidungspfad erstellt, der den Wiedergabebereich im Rasterspeicher 452 definiert. Auf diese Weise "sieht" der RIP 82 die Position, an der die Seite wiederzugeben ist, als aktuelles Ausgabegerät.
Für jene Seiten in der zusammengeführten PostScript^®-Datei 450, welche nicht auf der aktuellen Blattseite 456 wiedergegeben werden (d.h., nicht im aktuellen Druckerzeugnis enthalten sind), wird das aktuelle Ausgabegerät (der Demand-Drucker 84) als verkleinertes virtuelles Gerät für die nächste auf der Blattseite auszuschießende und wiederzugebende Seite definiert. Das verkleinerte virtuelle Gerät lässt zu, dass dazwischen liegende Seiten, welche nicht auf die Blattseite ausgeschossen werden sollen, vom RIP 82 schnell interpretiert werden.
Zu den Prozeduren für das Ausschießen im laufenden Betrieb zählt die Prozedur setvirtualdevice, welche das virtuelle Gerät für die nächste auf der Blattseite 456 wiederzugebende Seite festlegt, sowie eine Prozedur EnableVirtualDevice, mit der der Operator showpage zur Unterstützung virtueller Geräte eingerichtet wird. Ebenso werden die vom Operator showpage aufgerufenen Prozeduren EndPage und BeginPage umdefiniert. Diese Prozeduren sind weiter unten im Detail beschrieben.
Der Befehlssatz für das Ausschießen im laufenden Betrieb:
Vorzugsweise wird der Befehlssatz zur Implementierung des Ausschießens im laufenden Betrieb durch Erstellung des virtuellen Geräts für die auf der Blattseite wiederzugebenden Seiten in den RIP 82 im unten beschriebenen Format eingegeben. Die vorliegende Erfindung kann jedoch geändert werden, um das Ausschießen verschiedener Befehlssatzformate zu erlauben.
Der Befehlssatz für das Ausschießen im laufenden Betrieb enthält den/die Namen der zusammengeführten PostScript^®-Datei(en) 450, welche von RIP 82 interpretiert und vom Demand-Drucker wiedergegeben werden. Diese Dateinamen stehen mit (in Arrays gespeicherten) Eintragslisten in Verbindung, welche einen oder mehrere Einträge enthalten, wobei in jedem Eintrag folgende Angaben enthalten sind:

1) Eine erste Prozedur user – Die Prozedur user kann verschiedene Anweisungen, insbesondere Kommentare, Druckzeichen (wie Barcodes oder Wasserzeichen) oder andere Informationen enthalten. (Die Prozedur user kann auch 0 sein und ist für die Prozeduren des Ausschießens im laufenden Betrieb der vorliegenden Erfindung nicht zwingend erforderlich.)
2) Eine Seitenzahl – Die Seitenzahl ist die fortlaufende Nummer der Seitenbeschreibung in der zusammengeführten PostScript^®-Datei 450 der auf Blattseite 456 wiederzugebenden Seite. Es wird davon ausgegangen, dass die zusammengeführte PostScript^®-Datei 450 Seitenbeschreibungen in fortlaufender Reihenfolge enthält, wobei die erste Seitenbeschreibung die Seite "0" ist.
3) Operanden der Prozedur setvirtualdevice – Wie weiter unten im Detail ausgeführt, legt die Prozedur setvirtualdevice das entsprechende virtuelle Gerät als aktuelles Ausgabegerät für eine bestimmte Seite fest. Die Prozedur setvirtualdevice erfordert die folgenden drei Operanden, welche in jedem Eintrag der Eintragsliste enthalten sind:
i) Skalierungs-, Übersetzungs- und Drehungsfaktoren, die zur Generierung einer "virtuellen [CTM]" verwendet werden, welche die ausgewählte Seite ordnungsgemäß auf der Blattseite 456 positioniert. Diese Faktoren sind wie folgt aufgelistet: [scale_x scale_y translate_x translate_y rotate];
ii) Die Koordinaten des Anwenderraums in der linken unteren und der rechten oberen Ecke des tatsächlichen Wiedergabebereichs der nächsten Seite, welche auf der Blattseite 456 wiedergegeben werden soll. Diese Eck-Koordinaten werden zur Generierung eines Beschneidungspfads um den Rand der Seite im Rasterspeicher 452 verwendet. Die Eck-Koordinaten sind wie folgt aufgelistet: [Clip11X Clip11Y ClipurX ClipurY], sowie
iii) Größe (Breite und Länge) der auf der Blattseite wiederzugebenden Seite. Die Seitengröße ist wie folgt aufgeführt: [PageX PageY]. (Die Seitengröße entspricht nicht notwendigerweise dem Beschneidungspfad, der den Wiedergabebereich der Seite begrenzt, da viele Demand-Drucker nicht in der Lage sind, Markierungen an den äußersten Rändern einer Seite anzubringen).
4) Eine zweite Prozedur user ("Offsets"): Wie die erste Prozedur user kann auch die zweite Prozedur user Kommentare, Druckzeichen (Barcodes, Wasserzeichen usw.) oder andere Informationen enthalten oder aber 0 sein. In einem Ausführungsbeispiel für die erste Blattseite wird jedoch die zweite Prozedur user für den Versatz ("Offset") des Programms zur nächsten auf der Blattseite wiederzugebenden Seite verwendet.

So enthält beispielsweise die zusammengeführte PostScript^®-Datei allgemein zahlreiche Seiten, da sie für jede einzelne variable Seite separate Seitenbeschreibungen umfasst. Gehen wir von einem einfachen 4-seitigen Druckerzeugnis mit drei Hauptseiten und nur einer variablen Seite aus. Das Druckerzeugnis wird unter Umständen an 1000 verschiedene Personen mit variabler Information für jede einzelne Person versandt. Die zusammengeführte PostScript^®-Datei enthält daher 1.003 Seitenbeschreibungen: 3 Hauptseiten und 1.000 variable Seiten. Das Ausschießen im laufenden Betrieb mit Offsets ermöglicht den schnellen Druck der Druckerzeugnisse, da es die 999 variablen Seiten, die nicht in jedem einzelnen Druckerzeugnis enthalten sind, "überspringt" (d.h., sie nicht mit dem RIP verarbeitet).
Für das Ausschießen im laufenden Betrieb mit Offsets enthält die zweite Prozedur user für den ersten Eintrag im Befehlssatz ein Dateiobjekt, eine Offsetposition sowie den PostScript^®-Operator setfileposition. Die Offsetposition zeigt auf die nächste Seitenbeschreibung in der Datei, welche auf der Blattseite enthalten sein soll. (Die Offsetpositionen wurden vom Block 364 in 13 berechnet und gespeichert.) Der Operator setfileposition positioniert die aktuelle zusammengeführte PostScript^®-Datei 450 in diese Offsetposition um.
Daher sieht das PostScript^®-Befehlssatzformat für das Ausschießen im laufenden Betrieb der vorliegenden Erfindung wie folgt aus:
Ein Beispiel eines Ausschießvorgangs im laufenden Betrieb mit einem Offset-Befehlssatz ist als Anhang I beigelegt. Der Befehlssatz in Anhang I umfasst auch Code in bestimmten zweiten Prozeduren user zum Druck eines Barcodes.
Erläuterung der Variablen:
Die in Verfahren zum Ausschießen im laufenden Betrieb verwendeten Variablen lassen sich problemlos definieren und in einem (beispielsweise als "impositiondict" bezeichneten) Anwender-Dictionary speichern. Zu diesen Variablen zählen:

1) PageOffset – Die kumulative Anzahl von Seiten aus früheren PostScript^®-Dateien, die entsprechend dem Verfahren der vorliegenden Erfindung zum Ausschießen im laufenden Betrieb interpretiert wurden. Zunächst ist PageOffset auf -1 gesetzt (keine früheren Dateien (oder Seiten) wurden interpretiert).
2) CurrentPage – Die Seitenzahl der nächsten Seite in der aktuellen zusammengeführten PostScript^®-Datei 450, welche auf der aktuellen Blattseite 456 wiederzugeben ist. CurrentPage ist anfänglich auf 0 eingestellt.
3) Last Page – Die Seiternzahl der letzten Seite in der aktuellen zusammengeführten PostScript^®-Datei 450, welche auf der aktuellen Blattseite wiederzugeben ist und welche der Seitenzahl im letzten Eintrag der Eintragsliste entspricht. LastPage ist zunächst auf 1 gesetzt und wird dazu verwendet, um zu ermitteln, wie viele Seitenbeschreibungen in der zusammengeführten PostScript^®-Datei zu interpretieren sind, damit alle ausgewählten Seiten auf der aktuellen Blattseite ordnungsgemäß wiedergegeben werden.
4) PageCount – Die Anzahl der Ausführungen des Operators showpage (anfangs 0). In PostScript^®-Implementierungen Level 2 wird PageCount intern von RIP 82 durch den Operator showpage gespeichert und erhöht.

In PostScript^®-Implementierungen Level 1 muss jedoch die Variable PageCount ausdrücklich definiert und erhöht werden, um die Operation des Operators showpage auf Level 2 zu emulieren.

5) PageList – Die Liste der in der Eintragsliste enthaltenen Einträge (Seitenzahlen und Ausschießverfahren).
6) CurrentIndex – Ein Index in die PageList
7) LastIndex – Die Anzahl der Einträge in der Eintragsliste.
8) DefaultMatrix – Wird zur Speicherung des Wertes der [CTM] verwendet, welche das virtuelle Gerät ("virtuelle [CTM]") beschreibt. Die Skalierungs-, Übersetzungs- und Drehungs-Bausteine der virtuellen [CTM] werden der Prozedur setvirtualdevice als Operanden geliefert.
9) PageX und PageY – Die Breite bzw. Höhe der auf Blattseite 456 wiederzugebenden Seite. Die Werte von PageX und PageY werden in jedem Eintrag der Eintragsliste der Prozedur setvirtualdevice als Operanden geliefert.
10) DefaultPageX und DefaultPageY – Die Standardwerte der Seitenbreite bzw. Seitenhöhe. Diese Werte sind anfänglich auf 8 1/2'' (612) bzw. 11'' (792) eingestellt.
11) Clip11X, Clip11Y, ClipurX und ClipurY – Die Koordinaten der linken unteren bzw. der rechten oberen Ecke des Anwenderraums des Beschneidungspfads, der die Ränder des virtuellen Geräts definiert. Die Werte diese Variablen sind auch in den Operanden für die Prozedur setvirtualdevice enthalten.
12) Portrait – Eine Boolesche Variable, welche zur Beschreibung der Ausrichtung der aktuellen Seite (Hochformat) verwendet wird. Falls Portrait auf True gesetzt ist, befindet sich die aktuelle Seite im Hochformat (Seitenbreite < Seitenhöhe). Falls Portrait auf Falle gesetzt ist, befindet sich die aktuelle Seite im Querformat (Seitenbreite > Seitenhöhe).
13) DefaultPortrait – Der Standardwert für die Seitenausrichtung; er ist anfänglich auf True (Hochformat) gesetzt.
14) VirtualDeviceEnabled – Ene Boolesche Variable, mit der untersucht wird, ob eine beispielsweise mit "EnableVirtualDevice" bezeichnete Prozedur durchgeführt wurde. Wie unten im Detail erläutert, richtet die Prozedur EnableVirtualDevice den PostScript^®-Standardoperator showpage so ein, dass er virtuelle Geräte unterstützt.
15) ImageDone – Eine Boolesche Variable, mit der festgelegt wird, warm die aktuelle Blattseite 456 fertig gestellt ist. ImageDone ist anfänglich und normalerweise auf Falle gesetzt und zeigt damit an, dass die aktuelle Blattseite 456 nicht fertig gestellt wurde.

Eine weitere Beschreibung der verwendeten Variablen ist im folgenden PostScript^®-Code enthalten, der das Dictionary impositiondict erstellt und die Variablen initiiert:
Die umdefinierten PostScript^®-Operatoren:
Vor der Durchführung von Verfahren der vorliegenden Erfindung zum Ausschießen im laufenden Betrieb müssen auch einige PostScript^®-Operatoren für die Kompatibilität mit den Prozeduren EnableVirtualDevice und setvirtualdevice, welche weiter unten in größerem Detail beschrieben sind, umdefiniert werden. Das virtuelle Gerät schirmt das PostScript^®-Programm und den RIP durch die [CTM] von dem Ort ab, von dem aus die Seiten in den Rasterspeicher 452 "eingemalt" werden. Auf diese Weise müssen generell die PostScript^®-Operatoren, welche die [CTM] beeinflussen, ebenfalls umdefiniert werden, damit auch sie das PostScript^®-Programm und den RIP vor der endgültigen Zuweisung der Seitenbeschreibung von den Koordinaten des Anwenderraums zu den Koordinaten des Geräteraums abschirmen. Unter anderen müssen folgende PostScript^®-Operatoren umdefiniert werden:

initmatrix transform

initclip itransform

setmatrix dtransform

currentmatrix idtransform

erasepage nulldevice

initgraphics copypage
Die Standardoperation dieser und sämtlicher anderer PostScript^®-Operatoren ist im Handbuch PostScript^® Language Reference Manual, Second Edition (1990) von Adobe Systems, Inc., welches bereits weiter oben zum Bestandteil dieses Dokuments deklariert wurde, näher beschrieben.
Der erste Schritt bei der Umdefinition der oben aufgeführten PostScript^®-Operatoren besteht in der Umbenennung des Standardoperators, beispielsweise zu "systemdict_operator", da seine Definition im Dictionary systemdict gespeichert ist. Dies kann durch folgenden Code ausgeführt werden:
Wie weiter unten erläutert, werden die Standardoperatoren nulldevice und copypage nicht umdefiniert, da ihre Standardoperation in Verbindung mit der vorliegenden Erfindung nie zum Einsatz kommt. Die Umdefinitionen der unten beschriebenen Operatoren werden dann in das Dictionary userdict geladen.
Der umdefinierte Operator initmatrix:
Der PostScript^®-Standardoperator inimatrix setzt die [CTM] als Systemstandardmatrix für das aktuelle Gerät ein. Der Operator initmatrix wird umdefiniert, um die [CTM] der virtuellen [CTM], welche das virtuelle Gerät definiert, gleichzusetzen. Die virtuelle [CTM] kann in der variablen DefaultMatrix gespeichert werden.
Der PostScript^®-Operator initmatrix kann mittels des folgenden Codes umdefiniert werden:
Der umdefinierte Operator initclip:
Der Standard-Beschneidungspfad entspricht der Begrenzung des maximalen Bilddarstellungsbereichs des aktuellen Ausgabegeräts (Demand-Drucker 84). Der PostScript^®-Standardoperator initclip ersetzt den aktuellen Beschneidungspfad im Grafikstatus durch den Standard-Beschneidungspfad des aktuellen Demand-Druckers. Der Operator initclip wird umdefiniert, um den aktuellen Beschneidungspfad im Grafikstatus durch einen Beschneidungspfad zu ersetzen, welcher den Rand der virtuellen Geräteseite definiert.
Das Flussdiagramm in 21 stellt die vom umdefinierten Operator initclip implementierten Programmschritte dar. Ein Entscheidungsblock 520 ermittelt durch Überprüfung des Vorhandenseins eines currentpoint, ob ein aktueller Pfad existiert. Falls kein currentpoint definiert ist, speichert ein Block 522 einen leeren Pfad in einer Variablen, welche beispielsweise "p1" genannt wird. Alternativ, falls ein currentpoint definiert ist, ruft ein Block 524 eine vorher festgelegte Hilfsroutine auf, welche beispielsweise den Namen "MakePath" erhalten hat und die aus dem aktuellen Pfad eine Pfadbeschreibung erstellt. Der Block 524 speichert dann die aktuelle Pfadbeschreibung in der variablen p1. Die Prozedur MakePath, welche im Dictionary impositiondict gespeichert werden kann, ist dem Level 2 PostScript^®-Operator upath ähnlich und lässt sich mittels folgenden Codes implementieren:
Als nächsten Schritt speichert ein Block 526 die aktuelle [CTM], während ein Block 528 die [CTM] auf die virtuelle [CTM] setzt. Ein Block 530 erstellt dann einen Beschneidungspfad zwischen den Ecken des virtuellen Geräts, welche durch die Werte der der Prozedur setvirtualdevice als Operanden gelieferten Variablen Clip11X, Clip11Y, ClipurX und ClipurY definiert wurden. Ein Block 532 stellt dann die von Block 526 gespeicherte [CTM] und den in der Variablen p1 gespeicherten aktuellen Pfad wieder her.
Der PostScript^®-Operator initclip kann mittels des folgenden Codes umdefiniert werden:
Der umdefinierte Operator setmatrix:
Der PostScript^®-Standardoperator setmatrix ersetzte die aktuelle [CTM] im Grafikstatus durch eine auf den Operandenstapel gelieferte Matrix. Die auf den Operandenstapel gelieferte Matrix ("Operandenmatrix") kann als Ergebnis der Verkettung der Systemstandardmatrix mit einer Operationsmatrix betrachtet werden.
Der Operator setmatrix wird zur Berechnung der Operationsmatrix durch Verkettung der Operandenmatrix mit dem Kehrwert der Systemstandardmatrix umdefiniert.
Der PostScript^®-Operator setmatrix kann mittels des folgenden Codes umdefiniert werden:
Der umdefinierte Operator currentmatrix:
Der Standardoperator currentmatrix ersetzt die auf den Operandenstapel gelieferte Matrix durch die aktuelle [CTM] im Grafikstatus.
Die aktuelle [CTM] kann als das Ergebnis der Verkettung der (in DefaultMatrix gespeicherten) virtuellen [CTM] mit einer Operationsmatrix betrachtet werden. Der umdefinierte Operator currentmatrix berechnet die Operationsmatrix durch Verkettung der aktuellen [CTM] mit dem Kehrwert der virtuellen [CTM], wie unten ausgeführt:
[aktuelle CTM] = [Operationsmatrix] [virtuelle CTM], und
[Operationsmatrix] = [aktuelle CTM] [virtuelle CTM]^-1.
Die [Operationsmatrix] wird dann mit der Systemstandardmatrix verkettet; die sich daraus ergebende Matrix wird in der Matrix auf dem Operandenstapel gespeichert.
Der PostScript^®-Operator currentmatrix kann mittels des folgenden Codes umdefiniert werden:
Der umdefinierte Operator erasepage:
Der Standardoperator erasepage löscht die im Rasterspeicher gespeicherte gesamte aktuelle Seite, indem er sie weiß einfärbt. Der Operator erasepage wird umdefiniert, damit er nur die virtuelle Geräteseite löscht; dies ist der von der nächsten auf der aktuellen Blattseite darzustellenden Seite begrenzte Bereich.
Der Operator erasepage wird durch Aufruf des oben beschriebenen umdefinierten Operators initclip umdefiniert, welcher einen Beschneidungspfad um den Rand der virtuellen Geräteseite festlegt. Der Bereich innerhalb des Beschneidungspfads wird dann weiß eingefärbt. Der PostScript^®-Standardoperator gsave (im Detail in Verbindung mit den optionalen Verfahren der Erfindung für das Ausschießen im laufenden Betrieb beschrieben) wird unmittelbar vor dem umdefinierten Operator initclip aufgerufen, um den aktuellen Grafikstatus, insbesondere den aktuellen Beschneidungspfad, den Grauton usw. zu speichern. Auch wird, nachdem die virtuelle Geräteseite weiß eingefärbt wurde, der (ebenfalls im Detail in Verbindung mit den optionalen Prozeduren beschriebene) PostScript^®-Standardoperator grestore aufgerufen, um den aktuellen Grafikstatus wiederherzustellen.
Der PostScript^®-Operator erasepage kann mittels des folgenden Codes umdefiniert werden:
(In den optionalen Verfahren zum Ausschießen im laufenden Betrieb werden die PostScript^®-Standardoperatoren gsave und grestore umdefiniert. Daher wird in den optionalen Prozeduren der Operator erasepage durch Aufruf der Operatoren systemdict_gsave und systemdict_grestore umdefiniert, wie oben spezifiziert.)
Der umdefinierte Operator initgraphics:
Der PostScript^®-Standardoperator initgraphics setzt mehrere Werte im Grafikstatus, insbesondere die [CTM], den aktuellen Pfad und den Beschneidungspfad, auf ihre Standardwerte zurück. Der Standardoperator initgraphics entspricht der folgenden PostScript^®-Sprachsequenz:
Zur Ausführung der oben aufgeführten Sequenz wird der Operator initgraphics umdefiniert. Der umdefinierte Operator initgraphics ruft jedoch die umdefinierten Operatoren initmatrix und initclip auf, welche oben beschrieben sind.
Auf diese Weise setzt der umdefinierte Operator initgraphics die [CTM] und den Beschneidungspfad in ihre Standardwerte für das virtuelle Gerät zurück.
Der PostScript^®-Operator initgraphics kann mittels des folgenden Codes umdefiniert werden:
Die umdefinierten "transform" Operatoren:
Der PostScript^®-Standardoperator transform wandelt eine gelieferte Anwenderraumkoordinate (x,y) in die entsprechenden Geräteraumkoordinate (x',y') um, wie in der [CTM] festgelegt. Da sich die [CTM] während des Ausschießvorgangs verändert, wird der Operator transform umdefiniert, um die Wandlung so vorzunehmen, als wäre die [CTM] nicht verändert worden.
Wird dem Standardoperator transform ein Matrixoperand geliefert, dann erfolgt die Umwandlung vom Anwenderraum zum Geräteraum entsprechend der gelieferten Matrix. Bei Lieferung eines Matrixoperanden wird daher auch der Operator transform umdefiniert, damit er die Umwandlung entsprechend der gelieferten Matrix vornimmt.
In der PostScript^®-Sprache existieren drei weitere Operatoren "transform" (dtransform, itransform und idtransform), welche auf dieselbe Art wie der Operator transform umdefiniert werden.
Der PostScript^®-Standardoperator dtransform spezifiziert eine "Distanz"-Umwandlung einer Koordinate vom Anwenderraum zum Geräteraum entsprechend der [CTM] oder entsprechend einem gelieferten Matrixoperanden. In einer Distanzumwandlung werden die Übersetzungskomponenten (t_x und t_y) der [CTM] nicht verwendet.
Der PostScript^®-Standardoperator itransform spezifiziert eine Umwandlung einer Koordinate im Geräteraum (x',y') zum Anwenderraum (x,y) entsprechend dem Kehrwert der [CTM] oder eines gelieferten Matrixoperanden. Der Standardoperator idtransform spezifiziert eine Distanzumwandlung von Geräteraum zum Anwenderraum entsprechend dem Kehrwert von [CTM] oder eines gelieferten Matrixoperanden.
22 stellt die vom umdefinierten Operator transform implementierten Programmschritte dar. Die anderen transform Operatoren werden auf dieselbe Art umdefiniert. Zunächst prüft ein Entscheidungsblock 534, ob dem Operator transform ein Matrixoperand geliefert wurde. Falls ein Matrixoperand geliefert wurde, ruft ein Block 536 einfach den Standardoperator transform (jetzt umbenannt in "systemdict_transform") auf, damit er die Umwandlung entsprechend der gelieferten Matrix durchführt. (Für die anderen transform Operatoren ruft der Block 536 systemdict_d transform, systemdict_itransform oder systemdict_idtransform auf.)
Alternativ, falls Block 534 feststellt, dass kein Matrixoperand geliefert wurde, speichert ein Block 538 zuerst eine Kopie der aktuellen [CTM] im Grafikstatus auf dem Operandenstapel.
Wie oben erläutert, kann die aktuelle [CTM] als Ergebnis der Verkettung der (in DefaultMatrix gespeicherten) virtuellen [CTM] mit einer Operationsmatrix betrachtet werden. So berechnet ein Block 540 die Operationsmatrix durch Verkettung der aktuellen [CTM] mit dem Kehrwert der virtuellen [CTM].
Im nächsten Schritt setzt ein Block 542 eine neue [CTM] gleich der mit der Systemstandardmatrix verketteten Operationsmatrix. Die neue [CTM] entspricht nun dem Wert, den die [CTM] gehabt hätte, wenn setvirtualdevice und die Ausschießverfahren nicht implementiert worden wären.
Anschließend ruft ein Block 544 den Standardoperator transform zur Durchführung der Umwandlung von Anwenderraum zu Geräteraum entsprechend der neuen [CTM] auf. (Auch hier wiederum ruft der Block 544 für die anderen transform Operatoren die Standardoperatoren dtransform, itransform, oder idtransform auf.)
Schließlich setzt ein Block 546 die [CTM] der auf dem Operandenstapel durch den Block 538 gespeicherten aktuellen [CTM] gleich.
Der PostScript^® transform Operatoren können mittels des folgenden Codes umdefiniert werden:
Der umdefinierte Operator nulldevice:
Der PostScript^®-Standardoperator nulldevice installiert "null device" als aktuelles Ausgabegerät. Der PostScript^®-Standardoperator nulldevice erzeugt keine physische Ausgabe und hat keinen ihm zugewiesenen Rasterspeicher. Alle alle ausgeführten Grafik-oder Schriftartoperationen werden jedoch im aktuellen Grafikstatus gespeichert. Der PostScript^®-Operator nulldevice setzt auch die [CTM] auf eine Identitätsmatrix ([100100]) und legt den Beschneidungspfad als einen einzigen Punkt am Ausgang fest.
Für die Verwendung mit dieser Erfindung ist der PostScript^®-Standardoperator nulldevice jedoch nicht geeignet, da er kein Seitengerätoperator ist und daher über keine ihm zugewiesenen Prozeduren EndPage und BeginPage verfügt. Daher wird der Operator umdefiniert, damit er die [CTM] auf die Identitätsmatrix setzt und einen Einpunkt-Beschneidungspfad einrichtet, ohne das Gerät der aktuellen Seite zu verändern.
Der PostScript^®-Operator nulldevice kann mittels des folgenden Codes umdefiniert werden:
Der umdefinierte Operator copypage:
Im normalen Betrieb überträgt der PostScript^®-Standardoperator copypage eine Kopie der aktuellen Seite an den Demand-Drucker, ohne die aktuelle Seite zu löschen oder den Grafikstatus zu verändern. Wie beim Operator showpage hängt die Operation des Operators copypage von den Prozeduren EndPage und BeginPage ab, welche durch die vorliegende Erfindung umdefiniert werden. In der vorliegenden Erfindung werden die Prozeduren End-Page und BeginPage umdefiniert, so dass der Operator copypage keine Wirkung hat. Die Prozeduren EndPage und BeginPage könnten so umdefiniert werden, dass sie den Operator copypage suchen (indem sie den reason code mit 1 vergleichen). Alternativ kann die Operation des Operators copypage durch folgenden Code einfach auf null gesetzt werden:
/copypage {} def
Die Prozedur EnableVirtualDevice:
Die von der Prozedur ImposeJob am Ende des Befehlssatzes aufgerufene Prozedur EnableVirtualDevice richtet den Operator showpage so ein, dass er virtuelle Geräte unterstützt. 23 ist ein Flussdiagramm, in welchem die von der Prozedur EnableVirtualDevice implementierten Programmschritte dargestellt sind. Zunächst prüft ein Block 550, ob der RIP 82 PostScript^® Level 1 oder Level 2 implementiert, indem er feststellt ob der PostScript^®-Operator setpagedevice im Dictionary systemdict definiert ist. Falls der RIP 82 die PostScript^®-Sprache Level 2 implementiert, lädt ein Block 552 durch Aufruf des Operators setpagedevice die umdefinierten Prozeduren EndPage und BeginPage in den aktuellen Grafikstatus für den Demand-Drucker 84. Wie weiter unten in größerem Detail ausgeführt, werden die Prozeduren EndPage und BeginPage umdefiniert, um das aktuelle Ausgabegerät als virtuelles Gerät für die darzustellenden Seiten, oder als verkleinertes virtuelles Gerät für nicht dargestellte Seiten, zu definieren.
Die Blocks 550 und 552 der Prozedur EnableVirtualDevice können mithilfe des folgenden Codes implementiert werden:
Alternativ, wenn der Block 550 feststellt, dass der RIP 82 PostScript^® Level 1 implementiert, wird der Level 1 Standardoperator showpage von einem Block 554 umbenannt, während ein Block 556 den Operator showpage umdefiniert, um die Operation des Level 2 Standardoperators showpage zu emulieren, wie in 20 dargestellt. Als nächsten Schritt führt ein Block 558 in der zusammengeführten PostScript^®-Datei die Prozedur BeginPage für die erste Seite (Seite "0") durch. (In der Level 2 Implementierung geschah dies automatisch, indem der Operator setpagedevice durch den Block 552 aufgerufen wurde).
Die Blocks 554-558 können durch folgenden Code implementiert werden:
Als nächsten Schritt ruft ein Block 560 eine (beispielsweise "DisablePageDevice" benannte) Prozedur auf, welche vorher im Dictionary impositiondict gespeichert war. Die Prozedur DisablePageDevice definiert den PostScript^®-Operator setpagedevice sowie alle anderen Kompatibilitätsoperatoren um, welche den Operator setpagedevice aufrufen. Durch die Deaktivierung dieser Operatoren wird gewährleistet, dass der Rasterspeicher 452 (der die Rasterbeschreibungen der vorher verarbeiteten Seiten enthalten kann, welche auf Blattseite 456 wiederzugeben sind) vom Operator setpagedevice nicht gelöscht wird. Die Prozedur DisablePageDevice ist unten in Verbindung mit 24 eingehender beschrieben.
Nachdem der Block 560 die oben beschriebene Prozedur DisablePageDevice aufgerufen hat, setzt ein Block 562 die "VirtualDeviceEnabled" benannte Boolesche Variable auf True, um damit anzuzeigen, dass die Prozedur abgeschlossen und der Operator showpage so eingestellt ist, dass er virtuelle Geräte unterstützt.
Die Blocks 560 und 562 der Prozedur EnableVirtualDevice können mithilfe des folgenden Codes implementiert werden:
Die Prozedur DisablePageDevice:
24 ist ein Flussdiagramm, in welchem die Programmschritte dargestellt sind, die von der durch den Block 560 der Prozedur EnableVirtualDevice aufgerufenen Prozedur DisablePageDevice implementiert werden. Da es sich bei setpagedevice um einen Level 2 Operator handelt, prüft ein Block 570, ob RIP 82 Level 1 oder Level 2 der PostScript^®-Sprache implementiert, indem er feststellt, ob der Operator setpagedevice im Dictionary systemdict definiert ist. Falls RIP 82 die PostScript^®-Sprache Level 2 implementiert, definieren Blocks 572-580 den Operator setpagedevice um, um bei Bedarf die Seitenausrichtung des Ausgabegerätes zu korrigieren.
Während der normalen Level 2 Operation wird dem PostScript^®-Operator setpagedevice ein Dictionary-Operand geliefert, welcher Einträge zur Eingabemedienauswahl enthält; der Operator setpagedevice legt das aktuelle Ausgabegerät entsprechend den im aktuellen Grafikstatus und im Dictionary-Operanden enthaltenen Informationen fest. Der Dictionary-Operand kann beispielsweise einen Eintrag für PageSize enthalten; es handelt sich dabei um eine Matrix von zwei Zahlen, welche Breite und Höhe der aktuellen Seite angeben. Daher kann ein Aufruf des Operators setpagedevice die Seitengröße verändern, was bei der Einrichtung des virtuellen Geräts von entscheidender Bedeutung ist.
Der Block 572 des umdefinierten Operators setpagedevice prüft zunächst, ob im Dictionary-Operanden für den Operator setpagedevice ein Eintrag für PageSize enthalten war. Falls ja, prüft anschließend Block 574, ob die im Eintrag spezifizierte PageSize im Hochformat oder im Querformat ist, indem er die Seitenbreite mit der im Eintrag PageSize angegebenen Seitenhöhe vergleicht. (Wie oben erläutert, wird für die Zwecke der Erfindung die Seitenausrichtung als Hochformat bezeichnet und die Variable Portrait auf True gesetzt, wenn die Seitenbreite kleiner als die Seitenhöhe ist. Ist die Seitenbreite größer als die Seitenhöhe, dann wird die Seitenausrichtung als Querformat bezeichnet und die Variable Portrait auf Falle gesetzt).
Anschließend vergleicht ein Block 576 die Seitenausrichtung des (von Block 574 ermittelten) Eintrags PageSize mit der Seitenausrichtung des (in der Variablen Portrait gespeicherten) virtuellen Geräts. Falls diese nicht gleich sind, ruft ein Block 578 eine beispielsweise "SetPortrait" benannte Prozedur auf, welche die Seitenausrichtung des virtuellen Geräts von Hochformat auf Querformat ändert oder umgekehrt. (Die Prozedur SetPortrait ist weiter unten eingehender beschrieben.) Im nächsten Schritt werden für die Durchgängigkeit mit der normalen Operation des Operators setpagedevice die umdefinierten Operatoren initgraphics und erasepage durch einen Block 580 aufgerufen. Alternativ, falls Block 576 feststellt, dass die Seitenausrichtung des Eintrags PageSize mit der des virtuellen Gerät gleich ist, oder falls Block 572 feststellt, dass im Dictionary-Operanden an den Operator setpagedevice der Eintrag PageSize nicht enthalten war, springt das Programm direkt zu Block 580, der die Umdefinierung des Operators setpagedevice abschließt.
Die Blocks 570-580 der Prozedur DisablePageDevice können mithilfe des folgenden Codes implementiert werden:
Nach Aufruf der umdefinierten Operatoren initgraphics und erasepage, oder falls Block 570 feststellt, dass der RIP 82 Level 1 PostScript^® implementiert, definiert ein Block 582 jene Kompatibilitätsoperatoren um, die entweder im Dictionary statusdict oder im Dictionary userdict definiert sind und welche den Operator setpagedevice aufrufen oder ähnliche Level 1 Operationen durchführen.
Bei Kompatibilitätsoperatoren, welche die Seitenausrichtung ändern, definiert Block 582 den Operator dergestalt um, dass die Seitenausrichtung des virtuellen Geräts der Ausrichtung der vom Operator spezifizierten Seite entspricht, und dass das virtuelle Gerät initialisiert wird. Diese Operatoren können durch eine beispielsweise "SetPageSize" benannte Hilfsroutine umdefiniert werden, welche den oben beschriebenen Blöcken 576-580 ähnlich ist. Die Routine SetPageSize kann durch folgenden Code implementiert werden:
Bei Kompatibilitätsoperatoren, die keine Auswirkungen auf die Seitenausrichtung haben, werden die Operatoren von Block 582 einfach deaktiviert oder auf null gesetzt. Der Block 582 der Prozedur DisablePageDevice, welche die Kompatibilitätsoperatoren umdefiniert oder deaktiviert, kann durch folgenden Code implementiert werden:
Die Prozedur SetPortrait:
Die Prozedur SetPortrait, welche von Block 578 der Prozedur DisablePageDevice aufgerufen wird, ändert die Seitenausrichtung des virtuellen Geräts von Hochformat auf Querformat oder umgekehrt. 25 stellt die von der Prozedur SetPortrait implementierten Programmschritte dar. Zunächst prüft ein Block 590, ob die Variable Portrait auf True gesetzt ist (und damit das Hochformat anzeigt), oder auf False (womit die Seite im Querformat ist).
Falls Portrait auf True ist, muss die Ausrichtung des Geräts von Hochformat auf Querformat umgestellt werden. Wie in 26A illustriert, wird eine Seite 592 im Hochformat in einem kartesischen Koordinatensystem mit einem Ausgangspunkt bei Punkt 0_P dargestellt. Die im Hochformat ausgerichtete Seite 592 hat eine Breite PageX und eine Höhe PageY. Der Wiedergabebereich auf Seite 592 wird durch einen Beschneidungspfad 594 begrenzt, der durch die Koordinaten seiner linken unteren Ecke (11x, 11y) und den Koordinaten seiner rechten oberen Ecke (urx, ury) definiert werden kann.
Die im Hochformat ausgerichtete Seite 592 wird in eine im Querformat ausgerichtete Seite 596 umgewandelt, indem der Ausgangspunkt O_P der Seite 592 in die positive x-Richtung umgesetzt und dann das Koordinatensystem 90 Grad gegen den Uhrzeigersinn gedreht wird, woraus sich ein im Querformat ausgerichtetes Koordinatensystem der Seite 596 mit einem Ausgangspunkt O_L ergibt. Obwohl die Geräteraumkoordinaten des Beschneidungspfads 594 unverändert sind, muss der Beschneidungspfad 594 in Bezug auf das neue Querformat-Koordinatensystem umdefiniert werden.
Zurück in 25, sobald Block 590 festgestellt hat, dass die Ausrichtung eines Geräts vom Hochformat zum Querformat umgewandelt werden muss, definiert ein Block 600 die Eckkoordinatenvariablen neu, wie folgt:

Koordinate Hochformat Koordinate Querformat

Clip11X Clip11Y

Clip11Y PageX – ClipurX

ClipurX ClipurY

ClipurY PageX – Clip11Y
Im nächsten Schritt erstellen die Blocks 602 und 604 Matrizen, die den Ausgangspunkt O_P um die Seitenbreite (PageX) in die positive x-Richtung verschieben und anschließend das Hochformat-Koordinatensystem um 90 Grad gegen den Uhrzeigersinn um den Ausgangspunkt O_P drehen. Anschließend verkettet ein Block 606 die Matrizen mit der aktuellen virtuellen [CTM] zur Erstellung der neuen virtuellen [CTM], welche das Gerät in der Ausrichtung Querformat spezifiziert.
Die Blocks 590 und 600-606 der Prozedur SetPortrait können mithilfe des folgenden Codes implementiert werden:
Wenn Block 590 feststellt, dass die Variable Portrait auf False ist, muss die Ausrichtung des Geräts von Querformat auf Hochformat umgewandelt werden. Wie in 26B dargestellt, wird eine Querformat-Seite 608 in einem kartesischen Koordinatensystem mit einem Ausgangspunkt O_L spezifiziert. Der wiedergegebene Bereich auf Seite 608 wird von einem Beschneidungspfad 610 begrenzt, welcher durch die Koordinaten seiner unteren linken und oberen rechten Ecke definiert wird. Die im Querformat ausgerichtete Seite 608 wird in eine im Hochformat ausgerichtete Seite 612 umgewandelt, indem der Ausgangspunkt O_L in die positive y-Richtung umgesetzt und dann das Koordinatensystem 90 Grad im Uhrzeigersinn um den Ausgangspunkt O_L gedreht wird. Dadurch wird ein im Hochformat ausgerichtetes Koordinatensystem mit einem Ausgangspunkt O_P erzeugt.
Ähnlich der oben beschriebenen Prozedur der Umwandlung von Hochformat zu Querformat definiert ein Block 614 zunächst die Eckkoordinaten des Beschneidungspfads um, wie folgt:

Koordinate Querformat Koordinate Hochformat

Clip11Y Clip11X

Clip11X PageY – ClipurY

ClipurY ClipurX

ClipurX PageY – Clip11Y
Im nächsten Schritt erstellen die Blöcke 616 und 618 Matrizen, die den Ausgangspunkt O_L in die positive y-Richtung verschieben und dann den Ausgangspunkt O_L um 90 Grad im Uhrzeigersinn drehen. Anschließend verkettet ein Block 620 die Matrizen mit der aktuellen virtuellen [CTM] zur Erstellung der neuen virtuellen [CTM], welche das Gerät in der Ausrichtung Hochformat spezifiziert.
Die Blocks 614-620 der Prozedur SetPortrait, welche die Ausrichtung von Querformat zu Hochformat umwandeln, können mithilfe des folgenden Codes implementiert werden:
Nachdem die Ecken des Beschneidungspfads umdefiniert sind und die neue virtuelle [CTM] erstellt ist, tauscht ein Block 622 die Werte von PageX und PageY aus. Wenn daher beispielsweise vom Hochformat in das Querformat umgewandelt wird, dann wird die Hochformat-Seitenbreite zur Querformat-Seitenhöhe, während die Hochformat-Seitenhöhe zur Querformat-Seitenbreite wird. Zuletzt ändert ein Block 624 den Wert der Variablen Portrait. Wenn daher Portrait ursprünglich auf True gesetzt war (und damit eine Ausrichtung im Hochformat anzeigt), wird es auf False gesetzt, um anzuzeigen, dass das Gerät nun im Querformat ausgerichtet ist. Umgekehrt, wenn Portrait ursprünglich auf False gesetzt war (und damit eine Ausrichtung im Querformat anzeigt), wird es auf True gesetzt, um anzuzeigen, dass das Gerät nun im Hochformat ausgerichtet ist.
Die Blocks 622-624 können durch folgenden Code implementiert werden:
Die oben beschriebene Prozedur SetPortrait stellt einen optionalen Teil der vorliegenden Erfindung dar und ist für den Einsatz mit PostScript^®-Anwendungen, welche die Seitenausrichtung nicht verändern, nicht erforderlich.
Die Prozedur setvirtualdevice:
Die Prozedur setvirtualdevice legt die aktuelle Umformungsmatrix ([CTM]), den Beschneidungspfad sowie die Seitengröße dergestalt fest, dass das aktuelle Ausgabegerät als virtuelles Gerät spezifiziert wird. Das virtuelle Gerät wird so definiert, dass seine Größe der Größe der nächsten wiederzugebenden Seite entspricht, wobei sich Ausgangspunkt und Seitenbegrenzung in jener Position auf Blatt 456 befinden, auf welcher die Seite wiedergegeben werden soll.
Die Prozedur setvirtualdevice erfordert die folgenden drei "Operanden", welche in der Befehlssatzliste enthalten sind:

1) Die Prozedur imposition, welche die Skalierungs-, Verschiebungs- und Drehungsfaktoren – [scale_x scale_y translate_x translate_y rotate] enthält,
2) Die Anwenderraum-Koordinaten der linken unteren und rechten oberen Ecke des Wiedergabebereichs der auszuschießenden Seite, welche zur Erstellung eines Beschneidungspfads um die Begrenzung der virtuellen Seite im Rasterspeicher 22 – [clip_ll_x clip_11_y clip_ur_x clip_ur_y] verwendet werden, sowie
3) Die Seitenbreite und Seitenlänge – [page_size_x page_size_y].

27 stellt die von der Prozedur setvirtualdevice implementierten Programmschritte dar. Ein Block 630 prüft zunächst, ob die Variable VirtualDeviceEnabled auf True gesetzt ist und damit anzeigt, dass die Prozedur EnableVirtualDevice ausgeführt wurde, und ob der Operator showpage so eingestellt ist, dass er virtuelle Geräte unterstützt. Falls der Block 630 feststellt, dass VirtualDeviceEnabled auf Falle gesetzt ist, ruft ein Block 633 die Prozedur EnableVirtualDevice auf. (Ein Block 633, der nur in Verbindung mit dem optionalen Prozeduren für das Ausschießen im laufenden Betrieb implementiert wird, ist unten beschrieben.
Im nächsten Schritt definiert ein Block 634 die Variablen PageX und PageY als Breite bzw. Höhe des virtuellen Geräts. Auf ähnliche Weise definiert ein Block 636 die Variablen Clip11X und Clip11Y als die x- und y-Koordinaten der linken unteren Ecke des virtuellen Geräts, und die Variablen ClipurX und ClipurY als die x- und y-Koordinaten der rechten oberen Ecke des virtuellen Geräts.
Ein Block 638 ruft dann den PostScript^®-Standardoperator initmatrix (umbenannt in "systemdict_initmatrix") auf, der die [CTM] auf die Systemstandardmatrix des aktuellen Ausgabegeräts setzt. Ein Block 640 führt dann die Skalierung-, Verschiebungs- und Drehungsoperatoren mit den Operanden der Prozedur setvirtualdevice aus. Diese Skalierung-, Verschiebungs- und Drehungsoperatoren verändern zur Spezifizierung der virtuellen [CTM] die Systemstandardmatrix. Ein Block 642 speichert die sich daraus ergebende virtuelle [CTM] in der Variablen DefaultMatrix. Die virtuelle [CTM] legt fest, dass sich der Ausgangspunkt des virtuellen Geräts an jener Position auf der Blattseite befindet, an welcher die nächste Seite auf der Blattseite 456 wiedergegeben werden soll.
Ein Entscheidungsblock 644 vergleicht dann die Seitenbreite (PageX) mit der Seitenhöhe (PageY). Erweist sich PageX geringer als PageY, dann setzt ein Block 646 die Variable Portrait auf True (und zeigt damit eine Seitenausrichtung im Hochformat an). Alternativ, falls PageX größer als PageY ist, setzt ein Block 648 die Variable Portrait auf False (und zeigt damit eine Seitenausrichtung im Querformat an).
Im nächsten Schritt ruft ein Block 650 den umdefinierten Operator initclip auf, damit der Beschneidungspfad um die Begrenzung der virtuellen Seite eingerichtet werden kann. (Siehe 21).
Die Prozedur setvirtualdevice kann durch folgenden Code implementiert werden:
Die Prozedur ImposeJob:
Die Prozedur ImposeJob wird aufgerufen, nachdem Referenzen auf die zusammengeführten PostScript^®-Dateien 450 und den Befehlssatz auf dem Operandenstapel abgelegt wurden. Darüber hinaus wurden die oben beschriebenen Prozeduren und Variablen in das Dictionary impositiondict geladen.
28 ist ein Flussdiagramm, in dem die von der Prozedur ImposeJob den Ausschießprozeduren im laufenden Betrieb der vorliegenden Erfindung entsprechend umgesetzten Programmschritte dargestellt sind.
Ein Block 652 ruft die oben in Verbindung mit 23 beschriebene Prozedur EnableVirtualDevice auf, um den Operator showpage zur Unterstützung virtueller Geräte einzurichten.
Anschließend ruft ein Block 654 das erste Dateien-/Listenpaar (welches den Namen der zusammengeführten PostScript^®-Datei und die entsprechende Eintragsliste mit den Prozeduren user, Seitenzahlen und Operanden der Prozeduren setvirtualdevice für die aktuelle Blattseite 456 enthält) aus dem Befehlssatz ab. Das Dateien-/Listenpaar wird in einer Matrix gespeichert, die vor dem Aufruf der Prozedur ImposeJob auf dem Operandenstapel abgelegt wurde.
Für jedes Dateien-/Listenpaar ruft ein Block 656 die unten beschriebene Prozedur ImposeFile auf, welche die einzelnen Einträge aus der Eintragsliste abruft und feststellt, welche der in der zusammengeführten PostScript^®-Datei 450 beschriebenen Seiten auf der Blattseite 456 wiederzugeben sind. Unter der Annahme, dass in der Matrix mehr als nur ein Datei-/Listenpaar vorhanden ist, werden die Blöcke 654 und 656 in einer Schleife ausgeführt, welche jedes Datei-/Listenpaar einzeln aus der Matrix abruft und die Prozedur ImposeFile aufruft, um jedes einzelne Datei-/Listenpaar zu verarbeiten.
Wenn alle Datei-/Listenpaare aus dem Befehlssatz durch die Prozedur ImposeFile verarbeitet wurden, setzt ein Block 658 die Boolesche Variable ImageDone auf True. ImageDone wird dazu verwendet, den RIP 82 anzuweisen, dass die Ausschießaufgabe abgeschlossen ist und die Blattseite 456 ausgeworfen werden kann. An diesem Punkt könnte der Wert von ImageDone von einer globalen Variablen bestimmt werden. ImageDone könnte auch in der Prozedur user im letzten Eintrag der letzten Befehlssatzliste auf True gesetzt werden.
Im nächsten Schritt prüft dann Block 660, ob der Operator showpage zur Emulation von Level 2 umdefiniert wurde. Falls ja, führt ein Block 662 den Level 1 Standardoperator showpage (umbenannt zu "systemdict_showpage") aus, um zur physischen Wiedergabe der Blattseite 456 den Inhalt des Rasterspeichers 52 an den Demand-Drucker 84 zu übertragen. In der Level 2 Implementierung wird die Blattseite vom Operator showpage automatisch wiedergegeben, sobald die umdefinierte Prozedur EndPage "True" zurückgibt. (Siehe 20). Falls der Operator showpage nicht umdefiniert wurde, wird das Programm von einem Block 664 beendet.
Die Blocks 652-662 der Prozedur ImposeJob können mithilfe des folgenden Codes implementiert werden:
(Blocks 653 und 657 der Prozedur ImposeJob, welche nur in Verbindung mit dem optionalen Ausschießen im laufenden Betrieb der Erfindung implementiert werden, sind unten beschrieben.)
Die Prozedur ImposeFile:
29 stellt die von der Prozedur ImposeFile der Ausschießprozeduren im laufenden Betrieb der Erfindung implementierten Programmschritte dar. Wenn die Prozedur ImposeFile aufgerufen wird, hat die Prozedur ImposeJob ein Dateien-/Listenpaar aus dem Befehlssatz auf dem Operandenstapel abgelegt. Das Dateien-/Listenpaar enthält eine Liste von Einträgen ("PageList"), in welcher die einzelnen Einträge folgendes festlegen:

1) Eine erste Prozedur user,
2) Die Seitenzahl der auf der Blattseite 456 wiederzugebenden Seite,
3) Die Operanden der Prozedur setvirtualdevice (welche die virtuelle [CTM] zur ordnungsgemäßen Positionierung der Seite auf der Blattseite 456 generiert), sowie
4) Eine zweite Prozedur user (die die "Offsets" festlegt).

Ein Block 670 setzt die Variable PageOffset = CurrentPage + PageOffset + 1. CurrentPage (welche die Seitenzahl der nächsten Seite in der aktuellen zusammengeführten PostScript^®-Datei 450 darstellt, die auf der Blattseite 456 wiederzugeben ist) ist anfänglich 0; PageOffset (welche die kumulierte verarbeitete Anzahl von Seiten aus früheren Dateien darstellt) ist anfänglich -1. Daher ist PageOffset beim ersten Durchlauf der Prozedur Impose-File gleich 0 (und zeigt damit an, dass keine vorhergehenden Dateien verarbeitet wurden). Ein Block 672 verwendet anschließend den Verweis CurrentIndex, um den ersten Eintrag aus der von der Prozedur ImposeJob erhaltenen Eintragsliste abzurufen. Ein Block 673 ruft dann die Seitenzahl aus dem Eintrag ab und setzt CurrentPage diesen Wert gleich. Auf diese Weise legt CurrentPage jetzt die Seitenzahl der ersten Seite in der aktuellen zusammengeführten PostScript^®-Datei fest, welche auf der Blattseite wiederzugeben ist.
Im nächsten Schritt prüft ein Entscheidungsblock 674 durch Vergleich von Current-Page mit 0, ob die erste Seite in der aktuellen PostScript^®-Datei (Seitennummer 0) auf der Blattseite wiederzugeben ist. Falls CurrentPage gleich 0 ist, ist die erste Seite in der zusammengeführten PostScript^®-Datei 450 auszuschießen und auf der Blattseite wiederzugeben; ein Block 675 führt die in dem von Block 672 abgerufenen aktuellen Eintrag enthaltene erste Prozedur user aus. Alternativ, wenn Block 674 feststellt, dass sich die erste Seite nicht auf der Blattseite befindet, blendet ein Block 676 die erste Prozedur user aus dem vom Stapel abgerufenen Eintrag ein.
Nachdem Block 675 die Prozedur user ausgeführt oder Block 676 die Prozedur user eingeblendet hat, führt ein Block 678 die oben in Verbindung mit 25 detailliert beschriebene Prozedur setvirtualdevice aus. Die Prozedur setvirtualdevice setzt die virtuelle [CTM] und den Beschneidungspfad entsprechend den im abgerufenen Eintrag enthaltenen Operanden.
Die Blocks 670-678 der Prozedur ImposeFile können mithilfe des folgenden Codes implementiert werden:
Im nächsten Schritt prüft ein Entscheidungsblock 680 durch Vergleich von Current-Page mit 0, ob die erste Seite in der aktuellen PostScript^®-Datei (Seitennummer 0) auf der Blattseite wiederzugeben ist. Falls CurrentPage nicht gleich Null ist (d.h. die erste Seite nicht auf der Blattseite wiederzugeben ist), ruft ein Block 682 eine beispielsweise mit "MakeNull" bezeichnete Prozedur auf. Die im Detail unten in Verbindung mit 30 beschriebene Prozedur MakeNull erstellt eine verkleinerte Version des virtuellen Geräts für die nächste auf der Blattseite wiederzugebende Seite. Die Prozedur MakeNull wird zur raschen Interpretation von Seiten verwendet, welche in der zusammengeführten PostScript^®-Datei 450 enthalten sind und auf der aktuellen Blattseite 456 nicht wiedergegeben werden. Der Block 682 ruft auch den umdefinierten Operator initclip auf (siehe 21).
Nach Ausführung der Prozedur MakeNull durch Block 682, oder aber wenn Block 680 feststellt, dass CurrentPage gleich Null ist (d.h., die erste Seite auf der Blattseite wiederzugeben ist), setzt ein Block 684 die Variable LastPage auf einen Wert, der der Seitenzahl der letzten Seite in der PostScript^®-Datei entspricht, die auf der Blattseite wiederzugeben ist. Die letzte Seite wird dadurch bestimmt, dass LastIndex als die Anzahl der Einträge im Befehlssatz minus 1 definiert wird. Die Einträge werden beginnend bei 0 (d.h., 0, 1, 2, 3,) so indiziert, dass der letzte von vier Einträgen zum Eintrag Nr. 3 wird.
LastIndex wird dann für den Abruf der Seitenzahl aus dem letzten Eintrag der in der Variablen LastPage gespeicherten Eintragsliste verwendet. Auf diese Weise ermittelt Block 684 die Anzahl der Seitenbeschreibungen in der aktuellen zusammengeführten PostScript^®-Datei 450, die interpretiert werden müssen, damit alle ausgewählten Seiten auf der Blattseite 456 ordnungsgemäß wiedergegeben werden können.
Die Blocks 680-684 der Prozedur ImposeFile können mithilfe des folgenden Codes implementiert werden:
Ein Block 686 öffnet dann bei Bedarf die aktuelle zusammengeführte PostScript^®-Datei 450 und definiert ein Dateiobjekt (d.h. "TheFile") für den Zugang auf die aktuelle zusammengeführte PostScript^®-Datei 450. Block 686 interpretiert dann die aktuelle zusammengeführte PostScript^®-Datei 450, welche verschiedene Seitenbeschreibungen enthält, einschließlich der für die Wiedergabe auf der aktuellen Blattseite 456 ausgewählten Seiten. In jeder Seitenbeschreibung ist der Operator showpage enthalten, der die umdefinierten Prozeduren EndPage und BeginPage der vorliegenden Erfindung aufruft.
Vorzugsweise führt Block 686 die zusammengeführte PostScript^®-Datei 450 im angehaltenen Modus aus, was zwingend vorsieht, dass die Ausführung angehalten wird, sobald die letzte Seite, die für die Blattseite 456 zu verarbeiten ist, ausgeführt wird (dies wird durch den Wert von LastPage bestimmt). Sobald die Ausführung abgeschlossen ist, säubert und schließt ein Block 688 die aktuelle PostScript^®-Datei; ein Block 690 kehrt zum Block 654 der Prozedur ImposeJob (26) zurück, um das nächste Datei-/Listenpaar aus dem Befehlssatz abzurufen.
Die Blocks 686-690 der Prozedur ImposeFile können mithilfe des folgenden Codes implementiert werden:
Die Prozedur MakeNull:
Die Prozedur MakeNull wird von Block 682 der Prozedur ImposeFile vor der Verarbeitung von Seiten aufgerufen, welche auf der aktuellen Blattseite 456 nicht wiedergegeben werden. Die Prozedur MakeNull erstellt ein niedrig auflösendes (verkleinertes) Abbild des virtuellen Geräts für den nächste auf der Blattseite wiederzugebende Seite. Dank des niedrig auflösenden virtuellen Geräts ist eine rasche Verarbeitung der nicht wiedergegebenen Seiten möglich. Die nicht wiedergegebenen Seiten werden mit Hilfe eines niedrig auflösenden Abbilds des virtuellen Geräts für die nächste auf der Blattseite wiederzugebende Seite verarbeitet; so soll sichergestellt werden, dass die bei der Verarbeitung erzeugten Markierungen nicht etwa bereits als Bild erfasste Teile der Blattseite 456 überschreiben.
Die Prozedur MakeNull erstellt ein niedrig auflösendes Abbild des virtuellen Geräts durch Skalierung der Bestandteile der virtuellen [CTM]. Darüber hinaus positioniert die Prozedur MakeNull das verkleinerte virtuelle Gerät in die Mitte des ursprünglichen virtuellen Geräts. Auf diese Weise wird sichergestellt, dass sich das verkleinerte virtuelle Gerät vollständig innerhalb des Beschneidungspfads befindet, der das ursprüngliche virtuelle Gerät umgrenzt.
Wie bereits oben erläutert, enthält die virtuelle [CTM] per definitionem die Komponenten [a b c d t_x t_y] und sieht eine Umformung der Koordinaten (x, y) im Anwenderraum in die Koordinaten (x', y') im Geräteraum vor, wie folgt: x' = ax + cy + tx y' = bx + dy + ty.
Die PostScript^®-Sprache enthält einen Operator scale, der aus den gelieferten Skalierungsfaktoren x und y eine temporäre Matrix erstellt und diese mit der aktuellen [CTM] verkettet. Der Operator scale ersetzt dann die aktuelle [CTM] durch die entstandene Matrix.
Wenn der PostScript^®-Operator scale mit den Skalierungsfaktoren x und y (s_x und s_y) als Operanden aufgerufen wird, ist die skalierte [CTM] = [s_xa s_xb s_yc s_yd t_x t_y]. Daher ergibt sich die von der skalierten [CTM] festgelegte neue Umformung von Anwenderraum auf Geräteraum durch: x' = sxax + sycy + tA (1) y' = sxbx + sydy + ty. (2)
Je nach Art des verwendeten PostScript^® RIP 82 können die genauen Skalierungsfaktoren s_x und s_y schwanken. Gegenüber der normalen Verarbeitung mit einem hochauflösenden Gerät führt jedoch ein Verhältnis von 1:1 zwischen Anwenderraum- und Geräteraumkoordinaten zu einer erheblich schnelleren Verarbeitung der Seiten. Auch installiert der PostScript^®-Operator nulldevice eine [CTM] mit einem Verhältnis von 1:1 zwischen Anwender- und Gerätekoordinaten. Obwohl daher die Skalierungsfaktoren auf einem gegebenen PostScript^® RIP 82 für eine optimale Leistung abgestimmt werden können, wird angenommen, dass ein Verhältnis von 1:1 zwischen den Anwenderraum- und Geräteraumkoordinaten mit angemessener Effizienz auf jedem PostScript^® RIP 82 läuft.
Daher werden die von der Prozedur MakeNull verwendeten Skalierungsfaktoren s_n und s_y vorzugsweise so berechnet, dass ein Verhältnis von 1:1 zwischen dem Anwenderraum und dem Geräteraum erzielt wird, wie folgt.
Um ausschließlich über die Skalierungsfaktoren ein Verhältnis von 1:1 zwischen Anwenderraum- und Geräteraumkoordinaten zu erzielen, muss der Einheitsvektor im Anwenderraum von den Koordinatenpunkten (0, 0) bis (1, 0) und von (0, 0) bis (0, 1) im Geräteraum Einheitslänge aufweisen. Daher |(x'(1,0), y'(1,0)) – (x'(0,0), y'(0,0))j = 1 (3)und |(x'(0,1), y'(0,1)) – (x'(0,0), y'(0,0))| = 1. (4)
Aus den Gleichungen (1) und (3), |(sxa + tx, sxb + ty) – (tx, ty)| = 1 |(sxa,sxb)| = 1 ((sxa)z + (sxb)2)1/2 = 1ergibt sich daher s_x = 1/(a² + 2²)^1/2.
Auf ähnliche Weise s_y = 1/(c² + d²)^1/2.
30 stellt die von der Prozedur MakeNull implementierten Programmschritte dar. Ein Block 698 ermittelt zunächst die Geräteraumkoordinaten des Halbwegepunkts des virtuellen Beschneidungspfads und speichert diese. Der Halbwegepunkt (mpx, mpy) wird zunächst durch Abfrage der Eck-Koordinaten des virtuellen Beschneidungspfades ermittelt, die in den Variablen Clip11X, ClipurX, Clip11Y und ClipurY gespeichert sind. Der Halbwegepunkt der x-Achse (mpx) wird durch die Addition der unteren linken und oberen rechten Eck-Koordinaten der x-Achse (Clip11X und ClipurX) und der Teilung durch zwei errechnet.
Auf ähnliche Weise wird der Halbwegepunkt der y-Achse (mpy) durch Addition der Eck-Koordinaten der y-Achse (Clip11Y und ClipurY) und der anschließenden Division durch zwei errechnet. Nach der Berechnung des Halbwegepunkts wird der (in "systemdict_transform" umbenannte) PostScript^®-Standardoperator ausgeführt, um die Koordinaten des Anwenderraums in Koordinaten des Geräteraums umzuwandeln.
Als nächsten Schritt holt ein Block 700 die virtuelle [CTM], welche in der Variablen DefaultMatrix gespeichert ist. Ein Block 702 berechnet dann die Skalierungsfaktoren s_x und s_y, wie oben festgelegt, während ein Block 704 die Skalierungsfaktoren auf die virtuelle [CTM] anwendet. Ein Block 706 speichert anschließend die skalierte virtuelle [CTM] als neue virtuelle [CTM] in der Variablen DefaultMatrix.
Anschließend setzt ein Block 708 den Halbwegepunkt des (durch die neue virtuelle [CTM] festgelegten) skalierten Beschneidungspfads dergestalt, dass er den Koordinaten des Halbwegepunkt des (von Block 598 gespeicherten) ursprünglichen Beschneidungspfads entspricht. Der Block 708 ermittelt die Differenz zwischen den gespeicherten Halbwegepunktkoordinaten und den neuen Halbwegepunktkoordinaten und verlagert dann die neuen Koordinaten um diese Differenz.
Die Prozedur MakeNull kann durch folgenden Code implementiert werden:
Die umdefinierte Prozedur EndPage:
Sämtliche in der zusammengeführten PostScript^®-Datei 450 enthaltenen Seitenbeschreibungen enthalten den Operator showpage, der die umdefinierten Prozeduren EndPage und BeginPage aufruft.
Die umdefinierte Prozedur EndPage aktualisiert die Variable CurrentPage, welche die Seitenzahl der nächsten auszuschießenden und auf der Blattseite 456 wiederzugebenden Seite in der zusammengeführten PostScript^®-Datei 450 darstellt. Ebenso ruft die umdefinierte Prozedur EndPage für die zu interpretierenden Seiten die Prozeduren setvirtualdevice und MakeNull auf.
31 ist ein Flussdiagramm, in welchem die von der umdefinierten Prozedur EndPage implementierten Programmschritte dargestellt sind. Ein Block 710 prüft, ob die Prozedur EndPage von Operator showpage aufgerufen wurde, indem er überprüft, ob der Ursachencode 0 ist. Ein Block 712 vergleicht CurrentPage plus PageOffset mit PageCount um festzustellen, ob die aktuelle Seite in der PostScript^®-Datei ausgeschossen und auf Blattseite 456 wiedergegeben werden soll.
Unter der Annahme, dass sowohl für Block 710 als auch für Block 712 True gilt, richtet ein Block 713 durch Aufruf des (jetzt zu "systemdict_initgraphics" umbenannten) Standardoperators initgraphics die Standardumgebung ein. Der Block 713 ruft dann die zweite Prozedur user (welche beispielsweise die Offset-Anweisungen enthält) aus dem aktuellen Eintrag ab und führt sie aus. Falls die zweite Prozedur user Offset-Anweisungen enthält, wird die PostScript^®-Datei an den Beginn der nächsten in das Druckerzeugnis aufzunehmenden Seite umpositioniert; damit wird die Verarbeitung irrelevanter Seiten umgangen. Falls die zweite Prozedur user andere Anweisungen (wie Barcodes, Wasserzeichen usw.) enthält, werden diese ebenfalls ausgeführt.
Im nächsten Schritt erhöht ein Block 714 den Zeiger CurrentIndex, der für den Abruf des nächsten Eintrags aus der Eintragsliste (PageList) verwendet wird. Der Entscheidungsblock 716 prüft dann durch Vergleich von CurrentIndex mit LastIndex, ob im Befehlssatz ein weiterer Eintrag vorhanden ist.
Falls CurrentIndex weniger oder gleich LastIndex ist, setzt ein Block 718 durch Aufruf des PostScript^®-Standardoperators initgraphics (jetzt umbenannt in "systemdict_initgraphics") den Grafikstatus auf seinen Systemstandardwert zurück. Ein Block 720 ruft dann mit Hilfe von CurrentIndex den nächsten Eintrag in der Eintragsliste ab, um die Operanden für die Prozedur setvirtualdevice auf dem Operandenstapel abzulegen, während ein Block 722 die Prozedur setvirtualdevice aufruft.
Ein Block 724 setzt dann CurrentPage gleich dem Wert der Seitenzahl aus dem abgerufenen Eintrag.
CurrentPage wird nun so aktualisiert, dass es die Seitenzahl der nächsten Seite aus der zusammengeführten PostScript^®-Datei 450 enthält, welche auszuschießen und auf der Blattseite 456 wiederzugeben ist.
Im nächsten Schritt ruft ein Block 726 die Prozedur MakeNull auf, um das niedrig auflösende virtuelle Gerät für die Verarbeitung von nicht wiedergegebenen Seiten einzurichten. Die Prozedur MakeNull wird aufgerufen, da davon ausgegangen wird, dass die nächste Seite in der zusammengeführten PostScript^®-Datei 450 nicht auf der Blattseite 456 wiedergegeben wird. (Falls die nächste Seite auf der Blattseite wiederzugeben ist, wird das virtuelle Gerät für diese Seite von der unten im Detail beschriebenen umdefinierten Prozedur Begin-Page eingerichtet). Ein Block 728 entfernt dann die (im abgerufenen Eintrag enthaltene) Prozedur user vom Operandenstapel.
Sollte sich einer der Blocks 710, 712 oder 716 als False erweisen, oder aber nach dem Einblenden der Prozedur user durch Block 728, legt ein Block 730 den Wert der Variablen ImageDone auf dem Stapel ab. Ist der Wert von ImageDone auf True gesetzt und zeigt er damit an, dass die Blattseite fertig gestellt ist, wird durch den Aufruf der Prozedur EndPage (d.h., durch den Operator showpage oder für die neue Geräteaktivierung) der Inhalt des Rasterspeichers 452 automatisch zum Demand-Drucker 84 übertragen, damit die ausgewählten Seiten auf Blattseite 456 physisch wiedergegeben werden. (Siehe 19).
Ein Block 732 setzt dann ImageDone auf False zurück, um anzuzeigen, dass die Blattseite nicht fertig gestellt ist; der Inhalt des Rasterspeichers 452 wird noch nicht an den Demand-Drucker 84 zur physischen Wiedergabe übertragen.
Die umdefinierte Prozedur EndPage kann durch folgenden Code implementiert werden:
Die umdefinierte Prozedur BeginPage:
32 ist ein Flussdiagramm, in welchem die von der umdefinierten Prozedur BeginPage implementierten Programmschritte dargestellt sind. Zunächst ruft ein Block 740 den umdefinierten Operator initmatrix auf, um die virtuelle [CTM] zu setzen. Wie auch in 20 ersichtlich, erhält die Prozedur BeginPage vom Operator showpage als Operanden PageCount. Ein Entscheidungsblock 742 vergleicht CurrentPage (welches durch Block 724 der umdefinierten Prozedur Endpage in 31 aktualisiert wurde) mit PageCount. CurrentPage enthält die Seitenzahl der nächsten Seite in der PostScript^®-Datei, die auf Blattseite 456 wiederzugeben ist. Wenn daher CurrentPage und PageCount gleich sind, ist die aktuelle Seite in der zusammengeführten PostScript^®-Datei 450 auszuschießen und auf der Blattseite 456 wiederzugeben; ein Block 744 ruft den nächsten Eintrag aus der Eintragsliste ab (welcher die Prozedur user, die Seitennummer und die Operanden setvirtualdevice enthält).
Ein Block 745 führt dann die Prozedur user aus dem abgerufenen Eintrag aus, während ein Block 746 die Prozedur setvirtualdevice aufruft, um die virtuelle [CTM] sowie den Beschneidungspfad für das virtuelle Gerät einzurichten (siehe 27). Ein Block 748 blendet dann die Seitenzahl aus dem abgerufenen Eintrag ein.
Im nächsten Schritt "übertüncht" ein Block 750 die virtuelle Seite, indem er den Bereich innerhalb des Beschneidungspfads weiß färbt. Dies ist erforderlich, um etwaige verirrte Markierungen zu löschen, die unter Umständen während der Verarbeitung der nicht wiedergegebenen Seiten mithilfe der Prozedur MakeNull auf die Seite aufgebracht wurden.
Alternativ, falls Block 742 feststellt, dass die nächste Seite in der zusammengeführten PostScript^®-Datei 450 nicht auf der Blattseite dargestellt werden soll (also CurrentPage nicht gleich PageCount ist), vergleicht ein Entscheidungsblock 752 PageCount mit LastPage plus PageOffset. Falls PageCount größer als LastPage plus PageOffset ist, müssen nachfolgende Seiten in der PostScript^®-Datei nicht interpretiert werden, da sie jenseits der letzten Seite liegen, die auf der Blattseite 456 darzustellen ist. Ein Block 754 hält daher die Ausführung der zusammengeführten PostScript^®-Datei 450 an. Wie bereits weiter oben erläutert, führt die Prozedur ImposeFile die PostScript^®-Datei 450 im angehaltenen Kontext aus. Um zwischen dem erwarteten Halt im Block 754 und einem beispielsweise durch einen PostScript^®-Fehler verursachten unerwarteten Halt zu unterscheiden, wird vom Block 754 der umdefinierten Prozedur BeginPage der String "done with current file" generiert.
Wie ebenfalls in 27 dargestellt, prüft Block 386 der Prozedur ImposeFile, ob der String "done with current file" vorhanden ist, um auf diese Weise zu ermitteln, wann auf Block 688 über zu gehen ist, um die zusammengeführte PostScript^®-Datei 450 zu säubern und zu schließen.
Alternativ, falls Block 752 feststellt, dass PageCount weniger als oder gleich LastPage plus PageOffset ist (sich die aktuelle Seite also vor der letzten Seite befindet, die auf der Blattseite wiederzugeben ist), ruft ein Block 755 den umdefinierten Operator initclip auf, um den virtuellen Beschneidungspfad rückzusetzen. (Siehe 20).
Die umdefinierte Prozedur BeginPage kann durch folgenden Code implementiert werden:
Die Variable ImageDone:
Wie bereits weiter oben erläutert, handelt es sich bei der Variablen ImageDone um eine Boolesche Variable, welche anzeigen soll, wenn alle Seiten für die aktuelle Blattseite 456 interpretiert und in den Rasterspeicher 452 so eingetragen wurden, dass die Blattseite 456 vom Demand-Drucker 84 physisch wiedergegeben werden kann. ImageDone ist anfänglich und normalerweise auf False gesetzt und zeigt damit an, dass die aktuelle Blattseite 456 noch nicht fertiggestellt wurde. Wie jedoch in 26 dargestellt, setzt nach der Verarbeitung sämtlicher Datei-/Listenpaare aus dem Befehlssatz durch die Prozedur ImposeJob der Block 658 Image-Done auf True und zeigt damit an, dass die Blattseite abgeschlossen ist. Auch könnte die im letzten Eintrag eines Datei-/Listenpaares in Befehlssatz enthaltene Prozedur user eine Anweisung dahingehend enthalten, dass ImageDone auf True zu setzen ist, um anzuzeigen, dass die aktuelle Blattseite abgeschlossen ist.
Die Variable ImageDone wird von der umdefinierten Prozedur EndPage verwendet. Wie in 20 und 31 dargestellt, gibt Block 730 der umdefinierten Prozedur EndPage dem Block 502 des Operators showpage den Wert von ImageDone zurück. Wenn ImageDone auf True gesetzt ist, überträgt Block 504 den Inhalt des Rasterspeichers an den Demand-Drucker für die Wiedergabe der aktuellen Blattseite.
Die Variable ImageDone kann dazu benützt werden, die Wiedergabe mehrerer Blattseiten durch ein einzelnes Datei-/Listenpaar im Befehlssatz zuzulassen (siehe Anhang I Befehlssatzmuster).
Die Prozedur Showdevice:
Die Verfahren zum Ausschießen im laufenden Betrieb (Impositions-On-The-Fly) umfassen unter Umständen eine zusätzliche, beispielsweise mit "showdevice" bezeichnete Prozedur, die die Variable ImageDone einsetzt, um dem Anwender die Wiedergabe der Blattseite zu jedem beliebigen Zeitpunkt zu gestatten. Die Prozedur showdevice setzt ImageDone auf True und ruft dann den Operator showpage auf, der seinerseits die umdefinierte Prozedur EndPage aufruft und die aktuelle Blattseite wiedergibt, wie oben beschrieben.
Die Prozedur showdevice kann durch folgenden Code implementiert werden:
Die Prozedur showdevice kommt normalerweise dann zum Einsatz, wenn der Anwender die Prozedur setvirtualdevice (und verwandte Prozeduren) in einer Anwendung ohne Ausschießvorgang implementiert, in welcher die Prozeduren ImposeJob und ImposeFile eliminiert werden. So könnte die Prozedur showdevice beispielsweise implementiert werden, um eine oder mehrere in der zusammmengeführten PostScript^®-Datei 450 enthaltenen ausgewählten Seiten wiederzugeben.
Optionale Verfahren zum Ausschießen im laufenden Betrieb:
Optional können die Ausschießverfahren im laufenden Betrieb zusätzliche Prozeduren umfassen, die das ordnungsgemäße Ausschießen von Seitenbeschreibungen mithilfe der PostScript^®-Operatoren save und restore erlauben.
Der PostScript^®-Operator save macht einen "Schnappschuss" des Zustands des virtuellen Speichers, in welchem alle Werte zusammengesetzter Objekte wie Strings und Arrays gespeichert werden. Viele der vom Verfahren zum Ausschießen im laufenden Betrieb der vorliegenden Erfindung verwendeten Variablen werden im virtuellen Speicher gespeichert. Der Operator save speichert auch den aktuellen Grafikstatus, indem er eine Kopie des aktuellen Grafikstatus auf den Stapel Grafikstatus verschiebt.
Der PostScript^®-Operator restore versetzt den virtuellen Speicher und den aktuellen Grafikstatus in den Status zu jenem Zeitpunkt zurück, an dem der entsprechende Operator save ausgeführt wurde.
Der PostScript^®-Operator gsave verschiebt eine Kopie des aktuellen Grafikstatus auf den Stapel Grafikstatus, während der PostScript^®-operator grestore den gespeicherten Grafikstatus aus dem Stapel Grafikstatus einblendet und als aktuellen Grafikstatus wiederherstellt. Der PostScript^®-Operator grestoreall stellt entweder den zuunterst befindlichen, im Stapel Grafikstatus gespeicherten Grafikstatus oder den ersten vom Operator save (im Gegensatz zum Operator gsave) gespeicherten Grafikstatus wieder her. Zu den von diesen Operatoren betroffenen Elementen des aktuellen Grafikstatus zählen die aktuelle [CTM], der Beschneidungspfad und der aktuelle Pfad. Sie haben jedoch keine Auswirkung auf den Inhalt des Rasterspeichers 452.
Die PostScript^®-Operatoren save und restore können sich auf die Prozeduren des Ausschießens im laufenden Betrieb der vorliegenden Erfindung sowie auf andere Ausschießmethoden nachteilig auswirken. Das Problem entsteht, wenn eine Seitenbeschreibung in einer zusammengeführten PostScript^®-Datei 450 einen Operator save aufruft, der die [CTM] speichert, welche die gewünschte Position der Seite auf dem Gerät festlegt. Wenn eine nachfolgende Seitenbeschreibung einen Operator restore aufruft, wird die [CTM] der nachfolgenden Seite durch die [CTM] der vorhergehenden Seite ersetzt. Aus diesem Grund wird die nachfolgende Seite auf der Blattseite 456 falsch positioniert.
Um dieses Problem zu beheben, werden in Verbindung mit den oben beschriebenen Prozeduren zwei neue Prozeduren (Vsave und Vrestore) angewandt. Die Prozeduren Vsave und Vrestore werden so zur Umdefinition der PostScript^®-Operatoren save und restore eingesetzt, dass sie auf die anderen Prozeduren des Ausschießens im laufenden Betrieb der vorliegenden Erfindung keine störenden Auswirkungen haben.
Die Prozedur Vsave:
Generell werden durch die Prozedur Vsave die Komponenten der Seitengröße (PageX und PageY) und der virtuellen [CTM] (welche das virtuelle Gerät definieren) an den aktuellen Pfad angehängt, der vom PostScript^®-Operator save gespeichert wird. Später holt die Prozedur Vrestore diese Komponenten ab, entfernt sie aus dem aktuellen Pfad und verwendet sie zur Generierung des richtigen Beschneidungspfads, der Seitenausrichtung und der [CTM] für die wiederhergestellte Seite.
33 ist ein Flussdiagramm, in welchem die von der optionalen Prozedur Vsave implementierten Programmschritte dargestellt sind. Ein Block 800 speichert eine Kopie der aktuellen [CTM], anschließend setzt ein Block 801 die [CTM] auf einen einer Identitätsmatrix entsprechenden Wert ([1 0 0 1 0 0]).
Die Identitätsmatrix wird deswegen benützt, weil alle zur Beschreibung des aktuellen Pfads verwendeten Punkte in den Koordinaten des Anwenderraums festgelegt sind. Jedoch wird zu dem Zeitpunkt, an welchem ein PostScript^®-Programm einen Punkt in den aktuellen Pfad einträgt, jede einzelne Koordinate in einen der [CTM] entsprechenden Geräteraum umgewandelt. Auf diese Weise wird die Identitätsmatrix bei der Einfügung von Komponenten in den aktuellen Pfad eingesetzt, um Rundungsfehler zu vermeiden, die bei dieser Umwandlung von Anwenderraum zu Geräteraum auftreten können.
Ein Entscheidungsblock 802 prüft dann, ob ein currentpoint definiert ist. Ist ein currentpoint definiert, dann setzt ein Block 804 die Variable p1 gleich dem aktuellen Pfad.
Dies kann durch Aufruf der vorher definierten Prozedur MakePath geschehen, welche im aktuellen Koordinatensystem eine Beschreibung des aktuellen Pfads erstellt. (Die Prozedur MakePath wurde bereits oben in Verbindung mit dem Block 524 des umdefinierten Operators initclip in 20 beschrieben.)
Ein Block 806 definiert anschließend eine beispielsweise "firstop" genannte Variable als PostScript^®-Operator lineto. Per definitionem fügt der PostScript^®-Operator lineto ein gerades Liniensegment in den aktuellen Pfad ein, indem er den vorhergehenden aktuellen Punkt mit dem neuen verbindet.
Alternativ, wenn der Block 802 feststellt, dass kein currentpoint existiert, setzt ein Block 808 p1 einem leeren Pfad gleich. Ein Block 810 definiert anschließend firstop als neuen PostScript^®-Operator moveto, der einen neuen currentpoint festsetzt.
Nachdem firstop entweder durch den Block 806 oder den Block 810 definiert ist, erstellt ein Block 812 eine "unbegrenzte" Begrenzungsbox für den aktuellen Pfad. Eine Begrenzungsbox, die normalerweise vom PostScript^®-Operator setbbox festgelegt wird, definiert einen Bereich, in den die Koordinaten des aktuellen Pfads zu fallen haben. Bei den Operanden zum Operator setbbox handelt es sich um Anwenderraumkoordinaten der linken unteren und der rechten oberen Ecke der Begrenzungsbox. Da die Komponenten für Seitengröße und [CTM] während der Prozedur Vsave in den aktuellen Pfad eingefügt werden, muss die Begrenzungsbox groß genug eingestellt sein, um die von diesen Komponenten definierten "Punkte" zu umfassen. Daher kann eine beispielsweise "SetBigBBox" genannte vorher definierte Prozedur aufgerufen werden, um die Begrenzungsbox auf das größtmögliche Maß einzustellen.
Die Prozedur SetBigBBox kann durch folgenden Code implementiert werden:
Nach dem Setzen der großen Begrenzungsbox ruft ein Block 814 den (von Block 806 oder Block 810 definierten) Operator firstop auf, der die Komponenten der Seitengröße (PageX und PageY) an den aktuellen Pfad anhängen soll. Als nächsten Schritt fügt ein Block 818 die (in der Variablen DefaultMatrix gespeicherten) Komponenten der virtuellen [CTM] an den aktuellen Pfad an. Ein Block 820 ersetzt die Identitäts-[CTM] durch die von Block 800 gespeicherte [CTM].
Die Prozedur Vsave kann durch folgenden Code implementiert werden:
Die Prozedur Vrestore:
Die Prozedur Vrestore holt die von der Prozedur Vsave an den aktuellen Pfad angehängten Komponenten der Seitengröße und der virtuellen [CTM] (durch welche das virtuelle Gerät definiert wurde) und setzt sie zur Erstellung des richtigen Beschneidungspfads, der Seitenausrichtung und der virtuellen [CTM] für die wiederhergestellte Seite ein.
34 ist ein Flussdiagramm, in welchem die von der Prozedur Vrestore implementierten Programmschritte dargestellt sind. Ein Block 830 speichert die aktuelle [CTM], während ein Block 832 die [CTM] auf eine Identitätsmatrix setzt. Wie auch bei der Prozedur Vsave werden durch die Verwendung der Identitäts-[CTM] Rundungsfehler bei der Umformung der Koordinaten vom Anwenderraum zum Geräteraum im aktuellen Pfad vermieden.
Anschließend holt ein Block 834 die Elemente des aktuellen Pfads durch Aufruf des PostScript^®-Operators pathforall, der die Anwenderraumkoordinaten der einzelnen Pfadelemente auf den Operandenstapel verschiebt. Zu den abgeholten Elementen zählen die Komponenten der Seitengröße und der virtuellen [CTM], welche durch die Prozedur Vsave an den Pfad angehängt wurden. Ein Block 836 führt dann verschiedene Operationen der Stapelhandhabung durch, um die Komponenten von Seitengröße und virtueller [CTM] zuoberst auf dem Stapel abzulegen. Der Block 836 speichert anschließend die Komponenten in den Variablen, die beispielsweise "ResDefaultMatrix", "ResPageX" und "ResPageY" benannt sind und die die Seitengröße und die virtuelle [CTM] zu jenem Zeitpunkt darstellen, an dem der PostScript^®-Operator save aufgerufen wurde.
Im nächsten Schritt vergleicht ein Entscheidungsblock 838 ResDefaultMatrix (zum Zeitpunkt der Speicherung) mit der aktuellen virtuellen [CTM] (zum Zeitpunkt der Wiederherstellung), welche in der Variablen Defaultmatrix gespeichert ist. Die Äquivalenz der Matrizen lässt sich einfach durch Einsatz einer vorher definierten Hilfsroutine feststellen, welche beispielsweise "EqualMatrix" genannt wird und welche einen Vergleich der einzelnen Komponenten beider Matrizen durchführt, wobei ein geringfügiger Gleitkomma-Rundungsfehler geduldet wird. Wenn die beiden Matrizen gleichwertig sind, legt die Routine EqualMatrix den Wert True auf dem Stapel ab, bei ungleicher Wertigkeit gibt die Prozedur EqualMatrix den Wert False zurück. Die Routine EqualMatrix kann durch folgenden Code implementiert werden:
Wenn der Block 838 feststellt, dass die wiederhergestellte [CTM] und die aktuelle [CTM] nicht gleichwertig sind, wird angenommen, dass während der Interpretation einer Seite der Operator save aufgerufen wurde, während bei der Interpretation einer anderen Seite der Operator restore zum Einsatz kam. Ein Block 840 setzt dann die [CTM] auf den von Block 830 gespeicherten Wert zurück. Im nächsten Schritt ruft ein Block 842 p1 auf, welches den aktuellen Pfad zum Zeitpunkt des Aufrufs des Operators save enthält.
Der Block 842 entfernt dann die an den aktuellen Pfad angefügten Komponenten für Seitengröße und [CTM] und setzt p1 auf den gleichen Wert wie die verbleibenden Pfadelemente.
Die Blocks 830-842 der Prozedur Vrestore können mithilfe des folgenden Codes implementiert werden:
Im nächsten Schritt ermittelt ein Entscheidungsblock 844 durch Vergleich von ResPageX mit ResPageY die Seitenausrichtung der wiederhergestellten Seite. Falls ResPageX größer als ResPageY ist, wird eine Variable namens ResPortrait auf Falle gesetzt und zeigt damit eine Seitenausrichtung im Querformat an.
Alternativ, wenn ResPageX kleiner als ResPageY ist, wird die Variable ResPortrait auf True gesetzt und zeigt damit eine Seitenausrichtung im Hochformat an. Der Block 844 vergleicht dann ResPortrait (die wiederhergestellte Seitenausrichtung) mit Portrait (der gespeicherten Seitenausrichtung). Falls die Seitenausrichtung geändert wurde (ResPortrait und Portrait ungleich sind), ruft ein Block 856 die Prozedur SetPortrait auf, um die Ausrichtung des Geräts umzustellen. (Siehe 25 und 26A&B.)
Die Blocks 844 und 846 der Prozedur Vrestore können mithilfe des folgenden Codes implementiert werden:
Wenn der Block 844 feststellt, dass die Ausrichtung gleich ist, oder nach Korrektur der Ausrichtung durch Block 846 speichert ein Block 848 die Prozeduren für die Erstellung des aktuellen Beschneidungspfads durch Aufruf der Prozedur MakePath in einer beispielsweise mit "c1" bezeichneten Variablen.
Ein Block 850 errechnet dann die neue [CTM] durch Ermittlung der Akkumulation von Operationen, welche an der wiederhergestellten virtuellen [CTM] angewandt wurden, und durch Anwendung dieser Operationen an der aktuellen virtuellen [CTM]. Der Block 850 errechnet die neue [CTM], indem er zuerst die aktuelle [CTM] abholt, welche als das Ergebnis der mit einer Operationsmatrix verketteten wiederhergestellten virtuellen [CTM] (d.h., der aus dem Operator save wiederhergestellten virtuellen [CTM]) betrachtet werden kann. Dann berechnet der Block 850 die Operationsmatrix durch Verkettung der aktuellen [CTM] mit dem Kehrwert der wiederhergestellten virtuellen [CTM]. Die Operationsmatrix wird dann zur Erstellung der neuen [CTM] mit der aktuellen virtuellen [CTM] verkettet. Der Block 850 geht daher davon aus, dass:
[aktuelle CTM] = [Operationen] [wiederhergestellte virtuelle CTM].
Darüber hinaus führt Block 850 folgende Operationen durch:
[Operationen] = [aktuelle CTM] [wiederhergestellte virtuelle CTM]^-1;
und
[neue CTM] = [Operationen] [wiederhergestellte virtuelle CTM].
Die Blocks 848 und 850 der Prozedur Vrestore können durch folgenden Code implementiert werden:
Ein Block 852 regeneriert den (in c1 gespeicherten) Beschneidungspfad, während ein Block 854 den (in p1 gespeicherten) aktuellen Pfad in dem von der neuen [CTM] spezifizierten neuen Koordinatensystem regeneriert. Die Blocks 852 und 854 können durch folgenden Code implementiert werden:
Alternativ, wenn der Block 838 feststellt, dass die wiederhergestellte virtuelle [CTM] der aktuellen virtuellen [CTM] gleichwertig ist (d.h., dass die Operatoren save und restore auf derselben Seite aufgerufen wurden), entfernt ein Block 856 einfach die Komponenten für Seitengröße und virtuelle [CTM] aus dem aktuellen Pfad. Ein Block 858 stellt anschließend den aktuellen Pfad wieder her, während ein Block 860 die [CTM] auf den von Block 830 gespeicherten Wert zurücksetzt.
Die Blocks 856-860 können durch folgenden Code implementiert werden:
Die umdefinierten PostScript^®-Operatoren Save:
Die PostScript^®-Operatoren save (zu denen save und gsave zählen) werden umdefiniert, um die Prozedur Vsave aufzurufen. Bevor jedoch diese Operatoren umdefiniert werden, werden sie umbenannt (beispielsweise "systemdict_operator"), da ihre normale Operation im Dictionary systemdict definiert ist. Die Operatoren save können durch folgenden Code umbenannt werden:
/systemdict_save systemdict /save get def
/systemdict_gsave systemdict /gsave get def
Die PostScript^®-Operatoren save und gsave werden dann umdefiniert. 35 ist ein Flussdiagramm, in welchem die zur Umdefinition der PostScript^®-Operatoren save implementierten Programmschritte dargestellt sind. Ein Block 872 ruft zunächst die oben in Verbindung mit 33 beschriebene Prozedur Vsave auf. Die Prozedur Vsave speichert den aktuellen Pfad in p1 und hängt dann die Komponenten der Seitengröße und der virtuellen [CTM] an den aktuellen Pfad an.
Anschließend ruft ein Block 874 den PostScript^®-Standardoperator save (oder gsave) auf (welche nun in "systemdict_save" oder "systemdict_gsave" umbenannt wurden).
Der Operator save führt seine Standardfunktion der Speicherung des aktuellen Zustandes des virtuellen Speichers und des aktuellen Grafikstatus durch, einschließlich des aktuellen Pfads (welcher jetzt die Komponenten der Seitengröße und der virtuellen [CTM] umfasst). Der Operator gsave führt seine Standardfunktion der Speicherung des aktuellen Grafikstatus durch.
Im nächsten Schritt setzt ein Block 876 die [CTM] auf eine Identitätsmatrix. Wie bereits vorher werden dadurch auch hier Rundungsfehler im aktuellen Pfad ausgeschaltet. Daraufhin führt ein Block 878 den aktuellen Pfad auf den in p1 gespeicherten Pfad (den Pfad ohne die zusätzlichen Komponenten für Seitengröße und virtuelle [CTM]) zurück, während ein Block 880 die [CTM] zur virtuellen [CTM] zurückführt.
Die Blocks 870-880 für die Umdefinition des PostScript^®-Operators save können mithilfe folgenden Codes implementiert werden:
Auf ähnliche Weise lässt sich der PostScript^®-Operator gsave durch Implementierung des folgenden Codes umdefinieren:
Die umdefinierten PostScript^®-Operatoren Restore:
Zum Aufruf der Prozedur Vrestore muss der PostScript^®-Operator restore ebenfalls umbenannt und umdefiniert werden. Wie die Operatoren save wird auch der Operator restore durch folgenden Code beispielsweise in "systemdict_restore" umbenannt:
/systemdict_restore systemdict /restore get def
Da die PostScript^®-Operatoren save und restore Auswirkungen auf den Inhalt des virtuellen Speichers und des Grafikstatus haben, können durch die Verwendung dieser Operatoren die Werte zahlreicher während der Ausschieß- und setvirtualdevice-Prozeduren verwendeten Variablen unbeabsichtigt verändert werden. Einfache, auf dem Stapel Operanden gespeicherte Werte werden jedoch nicht beeinflusst. Daher wird der PostScript^®-Operator restore umdefiniert, um die Werte der im virtuellen Speicher gespeicherten Variablen zu schützen, indem er sie auf dem Stapel Operanden speichert, bevor er den PostScript^®-Standardoperator restore aufruft.
36 ist ein Flussdiagramm, in welchem die vom umdefinierten Operator restore implementierten Programmschritte dargestellt sind. Ein Block 892 legt die Werte aller im virtuellen Speicher gespeicherten Ausschießvariablen auf dem Operandenstapel ab, sodass ihre Werte vom Operator restore nicht überschrieben werden können. Anschließend ruft ein Block 894 den (jetzt in "systemdict_restore" umbenannten) Standardoperator restore auf. Ein Block 896 setzt dann die Werte der Variablen auf dem Operandenstapel auf ihre Werte vor der Speicherung zurück. Schließlich ruft ein Block 898 die Prozedur Vrestore auf.
Die Blocks 892-898 des umdefinierten Operators restore können mithilfe des folgenden Codes implementiert werden:
Die umdefinierten PostScript^®-Operatoren grestore:
Die PostScript^®-Standardoperatoren grestore oder grestoreall werden beispielsweise in "systemdict_operator" umbenannt. Dies kann durch folgenden Code geschehen:
/systemdict_grestore systemdict /grestore get def
/systemdict_grestoreall systemdict /grestoreall get def
Da die PostScript^®-Operatoren grestore und grestoreall nur auf den Grafikstatus Auswirkungen haben, ist der Schutz der Werte von im virtuellen Speicher gespeicherten Variablen nicht erforderlich. Daher lassen sich die Operatoren grestore oder grestoreall einfacher umdefinieren.
37 ist ein Flussdiagramm, in welchem die von den umdefinierten PostScript-Operatoren grestore und grestoreall implementierten Programmschritte dargestellt sind. Ein Block 902 ruft den umbenannten Standardoperator grestore oder grestoreall auf, während ein Block 904 die Prozedur Vrestore aufruft, welche dann die richtige [CTM], die richtige Seitenausrichtung und den berichtigten Beschneidungspfad errechnet.
Die Blocks 902-904 für die Umdefinition des PostScript^®-Operators grestore können mithilfe folgenden Codes implementiert werden:
Auf ähnliche Weise lässt sich der Operator grestoreall durch Implementierung des folgenden Codes umdefinieren:
Die Level 2 PostScript^®-Operatoren:
PostScript^®-Implementierungen des Levels 2 unterstützen die folgenden drei zusätzlichen Operatoren, welche Auswirkungen auf den aktuellen Grafikstatus (und damit auf die [CTM]) haben und daher einen störenden Einfluss auf die Ausschießverfahren der vorliegenden Erfindungen haben könnten: gstate, currentgstate und setgstate. Der PostScript^®-Operator gstate erstellt ein neues Grafikstatusobjekt (dessen Anfangswert dem aktuellen Grafikstatus entspricht) und verschiebt dieses auf den Operandenstapel. Der PostScript^®-Operator currentgstate ersetzt den Wert des gstate-Objekts durch den aktuellen Grafikstatus. Der PostScript^®-Operator setgstate ersetzt den aktuellen Grafikstatus durch den Wert des gstate-Objektes.
Ähnlich den oben beschriebenen Operatoren gsave und grestore werden zum Aufruf der Prozeduren Vsave und Vrestore die Operatoren gstate umbenannt und umdefiniert. Die Operatoren gstate können durch folgenden Code umbenannt werden:
Ähnlich dem in Verbindung mit 35 oben beschriebenen umdefinierten Operator gsave werden die Operatoren gstate und currentgstate umdefiniert, um zunächst die Prozedur Vsave und anschließend den umbenannten Standardoperator gstate oder currentgstate aufzurufen. Die umdefinierten Operatoren stellen dann den aktuellen Pfad ohne die Komponenten für Seitengröße und [CTM] wieder her und setzen die virtuelle [CTM] zurück.
Ebenso wird ähnlich dem oben in Verbindung mit 37 beschriebenen umbenannten Operator grestore der Operator setgstate umdefiniert, um zunächst den umbenannten Operator setgstate und anschließend die Prozedur Vrestore aufzurufen.
Der Level 2 PostScript^® gstate Operatoren können mittels des folgenden Codes umdefiniert werden:
Diese optionalen Prozeduren werden dann verwendet, wenn erwartet wird, dass die Seitenbeschreibungen in den zusammengeführten PostScript^®-Dateien 450 in einer Seitenbeschreibung einen Operator save und in einer nachfolgenden Seitenbeschreibung einen Operator restore enthalten. Wenn die optionalen Prozeduren angewendet werden, sollte an der Prozedur setvirtualdevice eine kleine Änderung vorgenommen werden, welche oben in Verbindung mit 27 beschrieben ist. Wie in 27 dargestellt, ruft ein zusätzlicher Block 633 den umdefinierten Operator save auf und blendet dann das Objekt save vom Operandenstapel ein, nachdem Block 632 die Prozedur EnableVirtualDevice aufgerufen hat. Dies ist erforderlich, da die Operatoren grestore und grestoreall ohne einen entsprechenden Operator save oder gsave aufgerufen werden können. Wenn grestore ohne einen Operator gsave aufgerufen wird, stellt er den Grafikstatus vom oberen Ende des Stapels Grafikstatus her. Wenn grestoreall ohne einen Operator gsave oder save aufgerufen wird, stellt er entweder den Grafikstatus vom unteren Ende des Stapels Grafikstatus oder den vom letzten Operator save gespeicherten Grafikstatus wieder her. Wenn das zuoberst liegende Objekt save vor der Umdefinition des Operators save erstellt wurde, enthält der gespeicherte aktuelle Pfad keine Anhänge der Komponenten für Seitengröße und [CTM] und wird daher mit den umdefinierten Operatoren grestore und grestorall nicht ordnungsgemäß funktionieren. Daher kann durch Aufruf des umdefinierten Operators save am Block 633 der Prozedur setvirtualdevice sichergestellt werden, dass die Operatoren grestore und grestoreall immer einen mit der vorliegenden Erfindung kompatiblen gespeicherten Grafikstatus wiederherstellen werden.
Die Blocks 630-633 der Prozedur setvirtualdevice können mithilfe des folgenden Codes implementiert werden:
VirtualDeviceEnabled not {EnableVirtualDevice save pop} if
Ebenso kann in einigen PostScript^®-Anwendungen die hintereinander erfolgende Interpretation verschiedener PostScript^®-Dateien die Operation der Erfindung störend beeinflussen. So könnten beispielsweise zwei verschiedene PostScript^®-Dateien für Variable mit unterschiedlichen Definitionen denselben Namen verwenden. Wenn die zweite interpretierte PostScript^®-Datei die Variable nicht ausdrücklich initialisiert, wird die Definition der Variablen aus der ersten PostScript^®-Datei verwendet, was sich auf die ordnungsgemäße Interpretation der zweiten PostScript^®-Datei störend auswirkt. Zur Behebung dieses Problems kann die Prozedur ImposeJob (28) geändert werden. Wie in 28 dargestellt, werden die Blocks 653 und 557 zur Speicherung des Zustands des virtuellen Speichers (in welchem zahlreiche Definitionen von Variablen enthalten sind) in die Prozedur ImposeJob eingefügt, bevor ein Datei-/Listenpaar aus dem Befehlssatz abgeholt und dieser gespeicherte Zustand wiederhergestellt wird, bevor das nächste Datei-/Listenpaar abgeholt wird. Insbesondere führt Blocks 653 den umdefinierten Operator save aus und speichert den gespeicherten Zustand in einer Variablen, die beispielsweise "SavedState" genannt wird. Die Blocks 654 und 656 holen dann ein Datei-/Listenpaar aus dem Befehlssatz und rufen zur Verarbeitung des Datei-/Listenpaares die Prozedur ImposeFile auf, wie oben beschrieben. Sobald jedoch die Prozedur ImposeFile die Bearbeitung der einzelnen Einträge im Datei-/Listenpaar abgeschlossen hat, holt Block 657 den in der Variablen SavedState gespeicherten Zustand ab und führt zur Wiederherstellung dieses Zustands den umdefinierten Operator restore aus. Der Block 657 initialisiert daher den virtuellen Speicher, bevor der Block 654 das nächste Datei-/Listenpaar aus dem Befehlssatz holt.
Die Blocks 650-662 der Prozedur ImposeJob, welche die Blocks 653 und 657 umfasst, können mithilfe des folgenden Codes implementiert werden:
Darüber hinaus wird, wie bereits weiter oben erläutert, der Polo-Operator erasepage aus Gründen der Kompatibilität mit optionalen Prozeduren durch Aufruf der Operatoren systemdict_gsave und grestore umdefiniert. Sämtliche verbleibenden Prozeduren des Ausschießens im laufenden Betrieb sind mit den optionalen Prozeduren kompatibel.

Claims

Verfahren zur Reproduktion von Druckerzeugnissen und Ergänzungen, welche aus folgenden Schritten besteht: (a) Veränderung einer Datenbank (108), welche variable Daten für Seiten im Druckerzeugnis enthält, dahingehend, dass sie Bezüge auf die Ergänzungen enthält, (b) Erstellen von Vorlagenseitendateien (130), wobei die Seitendateien feste Informationen sowie einen Platzhalter an jenen Stellen der Seite aufweisen, an denen die variablen Daten einzusetzen sind, (c) Erzeugen einer Druckbefehlsdatei (140) zur Festlegung der Verteilungsreihenfolge, nach welcher die Seiten und die Erfüllungsstücke zu reproduzieren sind, (d) Auswerten der Seiten und der Ergänzungen entsprechend der Druckbefehlsdatei, einschließlich Einfügen der aus der Datenbank gewonnenen variablen Daten in die Seiten an der Position des jeweiligen Platzhalters, sowie (e) Übertragen der Seiten und Ergänzungen nach der Verteilungsreihenfolge an ein Anzeigegerät (79).
Verfahren nach Anspruch 1, bei welchem das Anzeigegerät ein Anforderungs-Drucker ist, der die Seiten und die Ergänzungen druckt.
Ein Verfahren nach Anspruch 1, bei welchem das Anzeigegerät ein Computer ist.
Verfahren nach Anspruch 1, bei welchem die Seiten und die Ergänzungen in ein Computernetzwerk übertragen werden.
Ein Verfahren nach Anspruch 1, welches darüber hinaus den Vorgang des Anhängens der zu verteilenden Ergänzungen an die Seite an eine bestimmte Adresse umfasst.
Verfahren nach Anspruch 1, in welchem der Bezug auf eine Ergänzung in der Datenbank aus einem der Ergänzung entsprechenden Dateinamen besteht.
Verfahren nach Anspruch 6, bei welchem die Ergänzungen als QuarkXPress^®-Dateien erzeugt werden.
Verfahren nach Anspruch 1, bei welchem die Datenbank für jede Person einen Datensatz enthält, und bei welchem der Vorgang des Veränderns der Datenbank aus folgenden Schritten besteht: (i) Einfügen einer Spalte in die Datenbank für jede Ergänzung, sowie (ii) für jede Spalte, Einfügen eines Bezugs auf die Ergänzung für jede Person in jedem Datensatz.
Verfahren nach Anspruch 8, bei welchem der Vorgang des Erzeugens einer Druckbefehlsdatei aus folgenden Schritten besteht: (i) Erstellen einer separaten Druckbefehlsdatei für jedes Druckerzeugnis und jede Ergänzung, (ii) Für jeden Datensatz in der geänderten Datenbank, Kopieren der Druckbefehlsdatei für das Druckerzeugnis und der Druckbefehlsdatei für jede angeführte Ergänzung, sowie (iii) Zusammenführen der kopierten Druckbefehlsdateien in eine neue Druckbefehlsdatei.
Verfahren nach Anspruch 1, bei welchem der Vorgang des Änderns der Datenbank aus folgenden Schritten besteht: (i) Erstellen einer Steuerdatenbank, welche variable Daten für das Druckerzeugnis, einen Datensatz für jede Person und eine Spalte mit der eindeutigen Kennzeichnung jeder Person enthält, sowie (ii) Erstellen einer Ergänzungsdatenbank für jede Ergänzung, wobei jede Ergänzungsdatenbank variable Information für die Ergänzung, einen Datensatz für jede Person und eine Spalte mit der eindeutigen Kennzeichnung jeder Person enthält.
Verfahren nach Anspruch 10, bei welchem der Vorgang des Erzeugens einer Druckbefehlsdatei aus folgenden Schritten besteht: (i) Erstellen einer separaten Druckbefehlsdatei für jedes Druckerzeugnis und jede Ergänzung, (ii) Untersuchen der Steuerdatenbanken nach Identifikationsnummern sowie für jede Identifikationsnummer, Durchsuchen der einzelnen Ergänzungsdatenbanken nach Datensätzen, in welchen diese eindeutige Identifizierung enthalten ist, (iii) Für jeden Datensatz in den einzelnen Ergänzungsdatenbanken, der diese Identifikationsnummer enthält, Kopieren der mit der Identifikationsnummer verbundenen Druckbefehlsdatei, sowie (iii) Zusammenführen der kopierten Druckbefehlsdateien in eine neue Druckbefehlsdatei.
Verfahren nach Anspruch 1, welches darüber hinaus aus dem Vorgang des Einfügens einer Anzahl von leeren Seiten zu den Vorlagenseitendateien besteht, bei welcher die Anzahl der leeren Seitendateien einer Höchstanzahl von Seiten in der Ergänzung entspricht.
Verfahren nach Anspruch 12, bei welchem die Ergänzungen als QuarkXPress^®-Dateien erzeugt und im EPS-Format gespeichert werden.
Verfahren nach Anspruch 12, welches darüber hinaus das Einfügen einer Bildbox in jede hinzugefügte leere Seitendatei umfasst.
Verfahren nach Anspruch 14, bei welchem jede Bildbox entsprechend einem Spaltennamen in der geänderten Datenbank benannt wird.
Verfahren nach Anspruch 12, bei welchem die Datenbank für jede Person einen Datensatz enthält und jede Seite in den Ergänzungen einer benannten Datei gespeichert wird, und bei welchem der Vorgang des Veränderns der Datenbank ferner das Einfügen des Dateinamens der Seiten der Ergänzung für jeden Datensatz umfasst.
Verfahren nach Anspruch 1, bei welchem die Datenbank für jede Person einen Datensatz enthält und der Vorgang des Veränderns der Datenbank das Einfügen einer zusätzlichen Anzahl von Datensätzen für jede Person umfasst, wobei die Anzahl der zusätzlichen Datensätze pro Person der Anzahl der für diese Person bestimmten Ergänzungen entspricht.
Verfahren nach Anspruch 17, bei welchem zusätzliche Datensätze für die einzelnen Personen in der Reihenfolge der Verteilung in die Datenbank eingefügt werden.