DE10045133C2

DE10045133C2 - Wiederverwendbares computerimplementiertes Auftrags-Editier und Liefer-Verfahren

Info

Publication number: DE10045133C2
Application number: DE10045133A
Authority: DE
Inventors: Shell S Simpson; Ward S Foster
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 1999-09-28
Filing date: 2000-09-13
Publication date: 2003-10-02
Anticipated expiration: 2020-09-14
Also published as: GB2359646A; DE10045133A1; GB2359646B; GB0023094D0; US6738156B1; US20050076299A1

Description

Diese Erfindung bezieht sich allgemein auf das Gebiet der Software zum Editieren bzw. Bearbeiten und Liefern von Druckeraufträgen und insbesondere auf ein computerimplementiertes Verfahren, mit dem ein Benutzer einen Druckauftrag in einem Computersystem editieren und liefern kann, bei dem der Druckauftrag von unterschiedlichen Anwendungen und Platt formen ausgehen kann.

Eine neue Klasse Drucksoftware ist in jüngerer Zeit zur Anwendung gekommen. Diese Klasse Drucksoftware ermöglicht es, daß Aufträge außerhalb eines Druckertreibers editiert werden. Diese Klasse von Software ist von besonderem Inter esse, da dieselbe Druckmerkmale, die durch einen Drucker geliefert werden, für einen Benutzer sichtbar macht. Auf den Microsoft-Windows-Plattformen ("Windows-Plattformen"), die vorherrschende Plattform für das Heim- und Büro-Drucken, rührt die einzigste Benutzerschnittstelle, die sich auf das Drucken bezieht und mit der die meisten Benutzer wechsel wirken, von der Anwendung her. Diese Benutzerschnittstelle (d. h. die Druckdialogbox bzw. der Druckdialogkasten) zeigt oftmals nicht die Fähigkeit, die unterschiedlichen Drucker produkte zu unterscheiden. Folglich wird eine Investition in neue Hardware-, Firmware- und Software-Technologien für die Druckerprodukte durch die Mehrheit der Benutzer nicht wahr genommen und nicht benutzt.

Für die Zwecke dieser Anwendung wird diese neue Klasse von Drucksoftware als Auftrags-Editier- und Liefer-Systeme be zeichnet. Diese Systeme erfassen einen Auftrag von einer Anwendung und geben dem Benutzer die Gelegenheit, die Auf tragseinstellungen interaktiv zu modifizieren. Benutzer können Optionen, wie z. B. n-hinauf ("n" Bilder auf einem Blatt), Wasserzeichen und das Druckschriftdrucken, neben anderen, auswählen. Nachdem der Benutzer das Auswählen der gewünschten Einstellungen beendet hat, wird der Auftrag daraufhin zu einem Drucker nach Wahl des Benutzers gesendet. Einige Auftrags-Editier- und Liefer-Systeme verfolgen den Status des Auftrags mit variierenden Erfolgsgraden.

Heutzutage existieren mehrere kommerzielle Beispiele von Auftrags-Editier- und Liefer-Systemen. Eine nicht erschöp fende Liste dieser Systemtypen umfassen:

a) FinePrint von Single Track Software (www.singletrack.com);
b) printChef von MindGate (www.mindgate.com);
c) HandyPrint; oder
d) Power PrintCache von LaserTools.

Alle diese Auftrags-Editier- und Liefer-Systeme sind als ein monolithisches nicht wiederverwendbares System implemen tiert. Obwohl dieselben in dem Sinne wiederverwendbar sind, daß dieselben Druckaufträge von den meisten Windows-Anwen dungen erfassen und verarbeiten können, sind dieselben in dem Sinne nicht wiederverwendbar, daß dieselben nicht ver wendet werden können, um Aufträge von Nicht-Windows-Anwen dungen zu erfassen und zu verarbeiten, die durch Windows- Endbenutzer verwendet werden. Es ist beispielsweise eine wesentliche Entwurfsänderung für die aktuellen Erzeugnisse, wie z. B. dieselben, die oben erwähnt sind, erforderlich um einen Windows-Client zu unterstützen, der von einem UNIX- Host druckt. Dementsprechend besteht ein Problem der derzei tigen Systeme darin, daß Windows-Endbenutzer nicht die glei che reichhaltige Druckerfahrung ungeachtet dessen besitzen, von welchem System der Druckauftrag ausgeht.

Diese Auftrags-Editier- und Liefer-Systeme sind ferner nicht wiederverwendbar, da dieselben nicht stärker in Anwendungen integriert werden können. Um die Auftragsinformationen zu erfassen, machen es dieselben erforderlich, daß die Anwen dung Auftragsinformationen zu dem Drucksystem von Windows oder anderen Betriebssystemen weiterleitet. Bevor dieselben eine Druckvorschau anbieten können, müssen diese Information durch das Drucksystem laufen, was eine wesentliche Verzö gerung verursacht.

Außerdem sind die bekannten Systeme nicht gut in den Anwen dungen integriert und können daher nicht ohne weiteres durch die Anwendungen modifiziert werden. Das heißt, daß bekannte Auftrags-Editier- und Liefer-Systeme nicht ohne weiteres durch die Anwendungen konfigurierbar sind.

Fig. 1 zeigt den Betrieb eines typischen bekannten Auf trags-Editier- und Liefer-Systems 10 gleichartig zu den jenigen, die oben erwähnt sind. Es sei insbesondere bemerkt, daß die Figur vollständig auf einer funktionellen Unter suchung des Verhaltens von existierenden Systemen und einer Untersuchung eines Windows-Systems nach dem Installieren bzw. Einrichten eines bekannten Auftrags-Editier- und Liefer-Systems basiert, ohne ein Zerlegen der Programm befehle durchzuführen. In Fig. 1 erfaßt das bekannte System 10 den Auftrag unter Verwendung eines herkömmlichen Drucker treibers 11. Dieser Druckertreiber 11 leitet die Auftrags informationen zu einem 32-Bit-Verarbeitungsmodul 12 weiter, das seinerseits die Auftragsinformationen anzeigt, so daß ein Benutzer diese Auftragsinformationen editieren kann. Bei dieser offensichtlichen Implementation werden die Auftrags informationen (einschließlich der Bilderzeugungsinforma tionen) in das bekannte 32-Bit-Verarbeitungsmodul 12 weitergeleitet und direkt durch das bekannte System 10 verarbeitet. Dies macht das bekannte 32-Bit-Verarbeitungs modul 12 (oder jedes ähnlich implementierte Auftrags- Editier- und Liefer-System) zur Wiederverwendung unprak tisch.

Das Wiederverwenden eines Auftrags-Editier- und Liefer- Systems ist wünschenswert, da die Auftragsinformationen von vielen Quellen herrühren können. Beispielsweise können Auf tragsinformationen von einer Unternehmens-Betriebsmittel- Planungs-Anwendung (ERP-Anwendungen; ERP = Enterprise Resource Planning) von einem Lieferanten, wie z. B. SAP (der der Marktführer beim Liefern von ERP-Anwendungen ist), zugeführt werden. Obwohl SAP-Aufträge typischerweise von einer Server-Maschine ausgehen, gibt der Endbenutzer oftmals die Druckanweisung von einer Client-Software aus, die unter Windows läuft. Daher kann der Benutzer nicht mit dem ihm bekannten windows-basierten Auftrags-Editier- und Liefer- System wechselwirken, wenn derselbe von einer SAP-Anwendung (oder anderen ähnlichen Client/Server-Anwendungen) druckt.

