DE102004021269A1

DE102004021269A1 - Verfahren, Vorrichtung und Computerprogrammprodukt zum Erzeugen eines seiten- und/oder bereichsstrukturierten Datenstroms aus einem Zeilendatenstrom

Info

Publication number: DE102004021269A1
Application number: DE102004021269A
Authority: DE
Inventors: Werner Dipl.-Inform. Engbrocks; Matthias Dr. Fromm
Original assignee: Oce Printing Systems GmbH and Co KG
Current assignee: Canon Production Printing Germany GmbH and Co KG
Priority date: 2004-04-30
Filing date: 2004-04-30
Publication date: 2005-11-24
Also published as: EP1749257A2; US20080158605A1; WO2005106641A3; WO2005106641A2

Abstract

In einem Verfahren, einer Vorrichtung und einem Computerprogrammprodukt zum Erzeugen einer Abbildungsvorschrift, mit der Eingangsdaten eines zeilenweise strukturierten Druckdatenstroms in Ausgangsdaten einer Ausgangs-Datenstruktur umsetzbar sind, wird eine vorgegebene, dem zeilenweise strukturierten Datenstrom zugeordnete Strukturbeschreibungsdatei verwendet.

Description

Die Erfindung betrifft ein Verfahren, eine Vorrichtung und ein Computerprogrammprodukt zum Erzeugen eines seiten- und/oder bereichsstrukturierten Datenstroms aus einem Zeilendatenstrom. Derartige Zeilendatenströme sind im digitalen Druckbereich vielfach verbreitet und insbesondere als Advanced Function Presentation (AFP) Line Data Stream, der von International Business Machine Corporation (IBM) entwickelt wurde oder als Line Coded Data Stream (LCDS) der von der Xerox Cooperation entwickelt wurde, ausgebildet.

Obwohl Zeilendatenströme, auch zeilendatenbasierte Druckdatenströme genannt, aus den Anfangszeiten des digitalens Drukkens stammen, in denen mit mechanischen Druckköpfen Zeichen nur zeilenweise ausgegeben werden konnten, werden entsprechende Druckanwendungen vielfach bis heute benutzt, weil sie mit großem zeitlichen und personellen Aufwand über Jahrzehnte hinweg gepflegt und weiterentwickelt wurden und der Aufwand für eine Neuentwicklung unangemessen hoch und mit Risiken von Fehlprogrammierung behaftet wäre. Deshalb werden solche Druckanwendungen, sogenannte Legacy-Anwendungen, bis heute noch vielfach verwendet, obwohl heute moderne Druckdatensprachen zur Verfügung stehen, die vielfältige Möglichkeiten der Dokumentenaufbereitung, Dokumentenformatierung und Dokumentenstrukturierung bieten.

Aus dem von der International Business Corporation (IBM) herausgegebenen Dokument S544-3884-02 „Advanced Function Presentation-Programming guide and Line Data Reference", dritte Ausgabe (Oktober 2000), die zum Beispiel unter http://publib.boulder.ibm.com/prsys/pdfs/54438842.pdf zugänglich ist, ist der Zeilendatencode beschrieben. In Kapitel 3 ist darüber hinaus beschrieben, wie aus dem ursprünglichen Zeilendatencode mittels der sogenannten Page-Definition-Datei (pagedef) ein Ausgangsdatenstrom erzeugt wird.

In der IBM-Veröffentlichung Nummer 5544-5284-06 mit dem Titel „IBM page printer for matting aid: user guide", siebte Ausgabe (Mai 2002) ist ein Computerprogramm beschrieben mit dem komplexe Pagedef-Dateien und entsprechende Seitenzuordnungsdateien (formdef-Dateien) erzeugt werden können, mit denen komplexe Dokumente produziert werden können. Von der Anmelderin ist ein entsprechendes Softwareprogramm unter der Bezeichnung Océ SLE (Smart Layout Editor) zur Erstellung von Formdef-Dateien und pagedef-Dateien bekannt.

Ausgabe und Kodierung der AFP Zeilendaten erfolgt häufig auf Großcomputern (Main Frames) in speziell dafür erstellten Anwendungen. 14 zeigt eine derartige Anwendung, bei der aus Daten einer Datenbank 130 in einer kundenspezifischen Anwendung ein Zeilendaten-Druckdatenstrom 134 erzeugt wird. Der Zeilendaten-Druckdatenstrom 134 wird dann im weiteren Verlauf mittels eines Aufbereitungsprogramms und unter Verwendung der Pagedef-Datei 132 und ggf. der Formdef-Datei 133 zu einem Ausgangsdatenstrom aufbereitet, der z.B. an ein Druckgerät oder an ein Archivsystem gesandt wird. Die Ressourcen Pagedef 132 und Formdef 133 rufen ihrerseits wiederum andere Ressourcen wie Font-Daten 135, Overlaydaten 136, Codepages 137 und Pagesegmente 138 auf.

Von der Anmelderin wird ein mit dem Handelsnamen PRISMAproduction^TM bezeichnetes Datenverarbeitungs-System für Hochleistungsdrucksysteme angeboten, welches in der Lage ist Druckdatenströme aus verschiedenen Anwendungen zu verarbeiten, unter verschiedenen Betriebssystemen wie MVS^TM oder Linux^TM zusammen zu tragen (spoolen) und in einen geräteorientierten Ausgangsdatenstrom wie zum Beispiel IPDS^TM (Intelligent Data Stream) umzuwandeln.

In den 2 und 3 sind bekannte Verfahrensweisen zum Verarbeiten von Druckdaten dargestellt. Die Druckdaten werden dabei von einer Druckdatenquelle 25 mit einem Musterdatensatz an einen Editor, wie z. B. den Smart Layout Editor (SLE), den die Anmelderin vertreibt, gesandt. Anhand dieses Musterdatensatzes wird das Layout (Formulare, Datenplatzierung, Schriften etc.) zum Ausdruck festgelegt und ein AFP-Ressourcen-Datenstrom mit einer Formdef-Datei und Pagedef-Datei erzeugt. Der AFP-Ressourcen-Datenstrom 27 umfaßt nur einige zig- bis maximal einige hundert Kilobyte und enthält Formulare, Schriften, Seiten-Definitionen und Form-Definitionen als Befehle. Der AFP-Ressourcen-Datenstrom 27 wird dann an einen Druckaufbereitungscomputer (Printserver) 28 gesandt und dort abgespeichert. Beim späteren Ausdrucken der Druckdaten werden diese über den Druckdatenweg 29 direkt an den Printserver 28 gesandt, welcher die Druckdaten wiederum mit dem AFP-Ressourcen-Datenstrom verbindet und daraus einen IPDS-Datenstrom generiert, der an ein oder mehrere Druckgeräte 31, 32 zum Ausdruck gesandt wird.

Dieser Verarbeitungsweise liegt also das Konzept zugrunde, daß eine Trennung zwischen den zu druckenden variablen Daten und dem Ressourcen-Datenstrom erfolgt. Vorteile dieser auf AFP beruhenden Verfahrensweise sind eine hohe Verarbeitungsgeschwindigkeit und ein hoher Kompressionsgrad, da die Ressourcen-Daten als relativ kleine Datei einmalig übermittelt werden können und der Großteil der Daten (Druckdaten) ohne belastende Zusatzinformationen, wie Layouts, Formulare, Fonts (Schriften) etc., von der Druckdatenquelle 25 direkt an den Printserver 28 gesandt werden kann.

Nachteilig bei diesem auf dem IBM-Produkt Page Printer Formatting Aid (PPFA) basierenden Verfahren ist, daß nur die in PPFA vorgesehenen Druckdaten und vorgegebenen Formatieringsprinzipien verwendet werden können. Personalisierte Dokumente können zwar durch sogenannte „conditional processing" erzeugt werden, hierzu muß aber für jede Verzweigung eine neue Dokumentenseite beschrieben werden. Dadurch wird die Applikationsgestaltung sehr langwierig und komplex. Insbesondere ist auf diese Art und Weise die Generierung von Kuchen- oder Balkendiagrammen nicht möglich. Dies wäre nur durch Sonderfunktionen in einem entsprechend erweiterten Druckertreiber möglich. Der Ausdruck solcher Applikationen wäre damit aber auf herstellerspezifische Systeme beschränkt, was relativ ungünstig wäre.

Ressourcen sind statisch, das heißt sie werden bei der Ausführung eines Druckauftrags weder generiert noch verändert. Weiterhin enthalten sie keine Druckdaten, beim Entwurf der Ressourcen können jedoch Druckdatenmuster verwendet werden.

In 3 ist eine Datenaufbereitung nach dem sogenannten Formatter-Prinzip dargestellt. Der komplette Druckdatenstrom wird dabei von der Druckdatenquelle 25 einem Formatter 35 zugeleitet, welcher ein Layout erstellt und die Layoutangaben, wie Formularangaben, Schriftformangaben und andere Formatangaben, direkt in den Druckdatenstrom integriert. Der komplette so aufbereitete Druckdatenstrom wird dann an den Printserver 28 gesandt und von diesem an einen Drucker 31, 32 weitergeleitet. Eine derartige Verarbeitungsweise entspricht vielen im sogenannten Small-Office Home-Office (SOHO)-Bereich eingeführten Verfahrensweisen. Beispielsweise werden Druckdaten in den Microsoft-Office-Produkten WinWord^TM, Access^TM und Excel^TM unter dem Betriebssystem Windows 2000^TM auf diese Weise verarbeitet.

Vorteilhaft bei dieser Art der Datenaufbereitung ist, daß praktisch beliebig komplexe Anweisungen bzw. Regeln in den Druckdatenstrom integriert werden können. Insbesondere sind Tabellen mit dynamischer Länge einschließlich Zwischen- und Endsummen möglich sowie die grafische Aufbereitung von Druckdaten durch Kuchen- bzw. Balkendiagramme etc. Der Darstellung von Druckdaten sind dabei prinzipiell keine Grenzen gesetzt. Zudem sind über Eingangsfilter unterschiedliche Druckdaten ladbar, u. a. auch sogenannte RDI-Daten von Datenbank-Programmen der Firma SAP AG, Walldorf, Deutschland.