Um zu ermöglichen, daß das bekannte Auftrags-Editier- und Liefer-System verwendet werden kann, wenn aus einer SAP- Anwendung gedruckt wird, wäre es notwendig, den Auftrag von SAP zu dem PC des Endbenutzers zu übertragen, und dann diese Informationen in das Auftrags-Editier- und Liefer-System zusammenzuführen. Das Zusammenführen der Auftragsinforma tionen in ein Auftrags-Editier- und Liefer-System umfaßt wahrscheinlicherweise folgende Schritte:

a) Umwandeln der Auftragsdaten in die Zwischendarstel lung, die durch das Auftrags-Editier- und Liefer- System verwendet wird und dadurch stark das Verhalten beeinflußt; und/oder
b) Senden der Auftragsdaten über Prozeßgrenzen (was eine Kopie erforderlich macht), was ebenfalls stark das Verhalten beeinflußt.

Daher scheint keines der bekannten Auftrags-Editier- und Liefer-Systeme die Wiederverwendung zu unterstützen, wobei kein Nachweis existiert, daß es praktisch ist, die Druck software-Objekte oder -Module derselben wiederzuverwenden.

Die DE 694 09 487 T2 betrifft ein Betriebssystem mit einer objektorientierten Druckerschnittstelle. Die Computer schnittstelle umfaßt ein Anwendungsprogramm, ein Betriebs system und ein Druckerschnittstellenobjekt. Das Drucker schnittstellenobjekt ist in das Betriebssystem des Computer systems integriert und empfängt druckbare Informationen von dem Anwendungsprogramm durch Übergabe einer vorbestimmten Position der druckbaren Daten. Die Druckerschnittstelle ist dazu vorgesehen, Formatierungs- und Paginierungsaufgaben an den empfangenen druckbaren Informationen durchzuführen, die anderenfalls durch jedes Anwendungsprogramm, das auf dem Betriebssystem läuft, ausgeführt werden müßten. Die Aufgaben umfassen insbesondere das Hinzufügen von Rahmen, Seitennum mern, Ausrichtungsmarkierungen und dergleichen. Folglich kann jede Anwendung, die auf dem Betriebssystem läuft, die Druckerschnittstelle verwenden, wodurch eine Zentralisierung der Druckfähigkeiten erzielt wird. Die Druckerschnittstelle leitet die druckbaren Informationen an einen Grafport des Betriebssystems weiter, der als eine standardisierte Druckerschnittstelle wirkt (siehe Fig. 2). Der Grafport leitet die druckbaren Informationen wiederum an ein jewei liges Druckhandhabungsprogramm weiter, welches die Infor mationen wiederum an einen Druckerport ausgibt. Das Drucker schnittstellenobjekt ist objektorientierter Programmierung OOP implementiert.

Die Aufgabe der vorliegenden Erfindung besteht darin, ein computerimplementiertes Verfahren, mit dem ein Benutzer einen Druckauftrag in einem Computersystem editiert und lie fert, zu schaffen, das es ermöglicht, daß ein Windows-Benutzer einen Druck auftrag ungeachtet des Ursprungs des Druckauftrags editiert und überträgt.

Diese Aufgabe wird durch ein computerimplementiertes Verfah ren, mit dem ein Benutzer einen Druckauftrag in einem Com putersystem editiert und liefert, gemäß Anspruch 1 oder 9 gelöst.

Ein Vorteil der vorliegenden Erfindung besteht darin, daß dieselbe ein wiederverwendbares computerimplementiertes Auftrags-Editier- und Lie fer-Verfahren schafft, das die Standardkomponententechnologien verwendet, so daß das computerimplementierte Auftrags-Editier- und Liefer-Verfahren durch unterschiedliche Anwendungen auf unterschiedlichen Plattformen verwendet werden kann.

Ein weiterer Vorteil des Verfahrens besteht darin, daß dasselbe ein Drucksoftwareobjekt vorsieht, das direkt durch eine Anwendung verwendet werden kann, von der ein Druckauftrag ausgeht.

Ein weiterer Vorteil des Verfahrens besteht darin, daß dasselbe ein Drucksoftwareobjekt vorsieht, das durch einen Druckertreiberkanalhost, der die Druckauftrags daten von dem Druckteilsystem eines Betriebssystems erfaßt, verwendet werden kann.

Ein weiterer Vorteil des Verfahrens besteht darin, daß dasselbe ein Drucksoftwareobjekt vorsieht, das durch einen Serverkanalhost verwendet werden kann, der Druckauftragsdaten von einem Serversystem erfaßt, von dem der Druckauftrag ausgeht.

Diese und weitere Vorteile werden durch eine Schaffung eines computerimplementierten Verfahrens erreicht, mit dem ein Benutzer einen Druckauftrag in einem Computersystem editiert und liefert, wobei das Verfahren die Schritte des Vorsehens eines Drucksoftwareobjekts als eine Komponenten-Objekt- Modell-Komponente ("COM"-Komponente; COM = Component Object Model) zum Editieren und Liefern eines Druckauftrags, das Liefern der Auftragsdaten des Druckauftrags zu dem Druck softwareobjekt durch einen Druckauftragserzeuger in der Form von Bezugnahmen auf Seiten, das Verwenden des Bezugs auf die Seiten durch das Softwaredruckobjekt, um die Seiten auf einer Bedarfsbasis aufzurufen und anzuzeigen, das Editieren der Auftragsdaten des Druckauftrags durch einen Benutzer basierend auf den angezeigten Seiten, und das Liefern des Druckauftrags zum Verarbeiten gemäß der editierten Auftrags daten aufweist.

Ferner ist ein Verfahren vorgesehen, in dem ein Drucksoftwareobjekt als eine In-Prozeß- COM-Komponente geschaffen ist.

Es ist ferner ein Verfahren geschaffen, bei dem das Druck softwareobjekt direkt durch eine Anwendung verwendet wird, die der Druckauftragserzeuger ist.

Somit ist ein computerimplementiertes Verfahren geschaffen, bei dem das Drucksoftwareobjekt durch einen Druckertreiber kanalhost verwendet wird, der die Druckauftragsdaten von dem Druckteilsystem des Betriebssystems (Druckteilsystem des OS) erfaßt.

Desweiteren ist ein computerimplementiertes Verfahren geschaffen, bei dem das Softwaredruckobjekt durch einen Serverkanalhost verwendet wird, der die Druckauftragsdaten von einem Serversystem erfaßt, in dem die Druckauftragsdaten erzeugt werden.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend unter Bezugnahme auf die beigefügten Zeichnungen näher erläutert. Es zeigen:

Fig. 1 ein Blockdiagramm, das die Komponenten eines typi schen bekannten Auftrags-Editier- und Liefer- Systems zeigt;

Fig. 2a bis 2d die Verwendung eines Drucksoftwareobjekts als ein In-Prozeß-COM-Objekt;

Fig. 3 ein Einheits-Formgebungs-Sprachen-Diagramm (UML-Diagramm), das das Weiterleiten der Auf tragsdaten zwischen einer Anwendung und dem Auftrags-Editier- und Liefer-System gemäß der vorliegenden Erfindung darstellt;

Fig. 4 ein Beispielprogrammcode, der eine Beispielliste von Funktionen implementiert, die in den Seiten bildeinstellungs- und Seitenbild-Schnittstellen gemäß der vorliegenden Erfindung vorgefunden wer den;

Fig. 5 ein Pseudocode für eine beispielhafte Schnittstelle zu dem Auftrags-Editier- und Liefer-System gemäß der vorliegenden Erfindung;

Fig. 6 eine Darstellung einer einfachen Auftragsschnitt stelle gemäß der vorliegenden Erfindung;

Fig. 7 die Struktur eines Druckauftrags als ein modifi ziertes UML-Klassendiagramm; und

Fig. 8 ein Flußdiagramm, das den Betrieb des Auftrags- Editier- und Liefer-Systems gemäß der vorliegenden Erfindung zeigt.

Bei einem allgemeinen Aspekt bietet die vorliegende Erfin dung die folgenden Vorteile gegenüber bekannten Verfahren des Stands der Technik:

a) dieselbe vermeidet die berechnungsmäßig intensive Umwandlung von Bilderzeugungsinformationen in eine unnötige Zwischendarstellung;
b) dieselbe vermeidet das Kopieren von Auftragsinforma tionen über Prozeßgrenzen;
c) dieselbe erleichtert die Wiederverwendung eines Auf trags-Editier- und Liefer-Systems durch die Client/ Server-Druckserver (wie z. B. SAP, UNIX-Systeme und Mainframe-Systeme); und
d) dieselbe vereinfacht die Wiederverwendung eines Auftrags-Editier- und Liefer-Systems innerhalb der Anwendungssoftware.

Um die Vorteile der vorliegenden Erfindung hervorzuheben, sei bemerkt, daß alle bekannten Auftrags-Editier- und Lie fer-Systeme an wesentlichen Problemen aus den vor her genannten Gründen leiden. Der Auftrag muß von der Anwen dung zu dem Drucksystem der Betriebssysteme (OSs) übertragen werden, bevor der Auftrag (in seiner Gesamtheit) dem bekann ten Auftrags-Editier- und Liefer-System zur Verfügung steht. Wenn beispielsweise eine Anwendung 200 Seiten in einem Auf trag aufweist, müssen alle 200 Seiten zu dem Auftrags-Edi tier- und Liefer-System übertragen werden. Wenn das Auf trags-Editier- und Liefer-System in die Anwendung integriert ist, ist es für das Auftrags-Editier- und Liefer-System mög lich, gewünschte Seiten auf einer Bedarfsbasis abzufragen, wodurch die Notwendigkeit vermieden wird, alle Seiten des Auftrags zu verarbeiten.

Um die Anwendungsentwickler zu ermutigen, die Anstrengung des Integrierens eines derartigen Systems auf sich zu neh men, muß das System leicht zu integrieren sein, und die Integration muß eine vermarktbare Verbesserung für den An wendungsentwickler liefern. Sobald dasselbe integriert ist, wird das Auftrags-Editier- und Liefer-System gemäß der vorliegenden Erfindung im wesentlichen die Druckdialogbox (oder die Druckvorschau) der Anwendung werden.

Wie es vorhergehend erwähnt wurde, ermöglicht das vor liegende Verfahren, daß die Drucker-Hardware und -Software ihre Druckfähigkeiten einem Benutzer zeigt. Der bestmögliche Ort, um dies durchzuführen, ist eine Art und Weise, die in die Anwendung gemäß der vorliegenden Erfindung (d. h. unter Verwendung der Druckdialogbox der Anwendung) nahtlos integriert ist.

Bei einem allgemeinen Aspekt verwendet das vorliegende Verfahren zwei neue Lösungsansätze, um das Ziel des Erreichens eines wiederverwendbaren Auftrags-Editier- und Liefer- Systems zu erleichtern.

Bei dem ersten Lösungsansatz ist das Auftrags-Editier- und Liefer-System der vorliegenden Erfindung als eine In-Prozeß- COM-Komponente implementiert, die Auftragsdaten von einer Vielzahl von Quellen aufnimmt. Da COM ein gut bekann ter Windows-Standard ist, kann das System in anderen Soft wareprogrammen relativ einfach integriert werden. Da die COM-Komponente sich im Prozeß befindet, ist kein unnöti ges Kopieren von Daten von einem Prozeß zu einem anderen erforderlich.

Bei dem zweiten Lösungsansatz werden die Auftragsdaten zu dem Auftrags-Editier- und Liefer-System in der Form von Be zügen bzw. Verweisen auf Seiten geliefert. Das System ruft den Lieferanten dieser Seiten zurück, um die Seiten auf einer Nachfrage- oder Bedarfs-Basis zu zeichnen. Folglich vermeidet die vor liegende Erfindung die Notwendigkeit des Umwandelns der Bilddaten in eine Zwischendarstellung. Statt dessen sendet der Lieferant Bilddaten direkt zu der Windows-Graphikvor richtungsschnittstelle ("GDI"; GDI = Graphics Device Inter face), wie es durch das Auftrags-Editier- und Liefer-System angewiesen wird.

Um das Verständnis des bevorzugten Ausführungsbeispiels der vorliegenden Erfindung zu erleichtern, ist hierin eine kurze Beschreibung des Windows-Graphikvorrichtungsschnittstellen- (GDI-)Drucksystems und des Komponentenobjektmodells (COM) vorgesehen. Es sei hier erwähnt, daß Handelsmarken und Han delsnamen, auf die hierin Bezug genommen wird, das Eigentum ihrer jeweiligen Besitzer sind.

Das COM ist eine Komponentensoftwarearchitektur, die es An wendungen und Systemen ermöglicht, aus Komponenten aufgebaut zu werden, die durch unterschiedliche Softwarelieferanten auf unterschiedlichen Computerplattformen geliefert werden können. Ein wichtiges Merkmal des COM besteht darin, daß dasselbe einen Mechanismus liefert, durch den binäre Softwarekomponenten, die durch unterschiedliche Softwareliefe ranten geliefert werden, verbunden werden können und mit einander unter Verwendung einer gut definierten Schnittstel le kommunizieren können. Der Schnittstellenmechanismus wird durch das COM geliefert, das eine Komponentensoftwarearchi tektur ist, die von Microsoft entwickelt wurde, die:

a) einen binären Standard für eine Komponentenkompatibi lität definiert;
b) programmiersprachenunabhängig ist;
c) auf mehreren Plattformen vorgesehen ist; und
d) erweiterbar ist.

COM liefert ferner Mechanismen für die folgenden Funktiona litäten:

a) eine Kommunikation zwischen Komponenten über Prozeß- und Netzwerk-Grenzen;
b) eine gemeinsam verwendete Speicherverwaltung zwischen Komponenten;
c) Fehler- und Status-Berichte;
d) ein dynamisches Laden von Komponenten;
e) eine Grundkompatibilität;
f) eine Versionsprüfung; und
g) eine transparente Kreuz-Prozeß-Kompatibilität.

Einige der Grundlagen, die dem COM zugrunde liegen, umfassen:

a) einen binären Standard zum Aufrufen von Funktionen zwischen Komponenten;
b) eine Einrichtung zum Gruppieren von stark typisierten Funktionen in Schnittstellen;
c) eine Grundschnittstelle, die es ermöglicht, daß Kom ponenten die Schnittstellen bestimmen, die durch andere Komponenten implementiert sind, und eine Be zugszählvorrichtung, die es ermöglicht, daß Komponen ten ihre eigene Lebensdauer verfolgen;
d) einen Komponentenlader, der Komponentenwechselwirkun gen einrichtet und die Komponentenwechselwirkungen in Kreuz-Prozeß- und Kreuz-Netzwerk-Situationen bzw. in prozeßübergreifenden und netzwerkübergreifen den Situationen verwaltet.

Es existieren öffentliche Informationen, die eine weitere Beschreibung des COM- Modells und des GDI-Drucksystems liefern und dessen Inhalt hierin vollständig aufgenommen ist, wobei diese öffentlichen Informationen auf der Internet-Website von Microsoft bereitgestellt werden, und alle darin enthaltenen Rechte Microsoft gehören.