Nachteilig bei dieser Verfahrensweise ist, daß der Druckdatenstrom durch die Formatierungsangaben sehr umfangreich wird und damit die Übertragung der Druckdaten von einem Computer an einen anderen Computer oder an den Drucker relativ lange dauert. Weiterhin muß die Druckaufbereitung für jeden Druckauftrag einzeln erfolgen. Computerprogramme, die dieses Prinzip auf AFP-Druckdaten anwenden, müssen für jeden Druckauftrag einen vollständigen AFP-Datenstrom erzeugen, auch wenn keine Dynamik erfolgen soll. Zum Ausdrucken sind diese AFP-Datenströme in entsprechende IPDS-Datenströme für die Druckgeräte umzuwandeln. Nachteilig ist dabei, daß kleinste Änderungen am Druckauftrag eine völlige Neugenerierung des AFP-Datenstroms erzwingen.

Um die im Vergleich zu formatterbasierten Lösungen sehr eingeschränkte Formatiermöglichkeit mittels Formdef- und Pagedef-Dateien wenigstens teilweise auszugleichen werden in Kundenanwendungen beispielsweise dynamische Grafiken direkt in den Zeilendaten-Druckdatenstrom eingebettet, spezielle Datenfelder zur Steuerung von „conditional processing" eingefügt und so weiter. Sowohl dadurch als auch durch Fonts mit kundenspezifischen Codepages entstehen mitunter komplexe Abhängigkeiten zwischen den Kundenanwendungen, der Formdef- beziehungsweise- Pagedef-Datei und den anderen, in Druckprozeß benutzten Ressourcen wie Fonts, Codepages, Overlays, Pageseg mente und so weiter. Dies führt dazu, daß Änderungen und Erweiterungen am Layout beziehungsweise an den Formdef- beziehungsweise Pagedef-Dateien sehr aufwendig und fehleranfällig sind.

Es ist daher ein Bedürfnis, für zeilendatengenerierende Anwendungen Möglichkeiten zu schaffen, möglichst ohne Änderung der Anwendung den Zeilendatenstrom beziehungsweise die zur Bildung des Zeilendatenstroms notwendigen Ressourcen statt wie bisher über die Formdef-Datei beziehungsweise die Pagedef-Datei über andere, zum Beispiel formatterbasierte Lösungen aufzubereiten und hierbei die vielfältigeren Möglichkeiten der Formatter ausschöpfen zu können.

In 16 sind die verschiedenen, bekannten Verfahrensabläufe zum Erzeugen von Dokumenten aus Datenbanken dargestellt. Die Datenbankdaten können dabei von der Datenbank 130 in einen Zeilendatengenerator 90 eines Host-Computers 3 eingespielt werden, der daraus einen Zeilendaten-Druckdatenstrom bildet. Dieser Druckdatenstrom wird im Host-Computer 3 in ein Auftragseingangs-System (Job Entry System, JES) eingespielt, von dem aus der Druckdatenstrom wahlweise einem Gerätetreiber 33 im Host-Computer 3 zugeführt werden oder einem Druckauftragssammelmodul 38 eines Druckservers 28. Von dem Gerätetreiber 33a wird der Druckdatenstrom in ein an das jeweils angeschlossene Gerät angepaßtes Format umgesetzt, beispielsweise in einen AFP bzw. MO:DCA-Druckdatenstrom für ein AFP-Datenarchiv 34 oder in einen IPDS-Druckdatenstrom für einen IPDS-Drucker 31. Wenn die Druckdaten dem Druckauftragssammelmodul 38 zugeführt worden sind, können die Druckaufträge wieder einem oder mehreren Geräten zugeführt werden, wobei ein oder mehrere Gerätetreiber 33b auf den Druckserver 28 verwendet werden. Die Ausgabe kann wiederum auf einem AFP-Datenarchiv 34 oder auf einem oder mehreren Druckgeräten 31 erfolgen.

Alternativ zu den oben beschriebenen Druckdaten-Verarbeitungsverfahren ist es bekannt, Datenbankdaten aus einer Datenbank 130 feldweise an ein Formatierungs-Computerprogramm 20a im Host-Computer oder an einen Formatierungs-Computer 20b im Druckserver 28 zu übertragen und dort mit Formatierungselementen zu versehen, so dass ein Ausgangs-Druckdatenstrom entsteht, der wiederum dem Auftragseingangs-System 39 im Host-Computer 3 bzw. dem Druckauftragssammelmodul 38 im Druckserver 28 zugeführt wird.

Von der Firma Elixir Technologies Cooperation, Ventura, CA (USA) ist ein Computerprogramm mit der Bezeichnung „Pageminer^TM" zur Extraktion von Daten aus legacy Druckdatenströmen bekannt geworden, bei dem die Nutzdaten aus AFP-Zeilendatenströmen gemäß speziell zu kodierender Regeln wieder extrahiert werden können und in einer separierten Werte-Datei abgespeichert werden können, so daß formatterbasierte Lösungen diese als Eingangdatenstrom verwenden können.

Der Erfindung liegt die Aufgabe zugrunde, eine Migration von Zeilendaten-Druckdatenströmen zu ermöglichen, die erweiterte Formatierungsmöglichkeiten erlaubt.

Diese Aufgabe wird durch die in den unabhängigen Patentansprüchen angegebene Erfindung gelöst. Vorteilhafte Ausführungsformen der Erfindung sind in den Unteransprüchen angegeben.

Gemäß einem ersten Aspekt der Erfindung wird in einem Verfahren zum Erzeugen einer Abbildungsvorschrift, mit der Eingangsdaten eines zeilenweise strukturierten Druckdatenstroms in Ausgangsdaten einer Ausgangs-Datenstruktur umsetzbar sind, eine vorgegebene, dem zeilenweise strukturierten Druckdatenstrom zugeordnete Strukturbeschreibungsdatei verwendet. Dabei kann insbesondere ein Design-Datensatz festgelegt werden, welcher der Ausgangs-Datenstruktur entspricht. Die Abbildungsvorschrift kann dann derart erzeugt werden, dass sie ei ne Abbildung zwischen Einträgen der Strukturbeschreibungsdatei und Einträgen des Design-Datensatzes beschreibt.

Gemäß einem zweiten Aspekt der Erfindung wird ein Verfahren zum Erzeugen eines seiten- und/oder bereichsstrukturierten Ausgangs-Datenstroms aus einem zeilenweise strukturierten Zeilendaten-Eingangs-Druckdatenstrom angegeben, wobei dem Zeilendaten-Eingangs-Druckdatenstrom eine Strukturbeschreibungsdatei fest zugeordnet ist. Dabei wird ein Design-Datensatz erzeugt, der die Ausgangs-Datenstruktur beschreibt, eine Abbildungsvorschrift zwischen der Strukturbeschreibungsdatei und dem Design-Datensatz gemäß dem oben genannten ersten Aspekt der Erfindung erzeugt und mittels der Abbildungsvorschrift aus dem zeilenweise strukturierten Zeilendaten-Eingangs-Druckdatenstrom der seiten- und/oder bereichsstrukturierten Ausgangs-Datenstrom erzeugt.

Gemäß einem dritten Aspekt der Erfindung, der in Kombination oder auch unabhängig von den beiden zuvor genannten Aspekten gesehen werden kann, wird zum Erzeugen eines seiten- und/oder bereichsstrukturierten Datenstroms aus einem zeilenweise strukturierten Zeilendaten-Druckdatenstroms aus Zeilendaten-Druckdaten des Zeilendaten-Druckdatenstroms unter Verwendung mindestens einer ihnen zugeordneten Strukturbeschreibungsdatei automatisch ein Automatik-Design-Datensatz erzeugt, in dem strukturell zusammengehörige Druckdaten und/oder ihnen zugeordnete Kenndaten seiten- und/oder bereichsweise strukturiert zusammengestellt sind. Weiterhin wird mittels eines Design-Datensatzes, der eine vorbestimmte Datenstruktur beschreibt und des Automatik-Design-Datensatzes eine Abbildungsvorschrift erzeugt, die die Abbildung von Daten des Automatik-Design-Datensatzes auf den Design-Datensatz beschreibt. Schließlich wird unter Verwendung des Design-Datensatzes, der Abbildungsvorschrift und der Zeilendaten-Druckdaten der seiten- und/oder bereichsstrukturierte Datenstrom erzeugt.

Die Erfindung beruht auf der Erkenntnis, daß ein seiten- und/oder bereichsstrukturierter Datenstrom als Eingangsdatenstrom für formatterbasierte Lösungen zum Aufbereiteten von Dokumenten-Datenströmen geeignet ist, beziehungsweise, daß aus einem solchen Datenstrom relativ leicht ein entsprechender Datenstrom wie zum Beispiel ein kommaseparierter Werte-Datenstrom erzeugt werden kann. Der seiten- und/oder bereichsstrukturierte Datenstrom beinhaltet dabei im wesentlichen Daten, die die variable Information von Dokumenten darstellen, wobei Feldbezeichnungen zur Erklärung des jeweiligen Datums eingeschlossen sein können, wobei aber insbesondere keine Formatierungsanweisungen wie Fonts, Positionsangaben und so weiter eingeschlossen sind. Das erfindungsgemäße Verfahren stellt insoweit insbesondere eine Vorstufe zum Erzeugen von Druck- und/oder Dokumentendatenströmen mittels Formatter dar. Insbesondere wurde erkannt, daß eine zur Formatierung von Zeilendaten verwendete Strukturbeschreibungsdatei wie zum Beispiel eine Formdef-Datei, eine Pagedef-Datei oder eine PPFA Skript-Datei eines Advanced Function Presentation Zeilendatenstroms, gegebenenfalls mit zugehörigen anderen Ressourcen zur Interpretation der Zeilendaten insoweit geeignet ist, daß die seiten- und/oder bereichsweise Datenstruktur der Zeilendaten ermittelt werden kann und daraus automatisch der automatisch generierte Designdatensatz erzeugt werden kann.