Unter Bezugnahme auf die Figuren stellen die Fig. 2a-2d die Verwendung eines Drucksoftwareobjekts als ein In-Prozeß- COM-Objekt dar. Fig. 2a stellt dar, daß ein durch ein Auftrags-Editier- und Liefer-System geliefertes Drucksoft wareobjekt 21 direkt durch eine Client-Windows-Anwendung 22 verwendet wird. Es ist offensichtlich, daß die Client-Anwen dung nicht auf die Windows-Umgebung begrenzt ist, sondern ferner jede andere Client-Betriebsumgebung umfaßt, das ein Komponentenobjektmodell, wie z. B. COM, unterstützt.

Fig. 2b zeigt das Drucksoftwareobjekt 21, das durch einen Treiberkanalhost 30 verwendet wird, der mit den Druckauf tragsinformationen betrieben wird, die von dem Windows- Drucksystem erfaßt werden. Das heißt, eine Anwendung 31 überträgt einen Druckauftrag zu einem Druckertreiber 32, der programmiert ist, um mit einem Spooler (Software oder Hard ware, die einen Druckvorgang ermöglicht, während etwas ande res abgewickelt wird) 33 und einer Torüberwachungsvorrich tung 34 wechselzuwirken, um den Druckauftrag zu einem geeigneten Drucker (der in der Figur nicht gezeigt) zu leiten. Der speziell programmierte Druckertreiber 32, der die Druckauftragsinformationen erfaßt, ist ein Ausführungs beispiel eines Teilsystems, auf das im folgenden als das Auftragserfassungsteilsystem ("JCSS"; JCSS = Job Capture Subsystem) des Auftrags-Editier- und Liefer-Systems der vorliegenden Erfindung Bezug genommen wird.

Es sei angemerkt, daß das Entwickeln des Programmcodes, um die Druckauftragsinformationen von dem Druckertreiber 32 zu erfassen, innerhalb der Fähigkeiten eines Fachmanns liegen. Da sich der Druckertreiber in dem 16-Bit-Teilsystem befin det, werden beispielsweise bei einer solchen Implementation der Windows-Umgebung die durch das Windows-Betriebssystem gelieferten "Thunk"-Funktionen verwendet. Diese Thunk-Funk tionen liefern eine Möglichkeit, 16-Bit-Funktionen aufzu rufen, um Verfahrensaufrufe zu einem Code durchzuführen, der auf dem 32-Bit-Teilsystem läuft, wie z. B. der Treiberkanal host 30. Diese Thunk-Funktionen sind ein Softwaremechanis mus, der es einem 16-Bit-Programm ermöglicht, eine dynamisch verbundene Bibliothek (DLL; DLL = Dynamically Linked Library) mit 32 Bit unter einem 32-Bit-Windows-Betriebs system aufzurufen. Das 16-Bit-Programm, das versucht, einen Eintrag in der 32-Bit-DLL aufzurufen, ruft statt dessen einen entsprechenden Eintrag in einer 16-Bit-DLL auf. Der Programmcode muß ferner einen Code enthalten, um zu er fassen, ob die 32-Bit-DLL geladen ist. Ein 32-Bit-EXE-Modul lädt die 32-Bit-DLL. Daher kann der Thunking-Mechanismus durch einen ausgebildeten Programmierer verwendet werden, um zwischen dem Druckertreiber 32, der in dem 16-Bit-Teilsystem betrieben wird, und dem Druckerkanalhost 30, der in dem 32-Bit-Teilsystem der Windows-Umgebung läuft, zu kommunizie ren.

Fig. 2c stellt das Drucksoftwareobjekt 21 dar, das durch einen Serverkanalhost 40 verwendet wird, der mit den Druck auftragsinformationen arbeitet, die von einem serverbasier ten System 41 (z. B. SAP, UNIX, Mainframe (Großrechner)) durch ein weiteres Ausführungsbeispiel des Auftragserfas sungsteilsystems erfaßt wird. Daher wird eine Client- Graphische-Benutzerschnittstellen-Anwendung ("GUI"-An wendung) auf einer Windows-Client-Maschine 42 mit einer Sitzung 44 in der Servermaschine 41 verbunden, um einen Druckauftrag 45 zu erzeugen. Die Server-Haken 46 (Server- Programmeinstiegsmöglichkeiten), die durch die vorliegende Erfindung in der Server-Maschine 41 vorgesehen sind, er fassen erforderliche Druckauftragsinformationen und über tragen dieselben zu dem Server-Kanal-Host 40, so daß das Drucksoftwareobjekt 21 ein Fenster für einen Benutzer liefern kann, um die übertragenen Druckauftragsinformationen zu editieren oder zu modifizieren.

Fig. 2d stellt eine weitere Anwendung des Drucksoftware objekts 21 in einer gemeinsam verwendeten Umgebung dar, in der das Drucksoftwareobjekt 21 in einem zentralisierten PC- Kanal-Host 47 vorgesehen ist. Der zentralisierte PC-Kanal- Host 47 koordiniert dann das gesamte Drucken von unter schiedlichen Quellen von Druckauftragsdaten. Daher koordi niert der PC-Kanal-Host 47 gemäß der Figur das Drucken von Windows-Anwendungen 22, die jeweils ein Drucksoftwareobjekt 21 enthalten, das wie im folgenden beschrieben, modifiziert ist. Der PC-Kanal-Host 47 wechselwirkt ferner mit dem spe zialisierten Druckertreiber 32 und den Spooler-Haken 33, um das Editieren und die Lieferung der Druckauftragsdaten zu koordinieren, die durch den Druckertreiber 32 und die Spooler-Haken 33 erfaßt werden. Der PC-Kanal-Host 47 wechselwirkt ferner mit den Druckauftragsinformationen, die von einem Serversystem 41 durch die Server-Haken 46 erfaßt werden. Daher kann der PC-Host-Kanal 47 Druckauftrags informationen von mehreren unterschiedlichen Quellen, wie z. B. andere Anwendungen, Druckertreiber und andere Server, empfangen und dient als ein zentrales Druckzentrum für ein Endauftragseditieren und eine Endauftragslieferung für einen kombinierten Satz von Seitenbildern.

In dem gemeinsam verwendeten Szenario, das in Fig. 2d ge zeigt ist, besitzen die Anwendungen 22 integrierte Druck softwareobjekte 21, die speziell konfigurierbar sind. Die speziell konfigurierbaren Softwaredruckobjekte sind konfi gurierbar, um die Seitenbildsätze derselben zu dem zentra lisierten Host-Kanal 47 zu "verzögern". Einige der konfi gurierbaren Optionen des Verzögerungs-Merkmals können folgende Optionen umfassen: (i) das Verzögern lediglich auf Anfrage (d. h. der Benutzer wählt aus, ob ein Auftrag verzögert werden sollte); (ii) automatische/intelligente Verzögerung (d. h. das Drucksoftwareobjekt 21 verzögert, wenn dasselbe erfaßt, daß ein zentralisierter PC-Host-Kanal 47 bereits läuft); oder (iii) immer verzögern (d. h. die Ausgabe wird immer zu dem zentralisierten PC-Host-Kanal 47 ge sendet). Wenn die Verzögerungsoption ausgewählt ist, verzögert das In-Prozeß-Softwaredruck-COM-Objekt 21 der Anwendung den PC-Host-Kanal 47, indem die Druckauftrags informationen zu dem PC-Host-Kanal unter Verwendung eines Zwischenformats, wie z. B. EMF oder eines herkömmlich definier ten Formats, gesendet werden. Obwohl dieses Verzögerungs merkmal einige Verhaltensnachteile bringt, liefert dasselbe den Vorteil, daß die Druckauftragsausgabe von diesen Anwendungen mit den Druckauftragsausgaben von anderen Quellen, wie z. B. andere Anwendungen, Druckertreiber oder andere Server, kombiniert werden kann. Es sei angemerkt, daß, obwohl die In-Verfahren-COM-Objekte bei dem bevorzugten Ausführungsbeispiel verwendet werden, es ferner möglich ist, die Merkmale von Außer-Prozeß-Aktivierungen von COM zu verwenden.