Der Erfindung liegen weiterhin die Erkenntnisse zugrunde, dass Pagedef-Dateien in AFP Line Data-Druckanwendungen vielfach das Layout der mit ihnen produzierten Dokumente bestimmen und dass sie dann als Strukturbeschreibungsdatei verwendet werden können.

Die Abbildungsvorschrift kann insbesondere in einer Regeldatei hinterlegt werden, die in einer produktiven Druckprozessphase automatisch aufgerufen und abgearbeitet wird. Der Design-Datensatz bezeichnet insbesondere eine Ausgabestruktur der Druckdaten und die Abbildungsvorschrift wird insbesondere mittels der Regeldatei in Anweisungen für einen Computer umgesetzt, der die Druckdaten verarbeitet. Zum automatischen Erstellen der Abbildungsvorschrift können insbesondere Heuristiken angewendet werden, die Druckanweisungen der Strukturbeschreibungsdatei und/oder ihnen zugeordnete Kenndaten exakt gemäß ihren tatsächlichen Aufrufen beim Abarbeiten von Zeilendaten des Eingangsdatenstroms analysieren und/oder interpretieren.

Durch die Erfindung, insbesondere durch die Nutzung einer dem Eingangs-Zeilendatenstrom zugeordneten Strukturbeschreibungsdatei wie einer Pagedef-Datei kann ein maximaler Kompatibilitätsgrad erreicht werden hinsichtlich der Druckergebnisse bei einem konventionellen Legacy-Zeilendatendruck und dem erfindungsgemäßen, Formatter-unterstützten Verarbeiten der Druckdaten, wobei die Formatter-basierten Lösungen in den Workflow integriert werden können, ohne dass aufwendige Änderungen an den Zeilendatengeneratoren nötig sind.

In einer Druckumgebung ist insbesondere vorteilhaft, dass die Zeilendaten-Druckdaten beim Bilden des seiten- und/oder bereichsstrukturierten Datenstroms exakt in der gleichen Folge verarbeitet werden wie bei ihrem standardmäßigen Ausdrucken.

Mit der Erfindung wird insbesondere die strukturmäßige Aufbereitung von Zeilendatenanwendungen vereinfacht, wobei das menschliche Eingreifen gegenüber bisher bekannten Verfahren vereinfacht ist und sich im wesentlichen auf die Angabe von Zuordnungsregeln beschränkt. Insbesondere ermöglicht die Erfindung eine anschauliche Zuordnung zwischen Musterdaten, die dem Automatik-Design-Datensatz entsprechen und dem Design-Datensatz.

Die Strukturbeschreibungsdatei umfaßt insbesondere eine Seitendefinitions-Datei und kann weiterhin eine Seitenzuordnungs-Datei umfassen. Diese können insbesondere eine AFP Formdef-Ressource beziehungsweise eine AFP Pagedef-Ressource sein. Diesen wiederum zugeordnete Ressourcen wie zum Beispiel Fonts, Codepages, Overlays und/oder Pagesegmente können ebenfalls zum Erzeugen des Automatik-Design-Datensatzes verwendet werden.

Feldpositionen, die in der Strukturbeschreibungsdatei angegeben sind, können insbesondere entsprechenden Datensätzen des Zeilendaten-Druckdatenstroms zugewiesen werden. Weiterhin ist es möglich, vor dem Erzeugen des strukturierten Datensatzes eine Zwischendatei zu erzeugen, in der inhaltlich und/oder strukturell zusammengehörige Zeilendaten-Druckdaten innerhalb einer Strukturklammer zusammengefaßt werden. Als Zeilendaten-Druckdaten können insbesondere Advanced Function Presentation Zeilendaten-Druckdaten verwendet werden.

Der Ausgangsdatenstrom kann insbesondere Unicode codiert sein. In einem bevorzugten Ausführungsbeispiel der Erfindung werden Codepages von Fontzuweisungen aus der Strukturbeschreibungsdatei auf Konsistenz mit der Unicode-Kodierung überprüft und Konflikte, insbesondere solche, die durch einzelfallspezifische Symbole oder normabweichende Belegungen der Codepages bestehen, durch codespezifische Abbildungen nach Unicode aufgelöst.

Als seiten- und bereichsstrukturtierter Duckdatenstrom kann insbesondere ein kommaseparierter Werte-Druckdatenstrom (CSV-Druckdatenstrom) und/oder ein Extensible Markup Language-Datenstrom (XML Datenstrom) erzeugt werden. Diese können wiederum insbesondere als Eingangsdatenstrom für einen Formatter verwendet werden, indem ein komplex formatierter Druckdatenstrom gebildet wird, welcher Struktur- und/oder Formatierungselemente enthält, die in Zeilendatenströmen nicht zur Verfügung stehen. Der Formatter fügt insbesondere solche Elemente dem Formatter-Eingangsdatenstrom hinzu. Sie können insbesondere von einer Bedienperson eingegeben oder ausgewählt werden.

Mit der Erfindung wird es insbesondere möglich, aus Zeilendaten-Druckdatenströmen, die aus einer Datenbankabfrage gebildet wurden, die ursprüngliche Datenbankstruktur zu rekonstruieren und damit einen optimalen Eingangsdatenstrom für formatterbasierte Verfahren zu bilden.

Eine erfindungsgemäße Vorrichtung ist zur Durchführung des erfindungsgemäßen Verfahrens eingerichtet. Ein erfindungsgemäßes Computerprogrammprodukt erzeugt bei seinem Laden und Ausführen auf einen Computer einen erfindungsgemäßen Verfahrensablauf.

In einer weiteren, vorteilhaften Weiterbildung der Erfindung wird aus einem Zeilendaten-Eingangsdruckdatenstrom direkt mit Hilfe der zuvor erzeugten Abbildungsvorschrift und der Strukturbeschreibungsdatei der Ausgangsdatenstrom erzeugt. Weiterhin kann es möglich sein, direkt aus der Strukturbeschreibungsdatei, insbesondere der pagedef-datei eines AFP-Zeilendatenstroms, Abbildungsvorschriften zu gewinnen, mit denen aus dem Zeilendaten-Eingangsdatendruckdatenstrom der seiten- und/oder bereichsweise strukturierte Ausgangsdatenstrom erzeugt werden kann.