Bei jeder dieser Anwendungen des Drucksoftwareobjekts 21 kann die Implementation der COM-Komponente identisch sein, d. h. das COM-Objekt 21 kann unter Verwendung der gleichen COM-Komponente eingesetzt werden. Microsoft spezifiziert ein Standardverfahren zum Entdecken der Anwesenheit von COM-Kom ponenten in der Definition der COM-Komponentenarchitektur. Daher wird bei jeder dieser Situationen dieses Standardver fahren verwendet, um die COM-Komponente zu lokalisieren, und die COM-Komponente kann ohne weiteres durch dieselben ge meinsam verwendet werden.

Außerdem kann die COM-Komponente unabhängig von der Soft ware, die die COM-Komponente verwendet, aktualisiert werden. Dies ermöglicht es, daß die gesamte Software, die die COM- Komponente verwendet, einen Vorteil daraus zieht, wenn die selbe aktualisiert wird. Schließlich kann durch ein gemein sames Verwenden einer gemeinsamen COM-Komponente Software, die die COM-Komponente verwendet, konsistent mit anderer Software, die die COM-Komponente verwendet, entworfen werden, d. h. dieselben können die gleiche Benutzerschnitt stelle und das gleiche Verhalten bezüglich des Druckens aufweisen.

Bei der Implementation, die in Fig. 2b dargestellt ist, dem Fall eines Windows-Drucken, sind die Druckertreiber zweimal beteiligt. Zuerst wird der speziell programmierte Drucker treiber 32 beteiligt, um den Druckauftrag von dem Windows- Drucksystem zu erfassen. Der Druckertreiber 32 ist für das Übersetzen der Auftragsinformationen in eine Form ver antwortlich, die es ermöglicht, daß derselbe aus einem Druckertreibermodus (beispielsweise einem Kern-Modus (Kernel-Modus) auf Windows-NT, einem 16-Bit-Modus auf Windows 9x) heraus und in einen Anwendungsmodus (d. h. bei spielsweise den 32-Bit-WIN32) weitergeleitet wird. Danach ist möglicherweise ein zweiter Druckertreiber (d. h. der Standarddruckertreiber) beim Übersetzen der Auftragsinforma tionen in ein Format beteiligt, das durch einen ausgewählten Zieldrucker erkannt wird, nachdem der Benutzer einen Ziel drucker unter Verwendung des Auftrags-Editier- und Liefer- Systems der vorliegenden Erfindung ausgewählt hat. Alterna tiv kann das Auftrags-Editier- und Liefer-System der vorlie genden Erfindung selbst die Druckauftragsinformationen in eine geeignete Druckersprache übersetzen und zum Drucken weiterleiten. Die Details dieser Beteiligung des Drucker treibers 32 sind hier nicht vorgesehen, da dieselben inner halb der Fähigkeiten eines Fachmanns liegen, und für das Verständnis der Merkmale der vorliegenden Erfindung nicht wesentlich sind. Diese Erfindung konzentriert sich auf das Liefern von Informationen über die Schnittstelle zwischen dem austauschbaren Auftragserfassungsteilsystem (das den unterschiedlichen Betriebsplattformen und Anwendungen entspricht) und dem konstanten Auftrags-Editier- und Liefer-Teilsystem, das gemäß dem Auftrags-Editier- und Liefer-System der vorliegenden Erfindung vorgesehen ist.

Bei der Implementation der direkten Anwendung, die in Fig. 2(a) dargestellt ist, dient die Schnittstelle, die durch das COM-Drucksoftwareobjekt 21 geliefert wird, um die Fähigkei ten zu erweitern, die durch das Standard-Windows-Drucksystem vorgesehen werden. Beispielsweise liefert Windows keinen Mechanismus, um eine echte Druckvorschau zu erhalten, die die Druckereinstellungen widerspiegelt. Das Drucksoftware objekt 21 gemäß der vorliegenden Erfindung liefert jedoch eine echte Druckvorschau, die die Druckereinstellungen widerspiegelt, die nun durch die Anwendung 22 zu dem Benut zer geliefert werden können. Dies ist lediglich ein Bei spiel, wie das Drucksoftwareobjekt 21 gemäß der vorliegenden Erfindung erweiterte Fähigkeiten (gegenüber dem Standard- Windows-Drucksystem) liefert, die einem Benutzer einer An wendung 22, die den Druckauftrag erzeugt, zur Verfügung ge stellt werden.

Daher sieht das computerimplementierte Verfahren die Implementation eines Auftrags-Editier- und Liefer-Systems als ein COM- Objekt, wie oben beschrieben, vor. Diese Implementation weist mindestens die folgenden Vorteile auf:

a) ein unnötiges Kopieren von Auftragsdaten zwischen Prozessen wird durch ein Weiterleiten von Bezugnahmen auf Seiten und nicht von detaillierten Bilderzeu gungsinformationen zwischen Komponenten, wie im folgenden erörtert, vermieden;
b) COM ist ein weit bekannter Komponentenstandard für die Windows-Umgebung, daher erleichtert die Implemen tierung der Windows-Software als eine COM-Komponente die Wiederverwendung desselben; und
c) COM sieht ein Depot für Komponenten vor, die durch die Client-Software unter Verwendung von vorbe stimmten Standardschnittstellen gesucht werden kön nen; dieses Depot ermöglicht es, daß die Client- Software die gleiche COM-Komponente gemeinsam verwen det, was folglich die Konsistenz bzw. Übereinstimmung unter Anwendungen erleichtert und sicherstellt, daß alle Anwendungen einen Vorteil daraus ziehen, wenn die COM-Komponente aktualisiert wird.

Ein weiteres Merkmal des computerimplementierten Verfahrens sieht vor, daß Auftragsdaten zu dem Drucksoftwareobjekt in der Form von Bezugnahmen auf Seiten (wobei der Lieferant der Auftrags daten für das Zeichnen der Seiten verantwortlich ist) gelie fert werden. Dieser Prozeß des Lieferns von Auftragsdaten weist mehrere Vorteile auf. Fig. 3 ist ein UML-Diagramm, das das Weiterleiten der Auftragsdaten zwischen einer Anwendung 50 und dem Auftrags-Editier- und Liefer-System (d. h. dem Drucksoftwareobjekt 21) darstellt.

In Fig. 3 stellt die Anwendung 50 eine der möglichen Quellen von Bilddaten, einschließlich Anwendungen, wie z. B. die Windows-Anwendung 22 in Fig. 2a, Treiber, die die Auftrags informationen erfassen, wie z. B. der Druckertreiber 32 in Fig. 2b, und spezielle Software dar, die Auftragsinformatio nen von den Server-Systemen (z. B. SAP), wie z. B. dem Ser ver-Haken 46 in Fig. 2c, liefert.

Fig. 3 zeigt ein UML-Klassen-Diagramm. Das UML-Klassen-Dia gramm stellt dar, daß die Seitenbildsatzobjekte 51, die die Seitenbildobjekte 52 besitzen, von der Auftragsinformations quelle (d. h. der Anwendung 50) zu dem Auftrags-Editier- und Liefer-Teilsystem (d. h. dem Drucksoftwareobjekt 21) weiter geleitet werden. Die Seitenbildsatzobjekte 51 und die Sei tenbildobjekte 52 sind abstrakte Objekte. Die tatsächlichen konkreten Typen (oder Beispiele) dieser Objekte besitzen eine spezifische Art von Bilderzeugungsinformationen. Daher werden die tatsächlichen Beziehungen zwischen den konkreten Objekten aus der "Haben"-Beziehung zwischen den abstrakten Objekten Seitenbildsatz und Seitenbild abgeleitet. Eine Implementation des abstrakten Seitenbildsatzobjekts 51 und der Seitenbildobjekte 52 kann ein verbessertes Meta-Datei- Format (EMF-Format; EMF = Enhanced Meta File) verwenden. Wie es in Fig. 3 gezeigt ist, ist das konkrete EMF-Seiten bildsatzobjekt 53 aus konkreten EMF-Seitenbildobjekten 54 ("Haben"-Beziehung) zusammengesetzt. Ähnlicherweise kann eine weitere Implementation ein Postscript-Format verwenden. Daher ist der konkrete Postscript-Seitenbildsatz 55 aus konkreten Postscript-Seitenbildobjekten 56 zusammengesetzt.

Eine Beispielliste von Funktionen, die in den Schnittstellen des Seitenbildsatzes 51 und des Seitenbilds 52 vorgefunden wird, ist in Fig. 4 in der Programmiersprache C++ für Dar stellungszwecke gezeigt.

Wie in Fig. 4 gezeigt, liefert die Klasse-ISeitenbild- Schnittstelle zwei Funktionen. Eine Drawing-Funktion (Zeich nenGDI) ist für das Zeichnen auf den gelieferten Vorrich tungszusammenhang (DC; DC = Device Context) unter Verwendung des Transformierens, Drehens und Skalierens, das durch die oberen linken und unteren rechten Punkte geliefert wird, angedeutet. Ein DrawModus-Parameter wird ferner zugeführt, so daß die Wechselwirkung mit der GDI nach Bedarf verändert werden kann. Diese ermöglicht es dem Seitenbildlieferant, die GDI-Aufrufe basierend auf dem Typ des Vorrichtungs kontexts (Anzeige, Drucker oder Metadatei) anzupassen. Es ist beispielsweise nicht unüblich, daß Anwendungen unter schiedlich mit der GDI abhängig davon wechselwirken, ob die Anwendung anzeigt oder druckt.

Die Funktion GetSettingsBundle (Hole Einstellungsbündel), die in Fig. 4 gezeigt ist, gewinnt eine Einstellungsbündel datenstruktur wieder, die nicht detailliert hier beschrieben ist, da dieselbe für das Verständnis der beanspruchten Erfindung nicht notwendig ist. Einzelne Seiten können zugeordnete Einstellungen aufweisen, beispielsweise eine Einstellung, die bestimmt, auf welchen Medientyp zu drucken ist. Das Auftrags-Editier- und Liefer-System, wie z. B. das Softwaredruckobjekt 21, verwendet die Einstellungen, um zu bestimmen, welche Einstellungen auf die logischen und physischen Seiten anzuwenden sind, die sich von den Seitenbildern, wie im folgenden erörtert, unterscheiden.

Ähnlicherweise liefert die ISeitenbildsatz-Schnittstelle (IPageImageSet-Schnittstelle) ein GetSettingsBundle- Verfahren (oder eine GetSettingsBundle-Funktion), die eine ISettingsBundle-Datenstruktur (oder ein Bündel von Daten) wiedergewinnt. Dieses Bündel enthält Einstellungen, die für den gesamten Satz von Seiten relevant sind, der innerhalb eines Seitenbildsatzes umfaßt ist. Beispielsweise kann dieses Bündel Einstellungen, wie z. B. ob die Seiten zusammenzustellen sind oder nicht, und die Anzahl der gewünschten Kopien enthalten. Einstellungen, die auf die Bilder anwendbar sind, können ferner innerhalb des Seiten bildsatzeinstellungsbündels gespeichert sein. Indem dies durchgeführt wird, werden die Seitenbildeinstellungen auf alle Seiten innerhalb des Seitenbildsatzes angewendet, als ob die Einstellungen in jedem einzelnen Seitenbild gespei chert wären. Einzelne Seitenbildeinstellungen besitzen jedoch Vorrang gegenüber Seitenbildsatzeinstellungen.

Zurückkehrend zu Fig. 3 ist die Anwendung 50 für das Imple mentieren sowohl der ISeitenbild-Schnittstelle als auch der ISeitenbildsatz-Schnittstelle und für das Verwenden dieser Schnittstellen, um die Druckauftragsbeschreibung zu dem Auftrags-Editier- und Liefer-System weiterzuleiten, wie es durch das Drucksoftwareobjekt 21 implementiert ist, verant wortlich. Um dies durchzuführen, muß die Anwendung 50 mit einer Schnittstelle wechselwirken, die durch das Auftrags- Editier- und Liefer-System vorgesehen wird.

Fig. 5 stellt einen Pseudocode für eine Beispielschnitt stelle zu dem Auftrags-Editier- und Liefer-System dar, das durch die vorliegende Erfindung vorgesehen wird. Der Pseudo code, der in Fig. 5 für die IAuftragseditier-und-Liefer- System-Schnittstelle dargestellt ist, definiert zwei Ver fahren. Das erste Verfahren AcceptPageImages (Akzeptiere Seitenbilder) wird verwendet, um Seitenbilder in das Auf trags-Editier- und Liefer-System einzuführen. Dieses Ver fahren akzeptiert bzw. nimmt einen Seitenbildsatz und eine Sammlung von Seitenbildern auf. Das Auftrags-Editier- und Liefer-System führt die Zuordnung zwischen dem Seitenbild satz und den Seitenbildern basierend auf den Seitenbildern und dem Seitenbildsatz durch, die als Parameter zu einem gleichen Verfahrensaufruf geliefert werden. Der gleiche Sei tenbildsatz kann verwendet werden, um zusätzliche Seitenbil der zu dem Seitenbildsatz hinzuzufügen. Die Seitenbilder in einem Seitenbildsatz sind geordnet. Zusätzliche Seiten, die zu einem Seitenbildsatz hinzugefügt werden, werden an den Seitenbildsatz angehängt.

Die Seitenbilder werden gemäß der aktuellen Einstellung, die einem Auftrag zugeordnet ist, verarbeitet, sobald sich die selben innerhalb des Auftrags-Editier- und Liefer-Systems befinden. Einige Beispiele von Auftragseinstellungen umfas sen die Anzahl der Kopien, das Duplex-Drucken (doppelseiti ges Drucken), das Heften und andere Papierhandhabungsoptio nen. Das Modifizieren des Auftragsobjekts und der Bestandteile desselben kann die Einstellungen ändern, die dem Auf trag zugeordnet sind. Die GetJob-Funktion (Hole-Auftrag- Funktion) ermöglicht es der Anwendung 50, einen Zugriff auf den Auftrag für Modifikationszwecke zu gewinnen.

Fig. 6 ist eine Darstellung einer Pseudocodeimplementation für eine beispielhafte Auftragsschnittstelle. Diese Beispielschnittstel le, die in Fig. 6 dargestellt ist, liefert Verfahrensproto typen zum Gewinnen eines Zugriffs auf die Auftragsbestand teile, wie z. B. die Dokumente, die den Druckauftrag bilden, durch das Verfahren GetDefaultDocument( ) (Holen des Stan darddokuments). Dieselbe liefert ferner einen Zugriff auf Auftragseinstellungen durch das Verfahren ISettingsBundle( ) (IEinstellungsbündel) und Verfahren, um diese Einstellungen durch einen Austausch oder durch ein Mischen durch Vorsehen beispielsweise eines Verfahrens MergeSettingsBundle( ) (Mi schen des Einstellungsbündels) und ein Verfahren Replace- SettingsBundle( ) (Austauschen des Einstellungsbündels) zu modifizieren. Das Implementieren des Programmcodes, der diese und andere Verfahren, die hierin erörtert sind, imple mentiert, liegt innerhalb der Fähigkeiten eines Fachmanns, wobei weitere Implementationsdetails dieser Verfahren sind nicht angegeben sind, da dieselben für ein Verständnis der beanspruchten Erfindung nicht notwendig sind.