Nachfolgend werden Ausführungsbeispiele der Erfindung anhand einiger Figuren näher erläutert.
Es zeigen:
1 ein Hochleistungsdrucksystem,
2 die bekannte Verfahrensweise zur Verarbeitung von Druckdaten gemäß den AFP- und IPDS Spezifikationen,
3 die bekannte Verfahrensweise zur Verarbeitung von Druckdaten gemäß dem sogenannten Formatter-Prinzip,
4 ein Verfahren zum Aufbereiten von Druckdaten mit zusätzlichen Struktur- und Formatierungselementen,
5 die Aufbereitung von Datenbank-Daten in einem Doku mentenverarbeitungssystem,
6 die Verarbeitung eines Musterdatensatzes und eines Applikationsdatensatzes,
7 verschiedene Druckdatenstrukturen,
8 verschiedene Druckdatenstrukturen,
9 Datenstrukturen der 7 mit Beispiel-Datensätzen versehen,
10 einen Zeilendaten-Druckdatenstrom,
11 automatisch erzeugte, mit Strukturelementen versehene Daten, die aus den Daten der 10 gewonnen wurden,
12 einen seiten- und bereichsstrukturierten Druckdatenstrom, der aus den Daten der 11 gewonnen wurde,
13 eine Softwarestruktur zum Erzeugen eines komplex formatierten Druckdatenstroms,
14 eine Legacy Anwendung,
15 einen verallgemeinerten Verfahrensablauf,
16 verschiedene bekannte Verfahrensabläufe zum Erzeugen von Dokumenten aus Datenbankendaten und
17 ein für den Menschen lesbar aufbereiteter Auszug aus einer Pagedef-Datei.
In 1 ist ein Dokumenten-Druckproduktionssystem 1 gezeigt, das zum einen eine Main-Frame-Architektur 2 umfasst und zum anderen eine Netzwerk-Architektur 5, in denen jeweils Dokumentendaten bzw. Dokumentendruckdatenströme mittels Anwenderprogrammen (Tools) erzeugt werden. In der Main-Frame-Architektur 2 werden diese Druckdaten von einem Host-Computer 3, z.B. als AFP-Druckdatenstrom oder als Zeilendruckdatenstrom, erzeugt. Vom Host-Computer 3 können die Druckdaten wahlweise über einen sog. S/370-Kanal 14a direkt an einen oder mehrere Druckgeräte 6a, 6b übertragen werden. Alternativ zu diesem Ausgabekanal können die Druckdaten auch vom Host-Computer 3 über ein Netzwerk 13 oder eine direkte Datenverbindung 14b zu einem Bearbeitungscomputer 4 übertragen werden, in dem die Druckdaten zwischengespeichert (z.B. in einem zugehörigen File-Server) und für nachfolgende Ausgabeschritte bearbeitet werden. In derartigen Host-Computern 3 werden insbesondere Druckdatenströme erzeugt, die aus größeren Datenbeständen (Datenbanken) regelmäßig Listen-Ausdrucke, Rechnungen, Verbrauchsübersichten (für Telefonrechnungen, Gasrechnungen, Bankkonten) etc. zusammenstellen. Derartige Anwendungen sind häufig bereits seit vielen Jahren im Einsatz und werden nach wie vor in mehr oder weniger unveränderter Weise benötigt (sog. Legacy-Anwendungen).
Innerhalb der Main-Frame-Architektur 2 wird der Druckproduktionsablauf von einem Überwachungssystem 7 überwacht. Es umfasst einen Überwachungscomputer 7a, der mit einer Datenbank 7b gekoppelt ist und verschiedene Computerprogrammmodule 7c enthält.
Das Überwachungssystem 7 ist über ein Gerätesteuerungsnetzwerk 15 und ein Printmanager-Modul 8 mit dem Host-Computer 3 verbunden sowie über einen Konverter 9 mit z.B. einer V24-Datenleitung, die an die beiden Druckgeräte 6a, 6b ankoppelt.
Der Konverter 9 setzt die V24-Signale in DMI-Protokollsignale des Gerätesteuerungsnetzwerkes 15 um. SNMP-Protokollsignale können dem Device Manager DM als DMI-Protokollsignale umgesetzt bereitgestellt werden bzw. direkt als SNMP-Protokollsignale übergeben werden.
Druckgut 19, das in den Druckern 6a, 6b aus dem Dokumenten-Druckdatenstrom erzeugt wurde und auf dem Barcodes aufgedruckt sind, kann jeweils mit einem manuell bewegbaren, funkgesteuerten Barcode-Leser 11a abgescannt werden. Die Signale werden per Funk an die Lesestation 10a übertragen und in das Gerätesteuerungsnetzwerk 15 bzw. an das Überwachungssystem 7 übermittelt. Als Barcode-Leser können Leser für eindimensionale und/oder zwei-dimensionale Barcodes eingesetzt werden, sodass verschiedene Barcode-Systeme mit ein und derselben Lesevorrichtung gelesen werden können. Das Barcode-Lesesystem ist insbesondere konfigurierbar, d.h., auf verschiedene, anwendungsspezifische Codes bzw. die jeweils geeigneten Kontrollverfahren anwendbar.
In der Netzwerk-Architektur 5 werden Dokumentendaten mittels Anwenderprogrammen in Client-Computern 12, 12a erzeugt, die über ein Client-Netzwerk 13 untereinander sowie mit dem Bearbeitungscomputer (File-Server) 4 verbunden sind. Der File-Server dient damit als zentrale Verarbeitungs- und Bearbeitungsschnittstelle für Druckdaten des gesamten Druckproduktionssystems 1. Auf ihm laufen diverse Steuerungsmodule (Softwareprogramme), durch die der gesamte Druckproduktionsablauf bzw. die gesamte Dokumentenbearbeitung anwendungsspezifisch, produktionstechnisch und gerätesteuerungsseitig an die jeweiligen Gegebenheiten optimal angepasst wird.
Im File-Server lassen sich Steuerungsdaten, die im Eingangsdatenstrom vom Host-Computer 3 bzw. Anwender-Computer 12 an den Bearbeitungscomputer 4 geliefert worden sind, dahingehend filtern, dass solche Steuerungsdaten, die bei der gegebenen Gesamtsystemanordnung nicht benötigt werden, entfernt werden. Durch die Verbindung aller beteiligten Ausgabegeräte (Drucker 6a bis 6d, Schneidegerät (Cutter) 18a, Kuvertiergerät 18b) über das Gerätesteuerungsnetzwerk 15, kann bereits im Bearbeitungscomputer 4 entschieden werden, welche Steuerungsdaten des Eingangsdatenstroms von keinem der angeschlossenen Geräte benötigt wird. Durch Entfernen dieser Daten aus dem Datenstrom kann der Datenstrom insgesamt reduziert werden, insbesondere dann, wenn lediglich leere Feldeinträge zu entsprechenden Steuerungsdaten im Eingangsdatenstrom enthalten sind.
Wenn im Zuge der Weiterverarbeitung der Daten, insbesondere bei der Ausgabe der Daten auf einem der Druckgeräte 6a, 6b, 6c oder 6d, in einem der Nachverarbeitungsgeräte 18a, 18b oder auch im Druckcomputer 16, ein Fehler auftritt, so kann dies durch das Überwachungssystem 7 anhand der im Bearbeitungscomputer 4 eingefügten Steuerungs-Barcodes festgestellt werden und der Nachdruck der von der Störung betroffenen Dokumente (Seiten, Blätter, Mail-Pieces) angefordert werden. Diese Wiederholungsdruck-Anforderung wird maßgeblich im Bearbeitungscomputer 4 gesteuert.
Druckdaten, die vom Bearbeitungscomputer 4 fertiggestellt wurden, werden über die Druckdatenleitung 14c an einen Druckserver 16 geleitet. Dessen Aufgabe ist es im wesentlichen, den Bearbeitungscomputer 4 zu entlasten. Dies erfolgt durch Zwischenspeicherung der fertiggestellten Druckdaten bis zu deren Abruf über die Datenleitung 14d an einen oder beide Drucker 6c, 6d. Der Druckserver 16 ist somit in erster Linie aus Gründen der Performance (Geschwindigkeits) im Gesamtsystem integriert. Bei Systemen, deren Druckgeschwindigkeit weniger groß ist, kann auf den Druckserver 16 auch verzichtet werden.
Dokumentendaten, die an die Drucker 6c bzw. auf eine 6b übermittelt und dort auf einen Aufzeichnungsträger (z.B. Papierbahn) gedruckt werden, werden im Gesamtsystem weiteren Bear beitungsstufen, nämlich dem Schneidegerät 18a und dem Kuvertierungsgerät 18b der weiteren Verarbeitung zugeführt. Damit ist der Druckproduktionsprozess abgeschlossen.
Die gedruckten Dokumente werden auf ihrem Verarbeitungsweg zwischen dem Druckgerät 6 und dem letzten Nachverarbeitungsgerät 18b hinsichtlich verschiedener Kriterien mit einem Testsystem 17 getestet, nämlich durch ein optisches Testsystem 17a hinsichtlich ihrer optischen Druckqualität, mit einem Barcode-Testsystem 17b hinsichtlich ihres Vorhandenseins, ihrer Konsistenz und/oder ihrer Reihenfolge sowie mit einem MICR-Testsystem 17c, sofern der Druck mittels magnetisch lesbarem Toner (Magnetic Ink Character Recognition Toner) gedruckt wurde. Die vom Testsystem 17 gelieferten Daten der verschiedenen Testsysteme werden von einem gemeinsamen seriellen Datenerfassungsmodul (Serial Data Aquisition Modul) 17d an das Gerätesteuerungsnetzwerk 15 übermittelt und dem Überwachungssystem 7 zugeführt. Dort werden die jeweiligen Systemdaten erfasst und in Echtzeit die Geräte überprüft sowie die jeweiligen Positionen der Dokumente hinsichtlich ihrer Korrektheit bezüglich des Druckauftrages getestet.
Die fertig gedruckten Dokumente 23 können wiederum mit einem Barcode-Leser 11b erfasst werden, der z.B. funkgesteuert mit einer zugehörigen Steuerungseinrichtung 10b verbunden ist, welche wiederum über das Gerätesteuerungsnetz 15 ihre Daten an das Überwachungssystem 7 liefert.
In 4 ist ein Verfahren zum Aufbereiten von Druckdaten mit zusätzlichen Struktur- und Formatierungselementen dargestellt, wie es in der deutschen Patentanmeldung Nr. 102 50 842.9 bzw. in dazu korrespondierenden Anmeldungen beschrieben ist. Der Inhalt dieser Patentanmeldungen wird hiermit durch Bezugnahme in die vorliegende Beschreibung aufgenommen.
Mit Hilfe des Layout-Editors werden dabei statische Ressourcen anhand eines vollständigen Druckdatenmusters erstellt.
Dies sind die im AFP-Datenstrom bekannten Standardressourcen, wie Overlays, Pagesegmente, Fonts, Pagedef- und Formdef-Dateien. Druckdaten, die jedoch mittels der standardmäßig im AFP-Funktionsspektrum angebotenen Formatierungen nicht enthalten sind, werden jedoch nicht in eine AFP-Ressourcen-Datei geschrieben sondern in eine erweiterte, alle variablen Druckdaten enthaltende Druckdaten-Datei. Diese Datei wird zur individuellen Gestaltung mit besonderen Formatierungs-Elementen, z. B. grafischen Elementen wie Kuchendiagrammen oder Balkendiagrammen herangezogen. Dazu ist der Editor 26 derart erweitert, daß solche Formatierungen durchgeführt werden können. Das Grundkonzept der AFP-Datenstruktur, nämlich die Datentrennung zwischen variablen und statischen Daten wird dabei dennoch weitgehend beibehalten. Vom Formatter-Prinzip wird beibehalten, daß die Druckdaten vollständig an eine Zwischenstufe übertragen werden. In dieser Zwischenstufe werden – wie bei der Verarbeitung von AFP-Druckdaten vorgesehen – den Druckdaten Ressourcen zugeordnet und somit Formulare, Schriften etc. vereinheitlicht und in einen relativ kleinen AFP-Ressourcen-Datenstrom umgesetzt. Dieser Ressourcen-Datenstrom wird über einen AFP-Kanal 36 übertragen.
Weiterhin werden aus den variablen Druckdaten diejenigen Daten herausgesucht, die bereits anderweitig formatiert sind oder bei denen keine performante Umwandlung bzw. Zuordnung von AFP-Ressourcen möglich ist. Diese Druckdaten werden dementsprechend um die benötigten Befehle erweitert (Data Enrichment). Diese Druckdatenerweiterung findet in einer sogenannten Design-Phase mittels eines geeigneten Editors statt, in dem entsprechende Musterdatensätze bzw. Automatik-Design-Datensätze untersucht werden und entsprechende Zuordnungen getroffen werden. Beispielsweise könnte eine Datentabelle herangezogen werden und der Befehl zugeordnet werden, daß aus den in der Datentabelle stehenden Zahlen ein Kuchendiagramm als grafisches Element zu erzeugen ist. Als Editor kann wahlweise ein geeignetes neues Computerprogramm zur Verfügung gestellt werden oder ein bereits bestehender Editor für eine bestimmte Drucksprache, beispielsweise ein AFP-Editor, wie der oben erwähnte Smart Layout Editor (SLE) der Anmelderin, um entsprechende Funktionen erweitert werden.
In einer produktiven Phase, das heißt während der variable Druckdatenstrom von der Datenquelle 25 an den Druckserver oder direkt an eines der Druckgeräte 31, 32 übertragen wird, wird der entsprechend erweiterte Druckdatenstrom über den Datenkanal 37 an den Druckserver bzw. Drucker gesandt. Im Druckserver 28 bzw. Druckgerät 31, 32 wird der aufbereitete Druckdatenstrom mit den einmalig übertragenen AFP-Ressourcen kombiniert und schließlich der so kombinierte Datenstrom an den Drucker als IPDS-Datenstrom gesandt. Ein Ausdruck kann auch als Telefax an ein Faxgerät erfolgen, die Daten über einen E-Mail-Computer, beispielsweise über den Client-Computer 12 als E-Mail versandt werden oder über einen www-Server in das Internet gestellt werden.
Somit ist es einerseits möglich, Standard-Daten performant zu übertragen, weil diese Daten nicht durch Formatierungsanweisungen überladen sind und andererseits, diejenigen Datenformate, welche nicht oder nur umständlich in AFP beschreibbar sind, einfach und schnell an den Druckserver zu übertragen.
Bei der oben beschriebenen Verfahrensweise ist vorgesehen, die aus AFP-Umgebungen bekannte Verarbeitungsweise um mindestens eine Funktionalität zu erweitern, durch die innerhalb der Druckdaten Formatierungsanweisungen, wie die Darstellung grafischer Daten, z.B. der Umwandlung in Kuchen- bzw. Balkendiagramme oder der Hinzufügung von Komponenten, wie Barcodes, Bilder und anderer Objekte übertragen werden können.
Ein Vorteil der beschriebenen Lösung ist dabei einerseits die Arbeitskompatibilität zu den bekannten Umfeldern und zum andern die Möglichkeit, bestehende, immer wiederkehrende Druckaufträge weiterhin verwenden zu können. Somit kann eine 100%-ige Abwärtskompatibilität des Verfahrens in Druckproduktion sumgebungen gewährleistet werden. Druckdatenströme, die unter früheren Editoren erzeugt wurden, wie z. B. Zeilendatenströme (Line Data Streams) können weiterhin direkt über ein erweitertes Layout bzw. Editormodul an den Printserver bzw. Drukker übertragen werden. Dazu wird lediglich eine früher erzeugte pagedef-Datei in ein Dokument-Template übernommen.
In 5 ist gezeigt, wie Computerprogrammprodukte so zusammenwirken, daß Daten, die aus einer SAP-Datenbankanwendung stammen, mit Formatierungsinformationen aufbereitet und in einem Druckproduktionssystem so aufbereitet werden, daß sie an ein Druckgerät gesandt werden können. Von der SAP-Datenbankanwendung 40 werden SAP-spezifische RDI-Druckdaten über ein Ausgabedaten-Managementsystem 41 (Output Management System) und eine SAP-Schnittstelle 42 (SAP Connector) an ein Druckproduktionssystem 43 gesandt. Dort werden Druckaufträge von einem Auftragsverteilungssystem 44 (Order Distribution System) für die weitere Verarbeitung verwaltet. Jeder Druckauftrag wird dabei mittels eines Druckauftragsmanagers 45 (Printjob Manager) individuell gekennzeichnet und mit Druckauftragsdaten, beispielsweise für einen gewünschten Ausgabedrucker oder einer gewissen Priorität, versehen. Diese Daten stehen in einer Druckauftrags-Begleitdatei 46 (Jobticket). Zur Aufbereitung von Druckdaten aus einer Anwenderdatenbank dient ein Datenerweiterungs-Modul 47. Dieses umfaßt zwei Computerprogramm-Module 48, 49, die zu verschiedenen Zeitpunkten benötigt werden.
In einer Datenvorbereitungsphase werden die Daten eines Musterdatensatzes aus einer Anwendungsdatenbank 50 (z.B. SAP Datenbank) herangezogen und mittels des Designer-Moduls 48 geeignete Formatierungs- und sonstige Ergänzungsdaten an den Musterdatensatz angehängt, um diesen nach Wunsch eines Anwenders aufzubereiten. Geeignete Erweiterungsdaten 51 werden dann über das Auftagsverteilungssystem 44 an das Dokumenten-Generator-Computerprogramm 49 übermittelt. Mit dem Dokumenten-Generator-Computerprogramm 49 werden zudem die RDI-Daten sowie die zugehörigen Formatierungsdaten in ein internes vorgegebenes, an ein Drucksystem gekoppeltes oder von einem Anwender ausgewähltes Druckdatenformat umgewandelt. Die Umwandlung kann dabei z. B. in einen AFP-Datenstrom, einen PCL-Datenstrom, einen PostScript-Datenstrom oder auch einen PDF-Datenstrom erfolgen.
Das Computerprogramm-Modul 49 verwendet die Erweiterungsdaten in einer zweiten Verarbeitungsphase, in der die vollständigen Datenbankdaten von der SAP-Datenbankanwendung 40 über die SAP-Schnittstelle 42 übermittelt werden, Datensatz für Datensatz mit den Erweiterungdaten anzureichern. Auf diese Weise entstehen personalisierte Dokumente 52, die über das Auftragsverarbeitungssystem 44 als Druckdateien 53 an ein Sammelprogramm 54 (Spool) oder als direkte Druckdaten über ein Druckertreiber-Modul 56 an einen Drucker (in 5 nicht gezeigt) ausgegeben werden.
In 6 sind die Datenverarbeitungsvorgänge dargestellt, die einerseits in der Vorbereitungsphase (Design-Phase) und andererseits in der produktiven Phase (Druckphase) durchgeführt werden um Druckdaten aus beliebigen Quellen aufbereiten zu können. Ein Probedatensatz bzw. ein Probedokument 60, das aus dem Zeilendaten-Datenstrom stammt, wird zur Design-Phase über ein Import-Modul 61 als Design-Datensatz 62 in das Designer-Computerprogramm 48 geladen. Anhand dieses Programms 48 werden beliebige Formatierungs- bzw. Ergänzungs Informationen zu dem Design-Datensatz 62 hinzugefügt und somit die Design-Informationsdatei 63 gebildet. In der Design-Phase wird ausserdem mittels der pagedef-Datei und Musterdaten automatisch ein Automatik-Design-Datensatz gebildet und manuell, teilautomatisch oder vollautomatisch anhand eines logischen Vergleichs des Automatik-Design-Datensatzes und des Design-Datensatzes 62 eine Abbildungsvorschrift erzeugt.
Zur Druckphase werden Applikations-Datensätze 64 des Zeilendaten-Druckdatenstroms Datensatz für Datensatz eingelesen und mittels eines Übersetzungs-Computerprogramm-Moduls 65 des Dokumenten-Generator-Computerprogramms 49 in ein internes Datenformat 66 übersetzt. Der Translator 65 bildet mittels der in der Design-Phase gewonnenen Abbildungsvorschrift bzw. der diese Abbildungsvorschrift enthaltenden Regeldatei aus dem Applikations-Datensatz 64 den Applikations-Datensatz im internen Datenformat 66, auf das dann ein Computerprogramm-Modul "Formatter" des Dokumenten-Generator-Computerprogramms 49 unter Verwendung der Design-Informationsdatei 63 angewandt wird.
Das Formatter-Computerprogramm-Modul 67 erzeugt aus den Druckdaten im internen Datenformat und den durch den Design-Prozeß definierten Formatierungsvorschriften, die in der Design-Informationsdatei 63 hinterlegt sind, das personalisierte Dokument 68. Ein Datentransformations-Modul 69 (AFP-Transformer) wandelt die personalisierte Dokumentendatei 68 in eine Druckdatei 70 um.
In 15 ist der oben beschriebene Verfahrensablauf nochmals verallgemeinert dargestellt. Zur Umwandlung der Eingangsdaten 105 in die normierten Daten 104 dient ein Übersetzungsstufenmodul 94, das von der Regeldatei 77 gesteuert wird. Die Regeldatei 77 enthält Abbildungsvorschriften in Form von Mapping-Regeln, die in der Design-Phase aus den Eingangsdokumentendaten 105 bzw. aus dem daraus abgeleiteten Automatik-Design-Datensatz und dem ebenfalls erstellten Design-Datensatz 62 und ggf. aus eingangsdatenspezifischen Hilfsdateien 119 gebildet wurden. Sowohl der Design-Datensatz 62 als auch die Regeldatei 77 können frei editierbar sein. Der Design-Datensatz 62 kann bei der Bildung eines Dokumententemplates 112 verwendet werden, das die Formatierung des normierten Datenstroms 104 (in Stufe 113) steuert. Wie mit den Pfeilen A₁ und A₂ dargestellt, kann der Design-Datensatz 62 und aus diesem die Regeldatei 77 auch aus dem Dokumententemplate 112 erzeugt werden.
Die in der Regeldatei 77 angegebenen Mapping-Regeln sind spezifisch für den Eingangsdokumentendatenstrom 105. Sie geben an, welches Element des Eingangsdokumentendatenstroms 105 zu welchem Element des Design-Datensatzes zuzuordnen ist. Der Design-Datensatz 62 enthält die Strukturdefinition der normierten Daten, wobei Typ-Deklarationen vorgesehen sind für verschiedene Strukurelemente, z.B. für Kundennummern, Namen, Logos, Bilder usw. In den normierten Rohdaten 104 können dann auch Datengruppen gebildet werden, die zusammengehören, insbesondere all diejenigen Daten, die zu einem Dokument gehören. Somit sind für jedes Dokument alle dazugehörigen Daten im normierten Rohdatenstrom 104 verfügbar. Ein Dokumenten-Template 112 dient als Strukturvorlage für die zu erzeugenden Dokumente und beschreibt, welche Formatierungsanweisungen im normierten Datenstrom hinzuzufügen sind. Es kann Elemente aus dem Design-Datensatz 62 enthalten und/oder frei programmierte statische oder dynamische Elemente 96 93, 15 enthalten. Das Dokumenten-Template 112 ist somit dokumentenformatierungsabhängig und dient dazu, die Formatbildungseinrichtung 113 (Formatter oder document composition engine) zu steuern.
Aus dem normierten Rohdatenstrom 104 wird durch die Formatierungsbildungseinrichtung 113 dokumentenweise ein ressourcenorientierter Datenstrom gebildet. Soweit bereits in den Rohdaten Formatierungen enthalten waren, werden diese beibehalten und soweit die Rohdaten unformatiert sind und im Dokumenten-Template zu den entsprechenden Datenfeldern Formatierungsangaben enthalten sind, werden diese ressourcenorientiert in der Formatbildungseinrichtung 113 hinzugefügt, wobei Ressourcen, die mehrfach innerhalb eines Datenstromes benötigt werden performanceoptimiert weiterverarbeitet werden, d.h., daß sie im ressourcen-orientierten Datenstrom hauptsächlich durch Aufrufen der Ressourcen eingefügt werden, wobei die Ressourcen selbst nur einmal intern vorhanden sind, oder extern von einer Ressourcen-Datei geladen oder auch nur referenziert werden können. Zur Bearbeitung von Dokumenten-Template 112, Design-Datensatz 62 und Regeldatei 77 kann es vorteilhaft sein, diese Dateien in der Weise zu koppeln, daß eine Veränderung in einer der Dateien zu einer Konsistenz-Prüfung und ggf. Modifikation in den beiden anderen Dateien führt.
Der formatierte Dokumentendatenstrom 114 wird dann einer Bakkend-Einrichtung 118 zugeführt, in der er in den durch eine Ausgabeselektionsdatei 119 gesteuerte Ausgabesprache wahlweise als Druckdatenstrom 120 oder über eine Schnittstelle 121 für ein Ausgabegerät (Telefax, email-Server, www-Server, Monitor) aufbereitet wird. Desgleichen kann der normierte Datenstrom 104 und/oder der formatierte Datenstrom 114 bereits gerätespezifisch optimiert werden. Details hierzu sind in der WO-A2-01/78000 beschrieben, die hiermit durch Bezugnahme in die vorliegende Beschreibung aufgenommen wird.
In den 7 bis 13 und 17 wird das Verfahren zum Erzeugen eines seiten- und/oder bereichsstrukturierten Datenstroms aus einem zeilenweise strukturierten Zeilendaten-Druckdatenstrom näher erläutert. In 7a ist ein zeilenweise strukturierter AFP-Zeilendaten-Druckdatenstrom strukturell gezeigt, wobei die Zeilendaten (Line 01, Line 02,...) 80 zeilenweise strukturiert aufeinanderfolgen. Den AFP Zeilendaten ist eine Strukturbeschreibungsdatei „Pagedef" zugeordnet, die beim Ausdrucken der Zeilendaten 80 die Anordnung der jeweiligen Daten auf der Seite festlegt. Verwendet man diese Pagedef-Datei, kann aus den zeilenweise strukturierten Zeilendaten 80 anhand der Anweisungen aus der Pagedef-Datei automatisch eine neue Datenstruktur 81 erzeugt werden, in der einerseits zusammengehörige Seitengruppen sowie einzelne Seiten dargestellt werden, und andererseits innerhalb jeder Seite die aus der Pagedef-Datei stammenden Zeilendiskriptoren (LND) den jeweiligen Feldern aus der Zeilendatenstruktur zugeordnet sind. Anhand dieses seitenweisen Aufbaus der Datenstruktur läßt sich dann mittels von einem Bediener eingegebenen oder ausgewählten Daten eine Regeldatei (Zuordnungsdatei) bilden, mit der aus dem seitenweise strukturieren Datenstrom 81 ein bereichsweise strukturierter, mit Feldkennungen 82 (Customer, Street, City,...) versehener endgültig gekennzeichneter Datenstrom mit der in 7c gezeigten Struktur 82 erzeugt werden kann, bei dem jeder Feldkennung ein Feld des Eingangsdatenstroms 80 zugeordnet ist.
Die automatisch erzeugte, gekennzeichnete Datenstruktur 81 ist ein erstes Ausführungsbeispiel für einen automatisch erzeugten Design-Datensatz. Sie enthält im vorliegenden Fall v.a. Feldnamen als Information. Sie kann jedoch zusätzliche weitere Kenndaten enthalten wie z.B. Fontinformationen und Positionsinformationen, die insbesondere aus der pagedef-Datei gewonnen werden können. Die automatisch erzeugte, gekennzeichnete Datenstruktur 81 bzw. der automatisch erzeugte Design-Datensatz gibt Strukturinformationen der pagedef-Datei wieder, insbesondere im Hinblick auf Datenfelder, die erkannt werden müssen.
Während die automatisch erzeugte, gekennzeichnete Datenstruktur 81 hinsichtlich der Dateninhalte strukturlos ist, weist die endgültig gekennzeichnete Datenstruktur 82 eine inhaltliche Struktur auf. Im vorliegenden Beispiel entspricht die inhaltliche Struktur einer Flugübersicht eines Fluggastes, wobei verschiedene inhaltliche Strukturkriterien durch die Feldnamen „Customer", „Street",... „Connection",... „Flight NO" usw. repräsentiert werden.
Die endgültig gekennzeichnete Datenstruktur 82 stellt einen strukturierten Musterdatensatz dar, in dem strukturell zusammengehörige Zeilendaten-Druckdaten bereichsweise inhaltlich strukturiert zusammengestellt sind. Anhand dieses Musterdatensatzes und der Zeilendaten-Druckdaten kann dann der seiten- und/oder bereichsstrukturierte Datenstrom erzeugt werden, der als Eingangsdatenstrom für einen Formatter geeignet ist.
In 8 ist eine ähnliche Datenstromstruktur dargestellt wie in 7, wobei dort die Zeilendaten 80a durch die Strukturbeschreibungsdatei (Pagedef) in zwei Seitentypen aufgeteilt wird und wobei in jedem Seitentyp unterschiedliche Zeilendiskriptoren zum Einsatz kommen. Dadurch kann z. B. bewirkt werden, daß beim Seitentyp 1 jeweils Name und Anschrift des Flugkunden wiedergegeben werden, während beim Seitentyp 2 nur die Kundennummer und die Flugverbindungen angegeben sind, aber nicht der Kundenname usw. Die Datenstruktur 82a des Musterdatensatzes, die die inhaltliche Struktur wiedergibt, ist dabei jedoch identisch zur entsprechenden Datenstruktur 82 der 7. Die automatisch erzeugte, markierte Datenstruktur 81a ist ein weiteres Ausführungsbeispiel für einen automatisch generierten Design-Datensatz.
In 9a ist ein Zeilendatenstrom 83 dargestellt, der für Herrn Heinz Mustermann drei Flugverbindungen, München – Singapur, München – New York und München – Wien enthält. Aus der Interpretation der zugehörigen Pagedef wird automatisch der gekennzeichnete Datenstrom 84 erzeugt, wobei jedem Datum des Zeilendatenstroms 83 der entsprechende Zeilendiscriptor (LND) der Pagedef zugeordnet ist, die dieses Zeilendatum verarbeitet. Zusätzlich ist im Datenstrom 84 die Seitenstruktur gekennzeichnet (9b). In 9c ist der inhaltlich und bereichsweise strukturierte Datenstrom 85 dargestellt, der aus dem automatisch erzeugten, gekennzeichneten Datenstrom 84 sowie einer Regeldatei gebildet wird, welche die jeweilige Abbildungsvorschrift der Datenfelder sowohl zu einem Feldnamen als auch zu einem oder mehreren Gruppennamen (Customer, Connection) enthält. Die Regeldatei wird vollautomatisch, teilautomatisch oder manuell erzeugt, wobei vorzugsweise die Datenstruktur des Automatik-Design-Datensatzes verwendet wird. Im vorliegenden Beispiel ist erkennbar, dass eine Flugverbindung jeweils acht Einträge hat, d. h. jeder neunte Eintrag wiederum eine neue Flugverbindung darstellt. Zur Erkennung einer solchen Struktur kann genauso gut auch nach gewissen Kanalsteuerzeichen gesucht werden, beispielsweise das Kanalsteuerzeichen 1, welches bedeutet, dass ein neues Dokument beginnt. Sobald für alle Bereiche des Datenstroms derartige Regeln bzw. Triggermechanismen zur Erkennung der Bereiche festgelegt worden, kann aus einem Zeilendaten-Druckdatenstrom direkt ein inhaltlich bereichsstrukturierter Datenstrom automatisch erzeugt werden. Um sicherzustellen, dass alle denkbaren Datenkonstellationen, die mit einer vorgegebenen Strukturbeschreibungsdatei zu verarbeiten sind, in einen inhaltlich bereichsstrukturierten Datenstrom umgesetzt werden können, kann insbesondere maschinenunterstützt geprüft werden, ob alle Formatierungsvorschriften, insbesondere Zeilendiskriptoren, der Strukturbeschreibungsdatei zu einer entsprechenden Bereichserkennungs- bzw. Gruppenerkennungsregel in der Regeldatei umgesetzt worden ist.
In 9c ist ein entsprechender, inhaltlich bereichsstrukturierter Datenstrom 85 gezeigt, der mit der entsprechenden Regeldatei direkt aus dem Eingangszeilendatenstrom 83 erzeugt werden kann.
Zum Erzeugen des automatisch generierten Designdatensatzes wird als Strukturbeschreibungsdatei insbesondere eine Seitendefinitionsdatei wie z. B. eine an sich übliche und z.B. aus den in der Einleitung genannten Dokumenten des Stands der Technik bekannte Pagedef-Datei oder eine entsprechende Skript-Datei aus einem Seitenformatierungstool wie dem IBM-Page Printer Formatting Aid verwendet. Zusätzlich können ihnen zugeordnete Ressourcen wie Fonts, Codepages oder Pagesegmente verwendet werden sowie eine Seitenzuordnungsdatei wie ein AFP Formdef, ggf. mit ihr zugeordneten Ressourcen wie Fonts, Codepages, Overlays oder Pagesegmente verwendet werden.
In 10 ist ein etwas komplexerer Zeilendatenstrom 83a dargestellt, bei dem zusätzlich zu verschiedenen Verbindungen eines Fluggastes noch Daten von anderen Fluggästen enthalten sind.
Die 11a, 11b und 11c zeigen, wie mittels einer entsprechenden Seitenbeschreibungsdatei eine Seitenstruktur erzeugt wird, bei der für jede Person eine neue Seite begonnen wird und die Flüge einer Person auf einer oder mehreren Seiten dargestellt sind.
In dem Zeilendatenstrom 83a benutzte, kundenspezifische Codepages können im Zuge der Bildung des seiten- und/oder bereichsweise strukturierten Datenstroms umkodiert, zum Beispiel nach Unicodes konvertiert werden. Weiterhin können grafische Objekte, Bilder und so weiter in entsprechend typisierte, normierte Nutzdatenfelder des seiten- und/oder bereisweise strukturierten Datenstroms konvertiert werden.
In den 12a, 12b und 12c ist der endgültig gekennzeichnete Datenstrom 85a dargestellt, der aus dem Zeilendatenstrom 83a gebildet wird und gruppenweise bereichsweise strukturiert ist. Das Feld „Customer" enthält dabei jeweils Anrede, Vorname und Nachname des Fluggastes und wird jeweils mit diesen drei Angaben als ein Feld geführt. Ein derartiges kombiniertes Feld kann jedoch jederzeit in seine Einzelbestandteile zerlegt werden und somit aus einem solchen Feld mehrere Felder erzeugt werden, die jeweils einem entsprechenden Eintrag in einer Datenbank entsprechen. Der Datenstrom 85a dient für die weitere Verarbeitung als Eingangsdatenstrom eines Formatters.
In 13 ist ein Ausführungsbeispiel dargestellt, bei dem ein Zeilendaten-Druckdatenstrom mittels eines Zeilendatengenerators aus einer Datenbank 130 erzeugt wird, mit den zuvor beschriebenen Maßnahmen einem Zeilendaten-Vorprozessor 91 zugeführt wird, in dem der Zeilendaten-Druckdatenstrom zu einem seiten- und/oder bereichsstrukturierten Datenstrom umgewandelt wird und dieser Datenstrom einem Formatter 92 zugeführt wird, in welchem dem Datenstrom zusätzliche Formatierungselemente hinzugefügt werden. Der so vollständig formatierte Datenstrom wird dann einem Ausgabegerät 93 zugeführt, wobei dem Datenstrom verschiedene Ressourcen 94 wie Overlays und Fonts hinzugefügt werden können. Diese Ressourcen können mit bekannten Ressourcegeneratoren 95 erzeugt werden und werden zudem genutzt um den Zeilendaten-Vorprozessor 91 zu steuern (Linedata Import Dialog) und das im Formatter 92 erzeugte Layout zu steuern (Layout Import Dialog).
In 14 ist eine sogenannte Legacy Anwendung dargestellt, bei der AFP Zeilendaten-Druckdaten 134 in einer kundenspezifischen Anwendung 131 erzeugt werden, wobei Rohdaten aus einer Datenbank 130 entnommen und zeilen- und/oder seitenorientiert ausgegeben werden. Zusätzlich werden Begleitdateien wie eine Pagedef-Datei 132 und eine Formdef-Datei 133 und ggf. weitere Ressourcen wie Fonts 135, Overlays 136, Codepages 137, Pagesegmente 138 und so weiter bereitgestellt. Wenn aus dem Zeilendaten-Druckdatenstrom 134 ein Ausgabedruckdatenstrom erzeugt werden soll, z.B. zur Ausgabe auf einem Druckgerät oder in ein Archiv, dann werden die Zeilendaten mit den Begleitdateien bzw. Ressourcen mittels eines Aufbereitungsprogramms 104 wie z.B. dem eingangs genannten Programm Océ PRISMAproduction^TM wieder zusammengeführt bzw. kombiniert.
In 17a ist ein für den Menschen lesbar aufbereiteter Auszug aus einer Pagedef-Datei „P1 redbar" dargestellt, mit der eine Legacy-Druckdatenanwendung aus den in 7 bis 12 dargestellten Zeilendaten erzeugt wird. In der ersten Spalte 100 des Auszugs sind die fortlaufenden Nummern der structured fields in der pagedef Datei angegeben.
Die Parameter, die in den einzelnen structured fields enthalten sind, werden hinter den Gleichheitszeichen hexadezimal (in Maschinencode) aufgelistst. In dem Ausschnitt sind LineDescriptor structured fields (LNDs) zu sehen, die als Quellen zur Erstellung des Automatic Design Datensatzes verwendbar sind.
Ein Zeilendatenstrom wird mit den Maschinenbefehlen Zeile für Zeile abgearbeitet.
Die Erfindung wurde anhand von Ausführungsbeispielen beschrieben. Dabei ist klar, daß der Fachmann jederzeit Abwandlungen angeben kann. Insbesondere sind die genannten Druckdatensprachen nur beispielhaft zu verstehen, da diese sich stetig weiterentwickeln wie zum Anmeldezeitpunkt der vorliegenden Anmeldung an den beiden Druckdatensprachen Extensible Mark-up language (XML) und Personalized Printer Mark-up Language (PPML) deutlich wird.
Die Erfindung wurde insbesondere anhand von AFP-Beispielsdatenströmen und Dateien beschrieben. Es ist jedoch klar, dass die Erfindung auch für andere Zeilendatenströme mit dort entsprechenden Daten bzw. Dateien anwendbar ist und nicht auf AFP-Datenströme beschränkt ist.
Weiterhin ist das beschriebene Druckverfahren nicht auf bestimmte Bedruckstoffe wie Papier oder auf bestimmte Aufzeichnungsträgerformen wie Endlos-Bahnen oder Einzelblätter beschränkt.
Die Erfindung ist insbesondere dazu geeignet, als Computerprogramm (Software) realisiert zu werden. Sie kann damit als Computerprogramm-Modul als Datei auf einem Datenträger wie einer Diskette, DVD- oder CD-Rom oder als Datei über ein Daten- bzw. Kommunikationsnetz verbreitet werden. Derartige und vergleichbare Computerprogramm-Produkte oder Computerprogramm-Elemente sind Ausgestaltungen der Erfindung. Dabei ist klar, daß entsprechende Computer, auf denen die Erfindung angewandt wird, weitere, an sich bekannte technische Einrichtungen wie Eingabemittel (Tastatur, Mouse, Touchscreen), einen Mikroprozessor, einen Daten- bzw. Steuerungsbus, eine Anzeigeeinrichtung (Monitor, Display) sowie einen Arbeitsspeicher, einen Festplattenspeicher und eine Netzwerkkarte enthalten können.