Fig. 7 stellt die Struktur eines Druckauftrags als ein modi fiziertes UML-Klassendiagramm dar. Jede Klasse, die in Fig. 7 dargestellt ist, liefert gleichartige Schnittstellen für einen Zugriff und eine Modifikation der Klasseneinstellungen und der Klassenbestandteile. Zur Verkürzung sind die Details jeder dieser Klassen weggelassen, da dieselben für ein Ver ständnis der Erfindung nicht wesentlich sind. Unter Verwen dung der Schnittstellen, die durch jede dieser Klassen ge liefert werden, kann eine Anwendung die Struktur des Auf trags navigieren und Veränderungen an den Einstellungen, die dem Auftrag zugeordnet sind, durchführen. Es ist wichtig zu bemerken, daß diese Modifikationen typischerweise nicht er forderlich sind, da die meisten betroffenen Einstellungen durch das direkte Zuordnen derselben zu einem Seitenbildsatz oder einem Seitenbild (d. h. Einstellungen werden auf die logische Seite oder das Dokument angewendet) geliefert wer den.

Fig. 7 zeigt auf einem physischen Niveau, daß eine oder meh rere physische Seiten 60 (die gedruckt werden sollen) eines oder mehrere Blätter 61 bilden. Auf dem logischen Niveau bildet eine oder mehrere logische Seiten 62 ein oder mehrere Dokumente 63. Ein oder mehrere Dokumente 63 bilden ihrer seits einen oder mehrere Druckaufträge 64. Eine physische Seite 60 wird auf Null oder mehrere logische Seiten 62 abge bildet. Auf dem Bilderzeugungsniveau bildet ein oder mehrere Seitenbilder 52 einen oder mehrere Seitenbildsätze 51. Ein oder mehrere Seitenbildsätze 51 bilden den Druckauftrag 64. Null oder mehrere logische Seiten 62 werden ihrerseits auf Null oder mehrere Seitenbilder 52 abgebildet. Daher sieht die vorliegende Erfindung vor, daß Druckauftragsinformatio nen in der Form von Bezugnahmen auf Seiten, wie im vorher gehenden unter Bezugnahme auf Fig. 3 erörtert, geliefert werden.

Das Akzeptieren von Auftragsdaten in der Form von Seiten objekten, wie es bei der vorliegenden Erfindung vorgesehen ist, liefert wesentliche Vorteile. Einige dieser Vorteile sind:

a) da der Druckauftraglieferant die Auftragsdaten nicht in ein zusätzliches Zwischenformat umwandeln muß, wird das Verhalten drastisch verbessert;
b) da der Druckauftragslieferant (z. B. die Anwendung) bereits einen geschriebenen Programmcode aufweist, um zu der GDI zu zeichnen, ist der Anstrengungsaufwand, der erforderlich ist, um das Drucken anzupassen, um das Auftrags-Editier- und Liefer-Teilsystem zu unterstützen, minimal;
c) da die verwendete Bilderzeugungsschnittstelle die GDI ist, besteht keine Notwendigkeit, eine eigene Zwi schenbilderzeugungsdarstellung zu dokumentieren oder zu erzeugen;
d) die Arbeit des Erzeugens eines Kanals (eines spezi ellen Auftragsdatenlieferants oder eines Auftrags erfassungsteilsystems, das einen Auftrag von einem existierenden Drucksystem erfaßt) wird ordentlich zwischen dem Kanal und dem Auftrags-Editier- und Liefer-Teilsystem geteilt; der Kanal ist für das Erfassen der Auftragsinformationen, für das Über tragen derselben zu einer Host-Anwendung und für das Liefern der Auftragsinformationen in Seiteninkremen ten als Objekte verantwortlich; das Auftrags-Editier- und Liefer-System kann daher unabhängig von dem Kanal entwickelt werden; dies ermöglicht eine starke Paral lelisierung bei der Softwareentwicklung und der zeit lichen Abstimmung;
e) das Umwandeln der Seite wird solange vermieden, bis es absolut erforderlich ist; das Auftrags-Editier- und Liefer-Teilsystem gemäß der vorliegenden Erfin dung fragt lediglich bei dem Auftragsdatenlieferanten an, die Seite zu zeichnen, wenn die Seite absolut auf dem Bildschirm gezeichnet, gedruckt oder in ein Meta datei-Format umgewandelt werden muß;
f) GDI und COM sind ursprüngliche (und vermerkte) Micro soft-Technologien und werden für die kommerzielle Softwareentwicklung und die kommerzielle Software implementation weit verbreitet verwendet;
g) das Auftrags-Editier- und Liefer-System ist unabhän gig von dem Bilderzeugungsmodell; daher ist die vor liegende Erfindung gleichermaßen auf alle Bilderzeu gungssysteme, die verwendet werden (DDI, PostScript, etc.) bis zu dem Grad anwendbar, daß dieselben zurück auf GDI abbilden.

Fig. 8 ist ein Flußdiagramm, das den Betrieb eines bevorzug ten Ausführungsbeispiels des computerimplementierten Auftrags-Editier- und Liefer verfahrens zeigt. Bei dem be vorzugten Ausführungsbeispiel weist das Auftrags-Editier- und Liefer-System ein Auftragserfassungsteilsystem und ein Auftrags-Editier- und Liefer-Teilsystem auf. In einem Schritt 800 wird das Auftragserfassungsteilsystem ("JCSS") aufgerufen. Ein JCSS kann auf mehreren Maschinen und in meh reren Adreßräumen aufgerufen werden und dient dazu, um Druckauftragsinformationen von unterschiedlichen Quellen der Druckauftragsinformationen, wie z. B. Anwendungen, speziali sierte Druckertreiber oder andere Server-Anwendungen, zu erfassen. In einem Schritt 805 wird das Auftrags-Editier- und Liefer-Teilsystem ("JEDSS"; JEDSS = Job Editing And Delivery Subsystem), ein COM-Objekt, in einem der JCSS- Adreßräume gestartet.

Bei einem Schritt 810 liefert das JCSS die Druckauftrags informationen in der Form von Seitenbildbezugnahmen auf das JEDSS. Bei einem Schritt 815 zeigt das JEDSS eine Vorschau von ausgewählten Seiten an, indem das JCSS aufgerufen wird, und das JCSS die Seitenbilder bei einem Schritt 820 anspre chend auf den Aufruf von dem JEDSS zeichnet. Danach gibt das JEDSS dem Benutzer eine Gelegenheit, die Auftragseinstellun gen beim Schritt 825 zu verändern.

Bei einem Schritt 830 überprüft das JEDSS, ob Auftragsein stellungen modifiziert wurden, und wenn dies der Fall ist, zeigt das JEDSS eine Vorschau der relevanten Seiten mit den modifizierten Auftragseinstellungen an, indem zu den Schrit ten 815 und 820 fortgeschritten wird. Wenn es bei dem Schritt 830 keine Auftragseinstellungsänderungen gibt, druckt das JEDSS die Seitenbilder, indem bei einem Schritt 840 mit dem geeigneten Vorrichtungskontext zum Drucken oder zum Schreiben zu einer Metadatei zu dem JCSS zurückgerufen wird.

Bei einem Schritt 840 bereitet das JEDSS das Drucken der Seitenbilder durch ein Zurückrufen zu dem JCSS mit einem geeigneten Vorrichtungskontext vor, wodurch es demselben Befehle für das Drucken oder Ausgeben der Seitenbilder liefert. Das JEDSS liefert dem JCSS den Vorrichtungskontext zum Drucken oder Speichern der Seiten in einer Metadatei.