1a...1c: erste Gruppe von Dokumenten
2a...2c: zweite Gruppe von Dokumenten
3a...3c: mailpieces (Sendungen)
3: Host Computer
4: Bearbeitungscomputer (File Server)
5: Netzwerk-Architektur
6: Ausgabegerät
7: Überwachungssystem
7a: Überwachungscomputer
7b: Datenbank
7c: Computerprogramm-Modul
8: Print Manager
9: Konverter
10a, 10b: Lesestation
11a, 11b: Hand-Barcodeleser
12, 12a: Client-Computer (Anwendernetzwerk)
13: Netzwerk für Client
14a...14d: Druckdatenleitung
15: Gerätesteuerungsnetzwerk
16: Druckserver
16a: Bildschirm
17: Testsystem
17b: Barcode Testsystem
17c: MICR-Testsystem
17d: Datenerfassungs-Modul
18a: Schneidegerät
18b: Kuvertierer
19: Druckgut
20a, 20b: Formatierungs-Computerprogramm
23: gedruckte Dokumente
25: Druckdatenquelle
26: Editor
27: AFP-Ressourcen-Datenstrom
28: Print Server
29: Druckdatenweg
30: „Muster"-Weg
31: Druckgerät
32: Druckgerät
33a, 33b: Gerätetreiber
34: Datenarchiv
35: Formatter
36: AFP-Kanal
37: Data Enrichment Kanal
38: Druckauftragssammelmodul
39: Auftragseingangssystem (JES)
40: SAP-Datenbankanwendungen
41: SAP-Ausgabedaten-Management-System
42: SAP-Schnittstelle
43: Druckproduktionssystem
44: Auftragsverteilungssystem
45: Druckauftragsmanager
46: Druckauftragsbegleitdatei
47: Datenerweiterungs-Modul
48: Designer-Computerprogramm
49: Dokumenten-Generator-Computerprogramm
50: SAP-Anwenderdatenbank
51: Erweiterungsdaten
52: Personalisierte Dokumente
53: Druckdatei
54: Spool-Computerprogramm
55: Druckdaten
56: Druckertreiber
60: Probedatensatz
61: Import-Modul
62: Designdatensatz
63: Design-Informations-Datei
64: Applikationsdatensatz
65: Übersetzung
66: Applikationsdatensatz mit internen Datenformat
67: Formatter-Computerprogramm-Modul
68: Personalisiertes Dokument
69: Transformations-Modul
70: Druckdatei
71: Dokumenten-Template
72: Formatbildungseinrichtung
73: Formatierter Dokumentendatenstrom
74: PPML-Daten
75: Seitenextraktions-Modul
76: Ausschießprogramm
77: Backend-Einrichtung
78: Hilfsdatei
80, 80a: Zeilendatenstruktur
81, 81a: automatisch erzeugte, gekennzeichnete Datenstruktur
82, 82a: endgültig gekennzeichnete Patenstruktur
83, 83a: Zeilendatenstrom
84, 84a: automatisch erzeugter gekennzeichneter Datenstrom
85, 85a: endgültig gekennzeichneter Datenstrom
90: Zeilendatengenerator
91: Zeilendaten-Vorprozessor
92: Formatter
93: Ausgabegerät
94: Ressourcen
95: Ressourcengenerator
100: Zeilennummern-Spalte
104: Aufbereitungsprogramm
105 106: Strukturfenster
107: Deskriptor-Fenster
108: Seitendeskriptor
109: Zeilendeskriptor-Tabelle
130: Datenbank
131: kundenspezifische Anwendung
132: pagedef-Datei
133: formdef-Datei
134: Zeilendaten
135: Fonts
136: Overlays
137: Codepages
138: pagesegmente

Claims

Verfahren zum Erzeugen einer Abbildungsvorschrift, mit der Eingangsdaten eines zeilenweise strukturierten Druckdatenstroms in Ausgangsdaten einer Ausgangs-Datenstruktur umsetzbar sind, wobei eine vorgegebene, dem zeilenweise strukturierten Druckdatenstrom zugeordnete Strukturbeschreibungsdatei verwendet wird.
Verfahren nach Anspruch 1, wobei ein Design-Datensatz festgelegt wird, welcher der Ausgangs-Datenstruktur entspricht und die Abbildungsvorschrift derart erzeugt wird, dass sie eine Abbildung zwischen Einträgen der Strukturbeschreibungsdatei und Einträgen des Design-Datensatzes beschreibt.
Verfahren zum Erzeugen eines seiten- und/oder bereichsstrukturierten Ausgangs-Datenstroms aus einem zeilenweise strukturierten Zeilendaten-Eingangs-Druckdatenstrom, dem eine Strukturbschreibungsdatei fest zugeordnet ist, wobei ein Design-Datensatz erzeugt wird, der die Ausgangs-Datenstruktur beschreibt, eine Abbildungsvorschrift zwischen der Strukturbeschreibungsdatei und dem Design-Datensatz gemäß Anspruch 1 oder 2 erzeugt wird und mittels der Abbildungsvorschrift aus dem zeilenweise strukturierten Zeilendaten-Eingangs-Druckdatenstrom der seiten- und/oder bereichsstrukturierten Ausgangs-Datenstrom erzeugt wird.
Verfahren zum Erzeugen eines seiten- und/oder bereichsstrukturierten Datenstroms aus einem zeilenweise strukturierten Zeilendaten-Druckdatenstrom, wobei – aus Zeilendaten-Druckdaten des Zeilendaten-Druckdatenstroms unter Verwendung mindestens einer ihnen zugeordneten Strukturbeschreibungsdatei ein Automatik-Design-Datensatz automatisch erzeugt wird, in dem struk turell zusammengehörige Druckdaten und/oder ihnen zugeordnete Kenndaten seiten- und/oder bereichsweise strukturiert zusammengestellt sind, – mittels eines Design-Datensatzes, der eine vorbestimmte Datenstruktur beschreibt und des Automatik-Design-Datensatzes eine Abbildungsvorschrift erzeugt wird, die die Abbildung von Daten des Automatik-Design-Datensatzes auf den Design-Datensatz beschreibt und – unter Verwendung des Design-Datensatzes, der Abbildungsvorschrift (77) und der Zeilendaten-Druckdaten der seiten- und/oder bereichsstrukturierte Datenstrom erzeugt wird.
Verfahren nach einem der Ansprüche 1 bis 4, wobei als Strukturbeschreibungsdatei eine Seitendefinitions-Datei (pagedef) verwendet wird.
Verfahren nach Anspruch 4 und Anspruch 5, wobei zum Erzeugen des Automatik-Design-Datensatzes und/oder zur Bildung der Abbildungsvorschrift zusätzlich zur Seitendefinitions-Datei (pagedef), eine ihr zugeordnete Seitenzuordnungsdatei (formdef) und/oder zugeordnete Ressourcen, insbesondere Fonts, Codepages, Overlays und/oder Pagesegmente und/oder ihnen zugeordneten Ressourcen verwendet werden.
Verfahren nach Anspruch 4 und insbesondere einem der vorhergehenden Ansprüche, wobei zur Erzeugung des Automatik-Designdatensatzes Feldpositionen aus der Strukturbeschreibungsdatei entsprechenden Datensätzen des Zeilendaten-Druckdatenstroms zugewiesen werden.
Verfahren nach Anspruch 4 und insbesondere einem der vorhergehenden Ansprüche, wobei vor dem Erzeugen des Automatik-Designdatensatzes eine Zwischendatei erzeugt wird, in der inhaltlich und/oder strukturell zusammengehörige Zeilendaten-Druckdaten innerhalb einer Strukturklammer zusammengefasst werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei als Zeilendaten-Druckdaten Advanced Function Presentation Zeilendaten-Druckdaten verwendet werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Ausgangsdatenstrom in Unicode kodiert wird.
Verfahren nach Anspruch 10, wobei Code Pages von Fontzuweisungen aus der Strukturbeschreibungsdatei auf Konsistenz mit der Unicode-Kodierung überprüft werden und Konflikte, insbesondere solche, die durch kundenspezifische Symbole oder normabweichende Belegungen der Code Pages entstehen, durch codespezifische Abbildungen nach Unicode aufgelöst werden.
Verfahren nach Anspruch 3 oder 4 und insbesondere einem der vorhergehenden Ansprüche, wobei zum Erzeugen der Abbildungsvorschrift die Strukturbeschreibungsdatei (pagedef, formdef, PPFA Skript Datei), zumindest Teile des Zeilendatenstroms und/oder von einem Bediener eingegebene und/oder ausgewählte Daten verwendet werden und eine Regeldatei gebildet wird, die die Abbildungsvorschrift enthält und die zum Erzeugen des seiten- und/oder bereichsstrukturierten Druckdatenstroms verwendet wird.
Verfahren nach Anspruch 3 oder 4 und insbesondere einem der vorhergehenden Ansprüche, wobei der seiten- und/oder bereichsstrukturierte Datenstrom Datenpaare aus Feldkennungen und zugehörigen Feldwerten enthält.
Verfahren nach Anspruch 3 oder 4 und insbesondere einem der vorhergehenden Ansprüche, wobei der seiten- und/oder bereichsstrukturierte Datenstrom Gruppen zusammengehöriger Datenfelder enthält.
Verfahren nach Anspruch 3 oder 4 und insbesondere einem der vorhergehenden Ansprüche, wobei der seiten- und/oder bereichsstrukturierte Druckdatenstrom als kommaseparierter Werte-Druckdatenstrom oder als Extensible Markup Language Datenstrom erzeugt wird.
Verfahren zum Erzeugen eines formatierten Druckdatenstroms, wobei nach Anspruch 3 oder 4 und insbesondere einem der vorhergehenden Ansprüche aus einem Zeilendatenstrom ein seiten- und/oder bereichsstrukturierter Datenstrom gebildet wird, der seiten- und/oder bereichsstrukturierte Datenstrom oder ein davon abgeleiteter Datenstrom als Eingangsdatenstrom für einen Formatter (67) verwendet wird und im Formatter (67) der formatierte Druckdatenstrom gebildet wird.
Verfahren nach Anspruch 16, wobei als formatierter Druckdatenstrom ein MO:DCA-Daten-Strom gebildet wird.
Verfahren nach Anspruch 16 oder 17, wobei dem Formatter-Eingangsdatenstrom durch den Formatter (67) insbesondere von einer Bedienperson eingegebene oder ausgewählte Struktur- und/oder Formatierungselemente hinzugefügt werden.
Verfahren nach einem der Ansprüche 16, 17 oder 18, wobei dem Formatter (67) ein Dokumenten-Template (112) zugeführt wird, wobei der seiten- und/oder bereichsstrukturierte Datenstrom in ein internen Datenformat (66) umgewandelt wird, den Daten im internen Datenformat (66) bedarfsweise, gesteuert durch das Dokumenten-Template (112), eine Dokumentenformatierungsinformation hinzugefügt wird, die festgelegt, wie der Inhalt des Datenstroms im internen Datenformat im formatierten Druckdatenstrom dargestellt wird, und die Daten als formatierter Druckdatenstrom ausgegeben werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Abbildungsvorschrift automatisch erstellt wird und wobei Heuristiken angewendet werden, die Druckanweisungen der Strukturbeschreibungsdatei und/oder ihnen zugeordnete Kenndaten gemäß ihren tatsächlichen Aufrufen beim Abarbeiten von Zeilendaten des zeilenweise strukturierten Druckdatenstroms analysieren und/oder interpretieren.
Vorrichtung zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 20.
Vorrichtung nach Anspruch 21, umfassend einen Computer.
Drucksystem, das eine Vorrichtung nach einem der Ansprüche 21 oder 22 enthält.
Computerprogrammprodukt, das beim Laden und Ablaufen auf einen Computer ein Verfahren auch einen der Ansprüche 1 bis 20 bewirkt.