Bei einem Schritt 845 zeichnet das JCSS die Seitenbilder gemäß den Befehlen, die durch das JEDSS geliefert werden. Wenn beispielsweise bei einem Schritt 840 das JEDSS einen Metadatei-Vorrichtungskontext liefert, zeichnet das JCSS daraufhin gemäß dem gelieferten Vorrichtungskontext. Wenn danach das JEDSS eine Metadatei von dem JCSS erhält, ist dann das JEDSS für das Übersetzen der Metadatei in eine geeignete Druckersprache und für das Senden zu dem Drucker für ein weiteres Verarbeiten bei einem Schritt 850 verantwortlich. Wenn bei dem Schritt 840 das JEDSS einen Druckervorrichtungskontext liefert, verwendet das JCSS einen existierenden Druckertreiber, der die GDI-Aufrufe, die durch das JCSS durchgeführt würden, in die geeignete Drucker sprache umwandelt, und sendet bei dem Schritt 850 den Auftrag zum Verarbeiten durch ein Drucksystem. Bei einem alternativen Ausführungsbeispiel kann das Auftrags-Editier- und Liefer-System der vorliegenden Erfindung selbst die Druckauftragsinformationen in eine geeignete Druckersprache übersetzen und für das Drucken weiterleiten. Nach dem Verarbeiten durch das Drucksystem bei dem Schritt 850 wird der Verarbeitungszyklus für das Auftrags-Editier- und Liefer-System bei einem Schritt 855 beendet.

Bei dem Schritt 850 druckt das Drucksystem entweder den Auf trag gemäß dem Vorrichtungskontext und der Auftragsdaten, die durch das JCSS bei einem Schritt 845 geliefert werden, oder speichert den Auftrag in einem Speichermedium für ein zukünftiges Verarbeiten. Der gespeicherte Auftrag umfaßt die Speicherung des in eine geeignete Druckersprache, wie z. B. PCL oder Postscript, übersetzten Auftrags.

Es sei bemerkt, daß bei dem bevorzugten Ausführungsbeispiel die Druckauftragsdaten, die durch einen Benutzer editiert oder modifiziert werden, nicht das direkte Modifizieren der Bilderzeugungsdaten umfassen. Die Druckauftragsdaten, die durch den Benutzer modifizierbar sind, umfassen typischer weise die Drehung, die Verschiebung und das Skalieren der Bilder, die Papierhandhabungs- und Zusammenstellungs- Merkmale, Auflagen, Unterlagen, Filter und dergleichen. Ein Filter kann verwendet werden, um ein Seitenbild in eine Metadatei umzuwandeln, wonach die Metadatei editiert werden kann, um die Bilderzeugungsinformationen indirekt zu modifizieren.

Es ist ein computerlesbares Datenspeichermedium denkbar, das auf demselben einen aufgezeichneten Programm code für ein benutzereditierbares Druckauftrags-Editier- und Liefer-Verfahren gemäß der vorliegenden Erfindung aufweist, wobei der Programmcode einen ersten Programmcode, der ein Drucksoftwareobjekt als eine COM-Kom ponente zum Editieren und Liefern des Druckauftrags liefert, einen zweiten Programmcode, der Auftragsdaten des Druck auftrags zu dem Drucksoftwareobjekt in der Form von Be zugnahmen auf Seiten liefert, wobei das Drucksoftwareobjekt die Bezugnahme auf die Seiten verwendet, um die Seiten auf einer Bedarfsbasis aufzurufen und anzuzeigen, und die Auftragsdaten des Druckauftrags basierend auf der Antwort des Benutzers auf die angezeigten Seiten editiert, und einen dritten Programmcode aufweist, der den Druckauftrag zum Verarbeiten gemäß den editierten Auftragsdaten liefert.

Claims

1. Computerimplementiertes Verfahren, mit dem ein Benut zer einen Druckauftrag, der von einer Druckauftrags quelle (22; 31; 44) stammt, in einem Computersystem editiert und liefert, wobei das Verfahren folgende Schritte aufweist:
Bereitstellen (805) eines Auftrags-Editier- und Liefer-Teilsystems als ein COM-Objekt (21) zum Editieren und Liefern des Druckauftrags;
Liefern (810) von Druckauftragsinformationen in Form von Verweisen auf Seiten von der Druckauftragsquelle (22; 31; 44) oder einem Auftragserfassungsteilsystem (32; 46) zum Erfassen des Druckauftrags zu dem Auf trags-Editier- und Liefer-Teilsystem (21);
Anzeigen (815) einer Vorschau von ausgewählten Seiten durch das Auftrags-Editier- und Liefer-Teilsystem (21) durch ein Zurückrufen der Druckauftragsquelle (22; 31; 44) oder des Auftragserfassungsteilsystems (32; 46), um die ausgewählten Seiten unter Verwendung der Ver weise auf die ausgewählten Seiten auf einem Bildschirm zu zeichnen;
Editieren (825) der Druckauftragsinformationen durch den Benutzer, der die Vorschau der ausgewählten Seiten betrachtet;
Modifizieren der Druckauftragsinformationen durch das Auftrags-Editier- und Liefer-Teilsystem (21) gemäß den editierten Druckauftragsinformationen; und
Liefern (840) des Druckauftrags zur Verarbeitung gemäß den editierten Druckauftragsinformationen.

2. Computerimplementiertes Verfahren gemäß Anspruch 1, bei dem das Softwaredruckobjekt (21) als eine In- Prozeß-COM-Komponente vorgesehen ist, die in einem Adreßraum der Druckauftragsquelle (22) gestartet wird.

3. Computerimplementiertes Verfahren gemäß Anspruch 1 oder 2, bei dem der Schritt des Lieferns der Druck auftragsinformationen durch die Durckauftragsquelle (22) durchgeführt wird.

4. Computerimplementiertes Verfahren gemäß Anspruch 3, bei dem die Durckauftragsquelle (22) eine lokale Anwendung (22) ist.

5. Computerimplementiertes Verfahren gemäß Anspruch 1, bei dem der Schritt des Lieferns (810) der Druck auftragsinformationen durch das Auftragserfassungs teilsystem (32; 46) durchgeführt wird.

6. Computerimplementiertes Verfahren gemäß Anspruch 5, bei dem das Softwaredruckobjekt (21) als eine In- Prozeß-COM-Komponente vorgesehen ist, die in einem Adreßraum des Auftragserfassungsteilsystems (32) gestartet wird.

7. Computerimplementiertes Verfahren gemäß Anspruch 5, bei dem das Auftragserfassungsteilsystem (32) einen spezifisch programmierten Druckertreiber (32) umfaßt, wobei das Verfahren ferner das Übertragen des Druck auftrags von der Anwendung (31) zu dem spezifisch programmierten Druckertreiber (32) umfaßt.

8. Computerimplementiertes Verfahren gemäß Anspruch 5, bei dem die Druckauftragsquelle (44) eine lokale Klientanwendung (43) umfaßt, die mit einer Sitzung (44) auf einer Servermaschine (41) verbunden ist, wobei das Auftragserfassungsteilsystem (46) einen Serverhaken (46) umfaßt, der in der Servermaschine (41) vorgehen ist, wobei das Verfahren ferner das Erfassen des Druckauftrags (45) von der Sitzung (44) umfaßt.

9. Computerimplementiertes Verfahren gemäß einem der Ansprüche 1 bis 8, bei dem der Schritt des Lieferns folgenden Teilschritt aufweist:
Zurückaufrufen der Druckauftragsquelle (22) oder des Auftragserfassungsteilsystems (32; 46) zum Drucken durch das Auftrags-Editier- und -Liefer-System (21) gemäß den modifizierten Druckauftragsinformationen.