DE69712592T2

DE69712592T2 - Verfahren und Vorrichtung zur Verarbeitung und zum Drucken von Dokumenten

Info

Publication number: DE69712592T2
Application number: DE69712592T
Authority: DE
Inventors: Robert Chou; Sachin Naik; Taylor, Iii; Kirt Alan Winter
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 1996-12-09
Filing date: 1997-11-18
Publication date: 2002-08-29
Anticipated expiration: 2017-11-19
Also published as: DE69712592D1; US5867633A; EP0847002B1; JPH10248014A; EP0847002A1

Description

Die vorliegende Erfindung bezieht sich allgemein auf das Verarbeiten von Dokumenten und insbesondere auf ein Verfahren und ein System zum Vorbereiten von Dokumenten für das Drucken.

STAND DER TECHNIK

Die Bildverarbeitung ist aufgrund der Leichtigkeit und Verfügbarkeit der Hardware und Software, die verwendet wird, um Bilder zu erfassen, zu einer alltäglichen Aktivität geworden. Die Popularität und die leichte Zugänglichkeit des Internets und insbesondere die Erzeugung des World Wide Web haben die Verwendung von Bildern stark erhöht. Das Verarbeiten von erfaßten Bildern und anderen graphischen Elementen ist jedoch im allgemeinen komplexer als das Verarbeiten von Textdaten. Beispielsweise müssen Farbbilder zwischen einer Videoanzeige und einem Drucker farblich angepaßt werden, kantenverbessert, um bestimmte Merkmale zu extrahieren usw. Solche Manipulationen sind tendenziell CPU-intensiv (CPU = central processing unit = zentrale Verarbeitungseinheit), und aufgrund der großen Datenmengen, die Bilddateien, insbesondere großen Farbbildern, typischerweise zugeordnet sind, neigen solche Manipulationen auch dazu, I/Ointensiv zu sein. Ein Bereich, der durch die erhöhte Verwendung von Bildern beeinträchtigt ist, ist beispielsweise die Vorbereitung und das Drucken von Dokumenten, die solche Bilder enthalten.
Aufgrund der Verfügbarkeit von hochentwickelten Textverarbeitungs- und anderen Desktop-Publishing-Programmen bestehen Dokumente im allgemeinen nicht mehr nur aus Textdaten, sondern umfassen eine Vielzahl von Bildern. Das Vorbereiten von solchen Dokumenten für das Drucken auf einem Computer kann mehrere Bildverarbeitungsoperationen erfordern, einschließlich Skalieren, Abschneiden, Scharfzeichnen, verschiedene Transformationen, und dergleichen. Diese Operationen werden entweder durch die Anwendung oder durch die Druckertreibersoftware durchgeführt, die in dem Drucker enthalten ist. Als eine Folge des Einschließens von Bildern in ein Dokument erfährt das Computersystem aufgrund der Verarbeitung der großen Datenmengen, die für graphische Bildelemente typisch sind, einen hohen Grad an Belastung. Es gibt mehrere Lösungsansätze für die Dokumentvorbereitung und das Dokumentdrucken.
Einige Anwendungen bereiten eine geräteunabhängige Bittabelle eines Bildes des zu druckenden Dokuments vor. Die Bittabelle wird dann über die entsprechende Druckertreibersoftware zu einem Drucker gesendet. In den meisten Fällen hat die Anwendung keine Kenntnis von den Anforderungen des Druckers. Ein Benutzer kann beispielsweise entscheiden, ein Bild mit mittlerer Qualität unter Verwendung einer bestimmten Sorte Papier zu drucken. Dies erfordert, daß ein Bild des Dokuments mit einer bestimmten Auflösung und Bittiefe erzeugt wird. Die Anwendung kann nicht die Auflösung und/oder Bittiefe bestimmen, die benötigt wird, um die Ausgabe gemäß den Druckparametern, die von dem Benutzer ausgewählt wurden, aufzubereiten. Solches Wissen ist in dem Druckertreiber enthalten. Die Anwendung, die jede Art von Drucker umfassen bzw. mit derselben funktionieren muß, führt daher einen konservativen Lösungsansatz durch und sendet eine Kopie einer Bittabelle des Bildes mit hoher Auflösung an den. Druckertreiber. Der Druckertreiber führt dann an der empfangenen Kopie des Bildes mit hoher Auflösung eine zusätzliche Verarbeitung durch (z. B. eine Dezimierung), um eine Ausgabe für den Drucker mit der geeigneten Auflösung zu erzeugen.
Dieser einfache Lösungsansatz ist eine sehr ineffiziente Weise des Druckens. Die Anwendung erzeugt immer eine Kopie des Dokuments mit hoher Auflösung, unabhängig von dem Drucker und den ausgewählten Druckparametern. Dies bedeutet die unnötige Verarbeitung von großen Datenmengen, was übermäßige Plattenaktivität erfordert, während Zwischendateien erzeugt werden, auf die Platte geschrieben werden, von der Platte gelesen werden, verarbeitet werden, zurück auf die Platte geschrieben werden, usw. Eine solche Aktivität hat einen nachteiligen Effekt für den Benutzer, da der Zugriff auf die CPU blockiert ist, bis der Druckauftrag abgeschlossen ist.
Bei einem anderen Lösungsansatz fragt die Dokumentverarbeitungsanwendung den Drückertreiber ab, um zu bestimmen, welche Bildverarbeitungsfähigkeiten in dem Druckertreiber vorliegen. Die Anwendung entscheidet dann, wie die Bildverarbeitungsaufgaben zwischen der Anwendung und dem Druckertreiber auf zuteilen sind. Die Anwendung erzeugt ein geeignetes Bild des Dokumentes und sendet eine Kopie des Bildes an den Druckertreiber. Der Druckertreiber führt jede erforderliche zusätzliche Verarbeitung an der Kopie des empfangenen Bildes durch, und gibt ein endgültiges Druckerbild des Dokumentes an den Drucker aus. Die Kenntnis über die Bildverarbeitungsfähigkeiten des Druckertreibers verbessert die Effizienz, da eine druckerspezifische Verarbeitung, wie z. B. Ausgabeauflösungserzeugung, durch den Druckertreiber durchgeführt wird. Die Anwendung braucht keine Bittabelle mit hoher Auflösung mehr zu erzeugen, in dem Versuch, alle Drucker zu umfassen. Statt dessen führt die Anwendung nur geräteunabhängige Operationen durch, wie z. B. Abschneiden, Korrektut roter Augen, Scharfzeichnen, usw. -Operationen, die typischerweise nicht durch den Druckertreiber unterstützt werden. Dies führt zu einer kleineren Bilddatei, die dann von der Anwendung zu dem Treiber weitergeleitet wird. Aus der Sicht des Benutzers ist die CPU jedoch weiterhin belegt, bis die Anwendung das Bild verarbeitet hat und eine Kopie des Bildes zu dem Druckertreiber weitergeleitet hat, an welchem Punkt der Druckertreiber zusätzliches druckerspezifisches Verarbeiten an der empfangenen Kopie des Bildes durchführt, und das erzeugte Druckerbild an den Drucker ausgibt.
Um das Warten zu verkürzen, verwenden die meisten Computer eine Technik, die als Spooling bzw. Spoolbetrieb bekannt ist, um die CPU so schnell wie möglich von einem Druckauftrag zu dem Benutzer zurückzugeben. Das Druckerbild, d. h. das Bittabellenbild, das tatsächlich zu dem Drucker gesendet wird, wird auf die Platte kopiert und als Hintergrundprozeß an den Drucker gesendet. Dies ermöglicht es dem Druckertreiber, die Steuerung des Computers zu dem Benutzer zurückzugeben, ohne darauf warten zu müssen, daß die tatsächliche Ausgabe erzeugt wird. Das Übertragen des endgültigen Druckerbildes zu dem Drucker stellt oft jedoch nur einen kleinen Bruchteil des gesamten Aufwandes des Druckauftrags dar, wobei sowohl die Anwendung als auch der Druckertreiber den meisten Aufwand und Zeit benötigen, um das Druckerbild des Dokumentes überhaupt erst zu erzeugen.
Ein Betriebssystem hat die Spooling- bzw. Spul-Technik einen Schritt weiter geführt. Unter dem Microsoft® Windows 95-Betriebssystem wurde ein Verfahren implementiert, das als verbessertes Metadatei-Format (EMF = enhanced metafile format) -Spooling bezeichnet wird. Mit EMF-Spooling spult das Betriebssystem (OS = operating system) alle Aufrufe, die die Anwendung dem Druckertreiber gegenüber unternimmt, auf eine Spul-Datei, bzw. lagert dieselbe auf dieselbe aus, fast auf die gleiche Weise, wie ein Druckerbild derzeit gespult wird. Das OS gibt dann die gespulte Datei wieder, sendet die gespulten Informationen an den Druckertreiber und beendet den Druckauftrag somit vollständig im Hintergrund. Die Steuerung des Computers wird unter EMF-Spooling schneller an den Benutzer zurückgegeben, da der Benutzer nicht mehr darauf warten muß, daß der Druckertreiber seine Bildverarbeitungsoperationen durchführt.
Aber selbst mit EMF-Spooling gibt es nach wie vor Faktoren, die die Systemleistung während dem Drucken beeinträchtigen.
Am bemerkenswertesten ist die Tatsache, daß große Datenmengen durch das System geleitet werden. Man nehme beispielsweise ein 24-Bit-Farbdigitalbild eines 8" · 10" Photos an. Etwa 20 Megabyte Daten werden benötigt, um ein solches Bild bei 300 dpi darzustellen, und 80 Megabyte Daten bei 600 dpi. Mit EMF-Spooling spoolt das Betriebssystem die Aufrufe auf, die von der Anwendung an dem Druckertreiber durchgeführt wurden, zusammen mit einer Kopie der 20 oder 80 Megabyte Daten, die das Bild darstellen. Die gespoolte Datei wird auf Platte geschrieben. Während der Wiedergabe wird die gespoolte Datei (die die 20 Megabyte Bilddaten umfaßt) von der Platte abgerufen und an den Druckertreiber weitergeleitet. Während der Druckertreiber das Druckerbild vorbereitet, werden temporäre Dateien erzeugt, auf der Platte gespeichert, von der Platte gelesen, zurück auf die Platte geschrieben usw. Alle diese Plattenaktivität fordert ihren Tribut bei der Antwortzeit und Gesamtleistung des Betriebssystems. Was der Benutzer wahrnimmt, ist ein sehr langsames und anderweitig nicht antwortendes System.
Obwohl sich die vorhergehende Erörterung auf die Engpässe konzentriert hat, die während dem Verarbeiten eines Druckauftrags erlebt werden, bestehen ähnliche Engpässe bei dem Verarbeiten von Bildern im allgemeinen. Was benötigt wird, ist ein Verfahren und ein System, das die Datenmenge, die während der Handhabung und Verarbeitung von Bildern durch das Betriebssystem weitergeleitet wird, minimiert. Insbesondere wird ein Verfahren und ein System benötigt, um einen Druckauftrag effizienter zu verarbeiten. Es ist außerdem wünschenswert, die Plattenaktivität zu minimieren, die das Betriebssystem während dem Verarbeiten eines Bildes, wie z. B. während einem Druckauftrag erlebt.
Die US-A-5 579 087 beschreibt eine Technik zum Zusammenstellen eines Druckauftrags aus mehreren Bildsegmenten, die über ein Netzwerk verteilt sind. Ein Betreiber identifiziert Druckauftragsegmente und deren Position auf dem Netzwerk, und auch die Druckauftragcharakteristika und ein Druckgerät, so daß auf jedes Segment des Druckauftrags zugegriffen wird und dieselben zu dem Druckgerät verteilt werden, um den Mehrfachsegment-Druckauftrag durchzuführen.
Die US-A-5 559 933 beschreibt ein verteiltes System, das den Druckauftragsfluß über ein Netzwerk bearbeitet, was es ermöglicht, daß unterschiedliche Druckertypen von unterschiedlichen PCs und Großcomputern gemeinschaftlich verwendet werden. Die Hauptkomponente ist ein Stapelauftrag, der im Hintergrund ausgeführt wird. Die Steuerung von Druckaufträgen basiert auf Dateicharakteristika und der Benutzer kann Druck- oder Übertragungsattribute spezifizieren, die in einer Dateimaske enthalten sind, was zu der Erzeugung eines Druckauftrags oder eines Übertragungsauftrages führt. Das System umfaßt eine Dateidatenbank, die Informationen darüber enthält, wo eine Druckdatei herkam, welche Art von Datei dieselbe ist und andere verwandte Informationen, und auch eine Dateimaskenbibliothek und eine Druckattributebibliothek.

ZUSAMMENFASSUNG DER ERFINDUNG

Gemäß der vorliegenden Erfindung ist ein Verfahren und ein System zum Verarbeiten von Bildern vorgesehen, wie es in Anspruch 1 bzw. 8 definiert ist. Das Verarbeiten eines Bildes, um eine gewünschte Erscheinung des Bildes zu erzeugen, beginnt mit dem Registrieren des Bildes bei einem Bildserver. Der Bildserver sendet eine Kennung zurück, die das Bild in dem Bildserver identifiziert. Bildverarbeitungsanforderungen werden dann gemäß der gewünschten Erscheinung des Bildes an den Bildserver gesendet. Das verarbeitete Bild wird dann von dem Bildserver wiedergewonnen.
Bei einem Ausführungsbeispiel umfaßt ein Verfahren und ein System zum Drucken eines Dokumentes das Registrieren des Dokumentes bei einem Bildserver und nachfolgend das Empfangen eines Identifizierers, der das Dokument identifiziert, von dem Bildserver. Das zu druckende Dokument wird bei dem Bildserver registriert, indem ein Dateideskriptor bzw. Dateibeschreiber an den Bildserver weitergeleitet wird, der die Position des Dokuments identifiziert. Der Dateibeschreiber ist typischerweise der Dateiname des Dokuments, der auf der Platte positioniert ist, kann aber auch ein Zeiger auf eine Position in gemeinschaftlich verwendetem Speicher sein, in dem das Dokument gespeichert ist. Nachfolgend wird der Identifizierer zu einem Druckertreiber weitergeleitet, zusammen mit Druckparametern, die die gewünschte Erscheinung des gedruckten Dokumentes beschreiben. Unter Verwendung des Identifizierers, um auf das Dokument zu verweisen, sendet der Druckertreiber Bildverarbeitungsanforderungen an den Bildserver, und weist letzteren an, ein Druckerbild zu bilden, durch Verarbeiten eines Bildes des Dokumentes gemäß den Druckparametern. Schließlich ruft der Druckertreiber das Druckerbild wieder von dem Bildserver ab, das nur aus den Bilddaten des verarbeiteten Dokuments besteht, die zum Herunterladen zu einem Drucker benötigt werden.
Die Datenmenge, die während dem Drucken durch das System geleitet wird, wird auf, ein Minimum begrenzt. Beispielsweise wird statt dem Kopieren von großen Datenmengen, die das Dokument darstellen, von dem Adreßraum eines Prozesses in den Adreßraum eines anderen Prozesses ein Identifizierer verwendet. Der Identifizierer dient dazu, das Dokument zu identifizieren, und weil er ein Identifizierer des Dokumentes ist und nicht das Dokument selbst, ist die weitergeleitete Datenmenge wesentlich geringer.
Ein weiteres Merkmal der vorliegenden Erfindung ist es, daß durch den Bildserver nur auf diejenigen Abschnitte des Bildes zugegriffen wird, die benötigt werden, um das endgültige Druckerbild zu bilden. Auf diese Weise ist der Bearbeitungsumfang der Bilder, die in einem Dokument enthalten sind, minimiert. Das Ergebnis ist eine geringere Plattenaktivität zum Speichern und Laden von Daten auf und von der Platte während der Bildung des Druckerbildes. Zusätzlich ist die Belastung der CPU geringer. Dies hat den Gesamteffekt, daß eine schnellere Durchlaufzeit für den Benutzer geliefert wird, der einen Druckbefehl ausgibt, und die Systemleistung verbessert wird.
Bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung führt die Benutzeranwendung, die den Druckauftrag auslöst, getrennt und unabhängig sowohl von dem Bildserver als auch von dem Druckertreiber aus. Gleichartig dazu können der Bildserver und der Druckertreiber getrennte, gleichzeitige und unabhängig ausführende Prozesse sein, falls das Betriebssystem einen Multi-Tasking-Betrieb unterstützt. Wenn der Bildserver eine Anforderung von einer Anwendung (z. B. einer Textverarbeitungsanwendung) empfängt, um ein Dokument zu registrieren, sperrt der Bildserver das Dokument, um andere Prozesse daran zu hindern, auf das Dokument zuzugreifen. Dies stellt die Integrität des Dokuments während der Zeit sicher, während der der Bildserver das gewünschte Druckerbild erzeugt. Trotzdem kann der Bildserver beim Empfangen einer nachfolgenden Freigabeanforderung eine temporäre Kopie des Dokumentes herstellen und das Original freigeben. Da auf das Dokument durch den Identifizierer verwiesen wird, der ursprünglich durch den Bildserver geliefert wird, werden Prozesse außerhalb des Bildservers durch das Kopieren nicht beeinträchtigt.
Bei einer Variation des bevorzugten Ausführungsbeispiels werden zwei oder mehr Anwendungen geladen, wobei jede ein zu druckendes Dokument auswählt und jede einen Druckauftrag gemäß der vorliegenden Erfindung ausgibt. Gleichartig dazu können zwei oder mehr Druckertreiber geladen werden, und als getrennte Programmeinheiten ausgeführt werden. Auf diese Weise kann mehr als eine Art von Drucker unterstützt werden. Jeder dieser Druckertreiber ist mit der Fähigkeit, mit seinem entsprechenden Drucker zu kommunizieren, geschrieben oder anderweitig konfiguriert.
Bei noch einer anderen Variation des bevorzugten Ausführungsbeispiels können sich der Bildserver und der/die Druckertreiber auf zwei oder mehr vernetzten Computern befinden. Die Anwendung(en) können mit dem Bildserver oder den Druckertreibern zusammen, positioniert sein, oder auf getrennten Computern positioniert sein. Dies liefert eine maximale Flexibilität beim Konfigurieren eines Aufstellungsorts mit mehreren Arbeitsstationen, die um einen Dateiserver und einen oder mehrere Drucker konfiguriert sind, während gleichzeitig die Leistungsvorteile realisiert werden, die durch die vorliegende Erfindung ermöglicht werden.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 ist ein Systemdiagramm eines Ausführungsbeispiels der vorliegenden Erfindung.
Fig. 2 stellt eine typische Sequenz von Ereignissen dar, wenn Dokumente gemäß der vorliegenden Erfindung verarbeitet werden.
Fig. 3 zeigt die Schnittstellen zwischen den Softwarekomponenten des Systems der vorliegenden Erfindung.
Fig. 4 ist ein Systemdiagramm der vorliegenden Erfindung, die in einer Netzwerkkonfiguration angeordnet ist.

BESTER MODUS ZUM AUSFUHREN DER ERFINDUNG

Der beste Modus, der zum Praktizieren der vorliegenden Erfindung bedacht wird, ist in dem in Fig. 1 gezeigten Systemblockdiagramm dargestellt. Bei einem Computersystem 40 erzeugen und manipulieren eine oder mehrere Benutzeranwendungen 100, 200 erzeugen Dokumente durch Interaktionen mit Benutzern. Solche Anwendungen umfassen Textverarbeitungsprogramme, Zeichenprogramme, Tabellenprogramme, Dokumentzusammenfügungsprogramme, Photobilderzeugungsprogramme und dergleichen. Der Begriff "Benutzer" ist hierin entweder als ein menschlicher Benutzer definiert, der mit der Anwendung in Wechselwirkung steht, oder ein automatisch Handelnder, der mit der Anwendung interagiert, z. B. eine Software, die eine Faxmaschine emuliert bzw. nachahmt, die automatisch ankommende Faxe empfängt, Bildscanningsoftware, automatische Datenwiedergewinnungssoftware, usw. Die Anwendungen 100, 200 haben Zugriff auf einen Datenspeicher 30 zum Speichern und Wiedergewinnen von Daten nach Bedarf. Der Datenspeicher 30 umfaßt ferner Bereiche in dem Adreßraum des Direktzugriffsspeichers (RAM) der Anwendung, und kann sich auf unterschiedliche Bereiche in einem gemeinschaftlich verwendeten Speicher beziehen. Ein Bildverarbeitungsserver 10 liefert Bildverarbeitungsfähigkeiten zum Handhaben von Dokumenten, die Bilder enthalten. Die Anwendungen 100, 200 kommunizieren mit dem Bildserver 10 durch eine Bildserverschnittstelle, die nachfolgend näher beschrieben wird. Wie die Anwendungen hat der Bildserver 10 Zugriff auf den Datenspeicher 30.
Einige der Anwendungen 100 sind in Kommunikation mit den Druckertreibern 30() gezeigt, mit denen Druckgeräte 22, 24 verbunden sind. Jeder oder Druckertreiber 200 ist spezifisch für einen speziellen Typ und/oder eine Art von Druckergerät geschrieben. Das Druckergerät 22 kann beispielsweise ein Plotter sein, während das Druckergerät 24 ein Laserdrucker ist. Alternativ können beide Druckergeräte 22, 24 Tintenstrahldrucker sein, aber von verschiedenen Herstellern und jeweils einen Treiber erfordern, der mit dem Gerät kommunizieren kann.
Ein Aspekt der Erfindung ist, daß die Druckertreiber 300 als unabhängig ausführende Programmeinheiten geladen werden können, d. h. jeder ist ein getrennter Prozeß. Die Kommunikation zwischen den Prozessen wird durch gut bekannte und voll verstandene IPC (interprocess communication)-Techniken geliefert, wie z. B. RPC OLE und COM. Die meisten Betriebssysteme unterstützen zumindest eine Form von Multitasking und sehen auch IPC unter Prozessen vor. Typische Betriebssysteme umfassen: die vielen Inkarnationen des UNIX- Betriebssystems, das Macintosh Betriebssystem, Windows 3.x, Windows '95 und Microsoft NT. Diese Liste ist selbstverständlich nur beispielhaft und soll nicht begrenzend sein. Die vorliegende Erfindung kann effektiv auf anderen Multitasking-Systemen implementiert werden, die IPC unterstützen.
Das in Fig. 2 gezeigte Flußdiagramm stellt die Schritte dar, die typischerweise durchgeführt werden, wenn Bilder und Dokumente gemäß der vorliegenden Erfindung gedruckt werden. Die in Fig. 2 gezeigte Sequenz entspricht den in Fig. 1 gezeigten Anwendungen 100 und Druckertreibern 300. Zunächst wird ein Dokumenmt von einer Anwendung 100 erhalten, entweder durch Einlesen einer Datei von dem Datenspeicher 30 und/oder von einer Eingabe, die durch den Benutzer der Anwendung geliefert wird, Schritt 60. Das Dokument wird durch den Namen der Datei auf der Platte identifiziert, oder durch einen Adreßzeiger in dem Speicher, wo das Dokument gespeichert ist. Zusätzlich zum Erhalten des Dokumentes erhält die Anwendung 100 von dem Benutzer Druckparameter, die die gewünschte Erscheinung des gedruckten Dokuments beschreiben.
Nachfolgend registriert die Anwendung 100 das Dokument bei dem Bildserver 10 durch Senden des Dateinamens oder des Adreßzeigers an den Bildserver, Schritt 62. Es wird hier daran erinnert, daß die Anwendungen 100, 200 und der Bildserver 10 unabhängig ausführende Prozesse sein können. Jeder Prozeß kann da her seinen eigenen logischen Adreßraum aufweisen, der im allgemeinen für andere Prozesse nicht direkt zugreifbar ist. Falls somit eine Anwendung ein Dokument durch einen Adreßzeiger registriert, muß sich das Dokument in einer gemeinschaftlich verwendeten Speicherregion befinden, auf die durch zwei oder mehr Prozesse zugegriffen werden kann. Gleichartig dazu kann ein Adreßzeiger verwendet werden, wenn die Daten in einem Adreßraum vorliegen, wie es bei dynamisch verbundenen Bibliotheken der Fall ist.
Auf den Empfang des Dokumentidentifizierers hin erzeugt der Bildserver 10 eine Kennung, die das Dokument unabhängig von dem Identifizierer identifiziert, der durch die Anwendung 100 geliefert wird, Schritt 64. Obwohl der Begriff "Kennung" typischerweise bestimmte Datenstrukturen impliziert, sollen die Verweise auf "Kennung" bei dieser Anwendung nicht auf solche Datenstrukturen begrenzt sein. Statt dessen wird jede Implementierung einer "Kennung", die mit der in dieser Anmeldung gegebenen Beschreibung übereinstimmt, bedacht. Danach sperrt der Bildserver das Dokument, um Zugriff auf dasselbe durch andere Anwendungen zu verhindern, Schritt 66. Der Dokumentkennung- und Dokumentsperrmechanismus stellen die Integrität und Dauerhaftigkeit des Dokuments sicher, während es durch den Bildserver verarbeitet wird. Falls beispielsweise eine zweite Anwendung versucht, das Dokument zu modifizieren, muß dieselbe zunächst eine Freigabeanforderung an den Bildserver senden. Der Bildserver kann durch Herstellen einer lokalen Kopie des Dokuments und Freigeben des Originals antworten. Der Bildserver verweist nachfolgend auf die lokale Kopie und gibt das Originaldokument auf, so daß die zweite Anwendung auf dasselbe zugreifen kann.
Nachfolgend empfängt die Anwendung 100 die Kennung, die durch den Bildserver erzeugt wird, und sendet dieselbe und die spezifizierten Druckparameter an den Druckertreiber 300, Schritte 68 und 90. Der Druckertreiber 300 sendet dann eine oder mehrere Bildverarbeitungsanforderungen an den Bildserver 10, um das Bild zu verarbeiten, das durch die Kennung gemäß den Druckparametern identifiziert wurde, Schritt 70. Danach gewinnt der Druckertreiber die verarbeiteten Bilddaten wieder von dem Bildserver, Schritt 72, und sendet die wiedergewonnenen Bilddaten an den entsprechenden Drucker 22, 24, Schritt 92. Schließlich wird das Dokument freigegeben, Schritt 74.
Falls der Bildserver eine lokale Kopie des Dokumentes wie oben beschrieben erzeugt, werden Bildverarbeitungsanforderungen an die lokale Kopie gerichtet. Die Tatsache des Kopierens ist für den Druckertreiber vollständig transparent, da er die Dokumentenkennung verwendet, um auf das Dokument zu verweisen. Bei der Beendigung des Druckauftrags löscht der Bildserver die lokale Kopie.
Im allgemeinen liefert der Bildserver 10 den Großteil der Bildverarbeitungsoperationen bei der vorliegenden Erfindung. Es kann jedoch wünschenswert sein, die Verarbeitungsfähigkeit des Bildservers auf diejenigen allgemeinen Operationen zu begrenzen, die unabhängig sind von jeder Art oder Typ von Drucker. Alle druckerspezifischen Bildanforderungen können durch den Druckertreiber auf das Wiedergewinnen der Bilddaten in Schritt 72 hin durchgeführt werden, um ein endgültiges Druckerbild zu bilden, das dann zu dem Drucker gesendet wird.
Fig. 2 umfaßt zusätzliche Schritte 80 bis 84, die das Thema der Rückwärtskompatibilität ansprechen. Vor dem Registrieren des Dokumentes mit dem Bildserver 10 fragt die Anwendung 100 zunächst den Druckertreiber ab, um zu bestimmen, ob derselbe eine Schnittstelle zu dem Bildserver aufweist, Schritt 80. Falls die Antwort negativ ist, schreitet die Anwendung nach den Grundsätzen der herkömmlichen Druckverfahren fort. Typischerweise bedeutet dies, daß die Anwendung ein geräteunabhängiges Bittabellenbild (DIB-Bild) des zu druckenden Dokumentes erzeugt, und das DIB-Bild für nachfolgendes Drucken an den Druckertreiber sendet, Schritte 82 und 84. Falls der Druckertreiber jedoch eine Bildserverschnittstelle unterstützt, schreitet die Anwendung entlang den Schritten 62 bis 92 fort, wie es oben beschrieben ist.
Bei einem anderen Ausführungsbeispiel, das ebenfalls in Fig. 2 dargestellt ist, umfaßt das Verfahren der vorliegenden Erfindung nur diejenigen Schritte, die durch die Bezugszeichen 60 bis 72 bezeichnet sind. Diese Sequenz entspricht den in Fig. 1 gezeigten Anwendungen 200. Dieses alternative Ausführungsbeispiel ist eine Verallgemeinerung der vorliegenden Erfindung, von der der oben beschriebene Druckprozeß ein spezieller Fall ist. Bei dem allgemeinen Verfahren kommuniziert die Anwendung 200 selbst mit dem Bildserver, um gewünschte Bildverarbeitungsoperationen auf dem Dokument auszuführen, Schritt 70. Zusätzlich werden die resultierenden verarbeiteten Bilddaten nicht notwendigerweise gedruckt, sondern können statt dessen einfach auf dem Datenspeicher 30 gespeichert werden, oder an einem Videoterminal angezeigt werden.
Die Erörterung richtet sich nun auf die Komponenten der vorliegenden Erfindung. Zahlreiche Softwaremodule umfassen die meisten der Hauptkomponenten des Systems. Als solches können viele bestehende Programmiersprachen verwendet werden, um die Erfindung zu praktizieren, insbesondere die C- und C++-Sprache. Die Funktionen der Softwaremodule sind bezüglich der Anwendungsprogrammierschnittstelle (API = applications programmer interface) für jedes Modul definiert, wobei die spezifischen Implementierungseinzelheiten lediglich eine Frage des Erzeugens des Codes sind, um die Operationen durchzuführen, die erforderlich sind, um die API zu implementieren. In einigen Fällen kann es jedoch notwendig sein, den Betrieb bezüglich eines tatsächlichen Betriebssystems zu erklären. Um in diesen Fällen den benötigten Zusammenhang zu liefern, wird die Umgebung des Windows 95- Betriebssystems verwendet.
Mit Bezugnahme auf Fig. 3 umfaßt die Anwendung 100 typischerweise die folgenden Komponenten: anwendungsspezifischen Code 101, DrLlckerdienstprogramme 302 zum Kommunizieren mit dem Druckertreiber 300, I/O (Ein/Aus) - Dienstprogramme 32 zum Lesen und Schreiben eines Speichers 30, und Bildserverdienstprogramme 12 zum Kommunizieren mit dem Bildserver 10. Der anwendungsspezifische Code 101 variiert selbstverständlich abhängig von der Anwendung. Wie oben erwähnt wurde, werden verschiedene Typen von Anwendungen in Betracht gezogen, einschließlich Textverarbeitung, Zeichenprogramme, Tabellen, Desktop-Publishing-Programme usw.
Die Druckertreiber 300 umfassen treiberspezifischen Code 301 zum Kommunizieren mit Druckgeräten, und umfassen ferner die Bildserverdienstprogramme zum Kommunizieren mit dem Bildserver. Zusätzlich zum Liefern einer Kommunikationsschnittstelle mit dem Druckgerät kann der druckerspezifische Code 301 bestimmte Bildverarbeitungsoperationen durchführen, die für den Drucker spezifisch sind. Auf diese Weise muß der Bildserver 10 nur diejenigen Bildverarbeitungsoperationen liefern, die geräteunabhängig sind.
Der Bildserver 10 umfaßt die I/O-Dienstprogramme 32 und Bildserver-spezifischen Code 11, der Bildverarbeitungsoperationen implementiert, wie z. B. Auflösungsskalieren, Bildvergrößerung/Verkleinerung, Abschneiden, Korrektur roter Augen, Drehungen, Merkmalextraktion, Kantenverbesserung, usw. Solche Operationen sind einem Durchschnittsfachmann auf dem Gebiet der Computerbildbearbeitung und Computergraphik bekannt und verständlich. Der Bildserver kann entworfen sein, um einen oder mehrere der vielen Typen von Bildformaten zu unterstützen, die in der Technik existieren, einschließlich JPEG, MPEG, GIF, TIFF, usw., aber nicht darauf beschränkt. Es wird angemerkt, daß die spezifischen Formate, die durch den Bildserver unterstützt werden, für die Praxis der vorliegenden Erfindung nicht wesentlich sind. Statt dessen hängt die Wahl der Formate/des Formates vom Abwägen bestimmter Faktoren ab, wie z. B. gewünschte Fähigkeit des Bildservers, Komplexität des Codes, Komplexität des Bildformates, Verarbeitungskapazität, Speicheranforderungen, äußere Betriebsbedingungen, Systemkosten, usw. Die Ein/Aus-Dienstprogramme 32 führen Standardoperationen durch, einschließlich: Öffnen einer Datei, Schließen einer Datei, Lesen von einer Datei und Schreiben auf eine Datei. Solche Operationen sind dem Fachmann auf dem Gebiet der Softwaretechnik vollständig bekannt und erfordern daher keine weitere Ausführung.
Die Drucker-Dienstp rogramme 302 ermöglichen es der Anwendung 100, mit dem Druckertreiber 300 zu kommunizieren, um einen Druckauftrag auszulösen. In den Druckerdienstprogrammen ist eine Funktion enthalten, die es der Anwendung 100 ermöglicht, zu bestimmen, ob der Druckertreiber 300 eine Bildserverschnittstelle unterstützt, siehe Schritt 80 in Fig. 2. Unter Windows 95 kann dies beispielsweise erreicht werden durch einen Systemaufruf an ExtEscape() für den IS_SUPPORT-Code (Bildserverunterstützung). Ein Druckertreiber 300, der den Bilöserver 10 unterstützt, erkennt den IS_SUPPORT-Code und antwortet zustimmend. Folglich ist der Rückgabewert von dem Aufruf an ExtExcape(QUERYESCSUPPORT, IS_SUPPORT) positiv. Andernfalls wird der Rückgabewert 0 (Null) sein, wodurch angezeigt wird, daß der Bildserver nicht unterstützt wird.
Falls der Bildserver nicht unterstützt wird, setzt die Anwendung das Verarbeiten auf die Weise fort, die derzeit beim Stand der Technik durchgeführt wird. Die Anwendung wird ein DIB-Bild erzeugen, und das Bild an den Druckertreiber 300 senden, was unter Windows 95 durchgeführt wird durch einen Systemaufruf an StretchDIBits() und Weiterleiten eines Zeigers zu dem DIB-Bild. Falls der Druckertreiber andererseits den Bildserver unterstützt, erhält die Anwendung eine Kennung zu dem Bild (siehe nachfolgend, siehe auch Schritt 68 Von Fig. 2) und führt den Systemaufruf an StretchDIBits() durch, und leitet statt dem DIB-Bild die Kennung weiter.
Die Bildserverdienstprogramme 12 definieren die Schnittstelle zu dem Bildserver. Somit werden Bildverarbeitungsoperationen durch die geeigneten Aufrufe zu den Dienstprogrammen durchgeführt. Die Anwendungsprogrammschnittstellen (API) für die Bildserverdienstprogramme werden nachfolgend erörtert. Diese API definieren die Funktionalität des Bildservers und beseitigen somit den Bedarf, Beispiele des Quellencodes zu liefern, der den Bildservet implementiert, was von dem Betriebssystem und der verwendeten Programmiersprache abhängt. Es ist offensichtlich, daß ein Durchschnittsfachmann auf dem Gebiet der Programmierung den Code erzeugen kann, der die Funktionen implementiert, die durch die API definiert sind.
Wie oben erwähnt wurde, ist der Bildserver 10 in der Lage, eine Vielzahl von Bildformaten zu unterstützen. Da auf den Bildserver durch die Bildserverdienstprogramme 12 zugegriffen wird, kann der Bildserver leicht ausgeweitet werden, um zusätzliche Bildformate zu unterstützen, wenn neue Formate definiert werden. Das Vorliegen der Bildserverdienstprogramme 12 macht diese Erweiterung vollständig transparent für Anwendungen/Treiber, die den Bildserver verwenden, und somit wird eine Rückwärtskompatibilität beibehalten, wenn der Bildserver aufgerüstet wird, um neue Bildformate zu unterstützen.
Fig. 3 zeigt die API-Definitionen für die Bildserverdienstprogramme 12. Die Figur zeigt, daß die Dienstprogramme zwischen der Anwendung 100 und dem Druckertreiber 300 aufgeteilt sind. Dies ist jedoch nicht notwendigerweise der Fall. Abhängig von der speziellen Verwendung können sich alle der aufgelisteten Dienstprogramme in einer Anwendung befinden oder können unter einer Anzahl von Anwendungen aufgeteilt sein. In alphabetischer Reihenfolge sind die API:

CloseImage (Bild schließen)

Funktion:

Informiert den Bildserver, daß das Verarbeiten der Bilddatei abgeschlossen ist. Der Bildserver gibt die Bilddatei frei, um einen Zugriff auf die Datei durch andere zu erlauben.

Parameter:

ihImageHandle (Bildkennung) - Identifiziert die Bilddatei.

Rückgabewerte:

TRUE (Wahr) - Funktion war erfolgreich.
ISE_NOTREGISTERED (ISE_NICHT REGISTRIERT) - ihImageHandle stimmt nicht mit einer derzeit registrierten Bilddatei überein.

ConfigureImage (Bild konfigurieren)

Funktion:

Informiert den Bildserver über die Bildverarbeitungsoperationen (Formatieroptionen) die auf dem Bild durchgeführt werden sollen.

Parameter:

ihImageHandle - Identifiziert die zu verarbeitende Bilddatei.
ipImageProcOptions - Eine Datenstruktur, die die angeforderten Bildverarbeitungsoptionen enthält.

Rückgabewerte:

TRUE - Funktion war erfolgreich.
ISE_FORMAT NOTSUPPORTED - Spezifiziertes Format wird durch den Bildserver nicht unterstützt.
ISE_NOTREGISTERED - ihImageHandle stimmt nicht mit einer derzeit registrierten Bilddatei überein.

OpenImage (Bild öffnen)

Funktion:

Informiert den Bildserver, daß Bildverarbeitungsoperationen auf dem spezifischen Bild durchgeführt werden sollen (über Aufrufe an Configurelmage{)}

Parameter:

ihImageHandle - Identifiziert die Bilddatei.

Rückgabewerte:

TRUE - Funktion war erfolgreich. Bildserver ist bereit, Bildverarbeitungsanforderungen für ihImageHandle zu akzeptieren.
ISE_NOTREGISTERED - ihImageHandle stimmt nicht mit einer derzeit registrierten Bitdatei überein.

QueryFormatSupport (Abfrageformatunterstützung)

Funktion:

Fragt den Bildserver ab, ob der Bildserver das spezifizierte Bildformat unterstützt. Informationen können geliefert werden, die zusätzliche Verarbeitungsfähigkeiten anzeigen, die für das spezifizierte Bildformat durch den Bildserver unterstützt werden.

Parameter:

dwImageFormat - Das spezifizierte Bildformat von Interesse. Beispielsweise TIFF, JPEG, MPEG, GIF.
IpFormatData - Zeiger auf eine Datenstruktur, der zusätzliche Verarbeitungsfähigkeiten anzeigt, z. B. Zusammensetzen, die durch den Bildserver geliefert werden.

Rückgabewerte:

ISE_FORMAT_SUPPORTED - Das spezifizierte Format wird durch den Bildserver unterstützt. Falls IpFormatData nicht der NULL-Zeiger ist, können zusätzliche Formatiermerkmale darin durch den. Bildserver spezifiziert werden.
ISE_FORMAT_NOTSUPPORTED - Spezifiziertes Format wird durch den Bildserver nicht unterstützt.

QueryImage (Bild abfragen)

Funktion:

Liefert Informationen über die spezifizierte Bilddatei.

Parameter:

ihImageHandle - Identifiziert die Bilddatei, für die Informationen gewünscht werden.
IpImageInfo - Zeiger auf Bildinformationsdatenstruktur.
Wird durch den Bildserver ausgefüllt.

Rückgabewerte:

TRUE - Funktion war erfolgreich.
ISE_NOTREGISTERED - ihImageHandle stimmt nicht mit einer derzeit registrierten Bilddatei überein.

RegisterImage (Bild registrieren)

Funktion:

Sperrt und/oder kopiert die spezifizierte Bilddatei und sendet eine private Kennung an die gesperrte/kopierte Bilddatei zurück. Die Kennung wird für nachfolgenden Zugriff auf die Datei verwendet.

Parameter:

IpszImageFileName - Zeigt zu einem vollständig qualifizierten Weg/Dateinamen der Bilddatei. Alternativ kann die Bilddatei durch einen Zeiger auf einen Puffer weitergeleitet werden, in diesem Fall ist IpszImageFileName der NULL-Zeiger.
IpJobData - Zeigt zu einer Struktur, die zugehörige Auftragsdaten enthält, wie z. B. den Namen des Druckgeräts.
dwImageFormat - Spezifiziert das Bildformat der spezifizierten Bilddatei.
IpImageHandle - Zeigt zu einem Puffer, in den die Bildkennung (erzeugt durch den Bildserver) kopiert wird.
IpImageData - Zeigt zu einem Puffer, der die Bilddatei enthält. Alternativ kann durch einen vollständig qualifizierten Weg/Dateinamen auf die Bilddatei vetwiesen werden, in diesem Fall ist IpImageData der NULL--Zeiger.
IpImageDataHeader - Zeigt zu einer Datenstruktur, die das Format der Daten definiert, auf die durch. IpImageData gezeigt wurde. Dies ist der Null-Zeiger, falls IpImageData ebenfalls der NULL-Zeiger ist.
dwOptions - Spezifiziert, wie die Bilddatei bei dem Bildserver registriert ist. Gültige Werte umfassen:
IS_TEMPFILE (IST TEMPORÄRE DATEI) - Die Datei, auf die durch IpszImageFileName gezeigt wird ist eine temporäre Datei, die durch den Bildserver gelöscht werden soll, wenn ein Aufruf an CloseImage durchgeführt wird.
IS_COPYNOW (IST JETZT KOPIEREN) - Die Datei, auf die durch IpszImageFileName gezeigt wird, ist eine nicht-temporäre Datei, aber der Bildserver sollte eine Kopie der Bilddatei erstellen statt die Datei zu sperren.

Rückgabewerte:

TRUE - Funktion war erfolgreich. IplrnageHandle zeigt zu einer gültigen Kennung (erzeugt durch den Bildserver) für das Bild.
ISE_OUTOFSPACE - Konnte keine angeforderte Kopie der Bilddatei erstellen. ZpImageHandle- Inhalte sind nicht definiert.
ISE_FORIMINOTSUPP - Das Format, das in dwImageFormat spezifiziert ist, wird durch diese Version des Bildservers nicht unterstützt. IpImageHandle-Inhalte sind nicht definiert.

RetrieveImageBand (Bildband wiedergewinnen)

Funktion:

Fordert die Bilddaten des verarbeiteten Bildes an, das durch den Bildserver als Folge von vorhergehenden Aufrufen an ConfigureImage() erzeugt wurde.

Parameter:

ihImageHandle - Identifiziert die Bilddatei.
XSrc - X-Koordinate des gewünschten Abschnitts der Bilddaten, die durch den Bildserver erzeugt werden, in Pixeln.
Ysrc - Y-Koordinate des gewünschten Abschnitts der Bilddaten, die durch den Bildserver erzeugt werden, in Pixeln.
cxSrc - Breite des gewünschten Abschnitts der Bilddaten, die durch den Bildserver erzeugt werden, in Pixeln.
cySrc - Höhe des gewünschten Abschnitts der Bilddaten, die durch den Bildserver erzeugt werden, in Pixeln.
IpBandBuffer - Zeiger auf einen Puffer, in dem der Bildserver den angeforderten Abschnitt der erzeugten Bilddaten plazieren soll.
IpBandHeader - Zeiger auf eine Datenstruktur, die das Format der Bilddaten spezifiziert, die in IpEandBuffer gespeichert werden sollen.

Rückgabewerte::

TRUE - Funktion war erfolgreich.
ISE_PROCERROR - Verarbeitungsfehler durch den Bildserver angetroffen.
ISE_NOTCONFIGURED - Keine Verarbeitungsoperationen wurden durchgeführt. Keine Aufrufe wurden zu der Funktion ConfigureImage() durchgeführt.
ISE_NOTREGISTERED - ihImageHandle stimmt nicht mit einer derzeit registrierten Bilddatei überein.

UnlockImage (Bild freigeben)

Funktion:

Entfernt die Dateisperre von IpszImageFileName, falls die Datei derzeit durch den Bildserver gesperrt ist. Dabei erstellt der Bildserver eine temporäre Kopie der Bilddatei.

Parameter:

IpszImageFileName - Dateiname der freizugebenden Bilddatei.

Rückgabewerte::

TRUE - Funktion war erfolgreich. IpszImageFileNamc ist freigegeben.
ISE_OUTOFSPACE - Konnte keine Kopie der Bilddatei erstellen, um IpszImageFileName freizugeben. Die Bilddatei bleibt durch den Bildserver gesperrt.
ISE_NOTUNLOCK: - Konnte IpszImageFileName nicht freigeben. Dies zeigt typischerweise an, daß die Datei nicht durch den Bildserver gesperrt war.
Das folgende Fragment von Pseudocode stellt dar, wie die obigen Aufrufe in einer typischen Dokumentbearbeitungsanwendung erscheinen können:
Die folgenden Pseudocodefragmente stellen dar, wie die Bildserverdienstprogramme in der Druckertreibersoftware erscheinen können:
Die Erörterung richtet sich nun auf ein Ausführungsbeispiel der vorliegenden Erfindung, das in Fig. 4 gezeigt ist. Während die Komponenten der Erfindung in Fig. 1 sich auf einem Computer befinden, sind die gleichen Komponenten, die in Fig. 4 gezeigt sind, über zwei oder mehrere vernetzte Computer verteilt. Die Computer 42 bis 48 sind durch ein Netzwerk 50 verbunden. Das Netzwerk 50 kann ein Ethernet- Backbone bzw. Hauptnetz in einem LAN (lokalen Netz) sein, oder kann das Telephonnetzwerk in einem WAN (weiten Netz) umfassen. Allgemeiner gesagt können die Computer 42 bis 48 durch eine Kombination von LAN und WAN verbunden sein. Die vorliegende Erfindung kann mit jeder Netzwerkkonfiguration praktiziert werden und ist nicht auf eine Architektur begrenzt.
Jeder Computer kommuniziert durch seine Netzwerkschnittstelle 52 über das Netzwerk. Die Schnittstelle 52 umfaßt die Hardware und Serversoftware, die benötigt wird, um es dem speziellen Computer zu ermöglichen, über das Netzwerk auf einen anderen Computer zuzugreifen. Es wird daran erinnert, daß die Anwendungen 100, der Bildserver 10 und die Druckertreiber 300 getrennte Prozesse sind, und daß die Kommunikation unter diesen Prozessen durch geeignete IPC- Aufrufe erreicht wird. Bei einer Netzwerkkonfiguration müssen die IPC-Aufrufe durch äquivalente Fernprozeduraufrufe (RPC = remote procedure calls) ersetzt werden, so daß diese Prozesse über das Netzwerk arbeiten können. Obwohl die Implementierung von RPC im allgemeinen von den Fähigkeiten des speziellen Betriebssystems abhängt, ist sie trotzdem innerhalb des Horizontes eines Durchschnittsfachmanns der Programmiertechnik.
Fig. 4 zeigt einen Computer, der als ein Plattenserver 44 dient. Auf dem Plattenserver befindet sich ein Bildserver 10 der vorliegenden Erfindung. Die Druckertreiber 300' sind ebenfalls auf dem Plattenserver 44 geladen, um die Drucker 22, 24 zu treiben. Ein anderer Computer 48 dient hauptsächlich als ein Druckerserver für den Drucker 26, 28. Die Benutzeranwendungen 100, die sich auf dem Computer 42 befinden, können über Serversoftware, die auf dem Plattenserver 44 läuft, auf die Dateien auf der Platte 30 zugreifen. Benutzeranwendungen 200, die auf dem Computer 46 laufen, arbeiten auf ähnliche Weise.
Obwohl die Komponenten der vorliegenden Erfindung verteilt sind bleibt der Betrieb der Erfindung gleich. Somit kann beispielsweise ein RegisterImage()-Aufruf von der Anwendung 100 auf dem Computer 42 ausgelöst werden, über das Netzwerk an den Computer 44 gesendet werden und durch den Bildserver 10 verarbeitet werden. Der Bildserver 10 erzeugt eine Kennung und sendet die Kennung an die Anwendung 100 zurück. Die Anwendung kommuniziert dann über das Netzwerk, um einen Druckauftrag mit dem Druckertreiber 300' auf dem Computer 44 auszulösen. Von dort interagieren der Druckertreiber 300' und Bildserver 10, die in dem gleichen Computer 44 arbeiten, auf die Weise, die oben beschrieben wurde, um das endgültige Druckerbild zu erzeugen. Alternativ kann die Anwendung 100 einen Druckauftrag mit dem Druckertreiber 300" auf dem Computer 48 auslösen. Wie der Druckertreiber 300' auf dem Computer 44 verhandelt der Druckertreiber 300" auf dem Computer 48 Bildverarbeitungsanforderungen mit dem Bildserver 10. Anders als der Druckertreiber 300' auf dem Computer 44 muß der Druckertreiber 300" jedoch die Bildserveraufrufe über das Netzwerk verhandeln.

Claims

1. Ein Verfahren zum Verarbeiten von Bildern, das folgende Schritte umfaßt:

(a) Erhalten (60) eines digitalisierten Bildes;

(b) Spezifizieren von Transformationsparametern, die eine gewünschte Erscheinung des digitalisierten Bildes anzeigen;

(c) Registrieren (62) des digitalisierten Bildes bei einem Bildserver (10);

(d) ansprechend auf den Schritt des Registrierens Empfangen (68) einer Bildidentifiziererkennung von dem Bildserver;

(e) Senden (70) von Bildverarbeitungsanforderungen an den Bildserver, um Bilddaten des digitalisierten Bildes gemäß den Transformationsparametern zu erzeugen, einschließlich des Sendens des Bildidentifizierers an den Bildserver, um das digitalisierte Bild zu identifizieren, wodurch die gewünschte Erscheinung des digitalisierten Bildes erzeugt wird; und

(f) Wiedergewinnen (72) der Bilddaten von dem Bildserver.

2. Das Verfahren gemäß Anspruch 1, das ferner das Laden einer Benutzeranwendung und des Bildservers (10) als gleichzeitig und unabhängig ausführende Programme (100) auf einem Computer (40) umfaßt, wobei die Benutzeranwendung die Teilschritte (a) bis (f) durchführt.

3. Das Verfahren gemäß Anspruch 1 oder 2, das ferner das Laden einer ersten und einer zweiten Benutzeranwendung (100) auf einem Computer (40) umfaßt, wobei die erste Benutzeranwendung die Teilschritte (a) bis (e) für ein erstes digitalisiertes Bild durchführt, und die zweite Benutzeranwendung die Teilschritte (a) bis (e) für ein zweites digitalisiertes Bild durchführt.

4. Das Verfahren gemäß Anspruch 1, 2 oder 3, das ferner das Laden einer Benutzeranwendung (100) auf einem ersten Computer (40) und das Laden des Bildservers (10) auf einem zweiten Computer umfaßt, wobei die Benutzeranwendung die Teilschritte (a) bis (f) durchführt.

5. Das Verfahren gemäß Anspruch 1, 2, 3 oder 1, das ferner folgende Schritte umfaßt:

Laden einer Benutzeranwendung (100), des Bildservers (10) und eines Druckertreibers (22), jeweils als eine gleichzeitig und unabhängig ausführende Programmeinheit, wobei der Druckertreiber konfiguriert ist, um mit einem ersten Typ von Drucker zu kommunizieren;

wobei die Benutzeranwendung die Teilschritte (a) bis (d) durchführt;

Übertragen (90) der Bildkennung und der Transformationsparameter von der Benutzeranwendung zu dem Druckertreiber nach dem Durchführen des Teilschritts (d);

wobei der Druckertreiber die Teilschritte (e) und (f) durchführt; und

Übertragen (92) der Bilddaten von dem Druckertreiber zu dem ersten Typ von Drucker.

6. Das Verfahren gemäß Anspruch 5, das ferner einen Schritt des Ladens eines Treibers eines zweiten Druckers (24) auf dem Computer als ein gleichzeitig und unabhängig ausführendes Programm umfaßt, wobei der zweite Druckertreiber konfiguriert ist, um mit einem zweiten Typ von Drucker zu kommunizieren.

7. Das Verfahren gemäß Anspruch 5, das ferner das Laden einer Benutzeranwendung (100) auf einem ersten Computer (42) und das Laden des Bildservers und des Druckertreibers auf einem zweiten Computer (44) umfaßt.

8. Ein System zum Verarbeiten von Bildern, das folgende Merkmale umfaßt:

(a) Einrichtung zum Erhalten eines digitalisierten Bildes;

(b) Einrichtung zum Spezifizieren von Transformationsparametern, die eine gewünschte Erscheinung des digitalisierten Bildes anzeigen;

(c) einen Bildserver (10), der angeordnet ist, um ansprechend auf die Registrierung eines digitalisierten Bildes eine Bildidentifiziererkennung zu erzeugen;

(d) eine Einrichtung zum Registrieren des digitalisierten Bildes bei dem Bildserver (10);

(d) eine Einrichtung zum Empfangen der Bildidentifiziererkennung, die ansprechend auf die Registrierung erzeugt wird;

(e) eine Einrichtung zum Senden einer Bildverarbeitungsanforderung an den Bildserver (10), um Bilddaten eines digitalisierten Bildes gemäß den Transformationsparametern zu erzeugen, wobei dieselbe eine Einrichtung zum Senden des Bildidentifizierers an den Bildserver (10) zum Identifizieren des digitalisierten Bildes umfaßt, um dadurch die gewünschte Erscheinung des digitalisierten Bildes zu erzeugen; und

(f) eine Einrichtung zum Wiedergewinnen der Bilddaten von dem Bildserver (10).

9. Ein System gemäß Anspruch 8, das ferner zum Drucken von verarbeiteten Bildern angeordnet ist, und ferner folgende Merkmale umfaßt:

einen ersten Speicher (30), der eine Mehrzahl solcher digitalisierter Bilder umfaßt, die jeweils einen jeweiligen Positionsanzeiger umfassen, der die Position des digitalisierten Bildes in dem ersten Speicher 30 spezifiziert;

einen Druckertreiber (300);

wobei der Bildserver (10) eine unabhängig ausführende Programmeinheit ist;

wobei der Bildserver (10) eine Schaltungsanordnung (11) umfaßt, um auf eine Registrierung des digitalisierten Bildes hin mit dem Empfang eines Bildpositionsanzeigers eine Bildidentifiziererkennung zu erzeugen, wobei die Bildidentifiziererkennung das Bild 1- dentifiziert, das durch den Bildpositionsanzeiger spezifiziert wird;

Code (301) zum Auslösen eines Druckauftrags, der einen Code zum Übertragen von einem der Bildpositionsanzeiger zu dem Bildserver (10), einen Code zum Erhalten einer entsprechenden Bildidentifiziererkennung von dem Bildserver (10) und einen Code zum Übertragen von Auftragsparametern zu dem Druckertreiber (300) umfaßt, wobei die Auftragsparameter die Transformationsparameter und die entsprechende Bildidentifiziererkennung umfassen;

wobei der Druckertreiber (300) folgende Merkmale umfaßt:

(a) Code zum Manipulieren von Daten des Bildes, das durch die entsprechende Bildidentifiziererkennung identifiziert wird, der einen Code zum Senden von Bildverarbeitungsanforderungen an den Bildserver (10) gemäß den Transformationsparametern umfaßt;

(b) Code zum Erhalten der resultierenden manipulierten Bilddaten von dem Bildserver (10); und

(c) Code zum Übertragen der manipulierten Bilddaten zu einem Drucker (z. B. 22).

10. Ein System gemäß Anspruch 9, bei dem sich das Bildverarbeitungssystem und der Druckertreiber (300) in einem einzigen Computer (40) befinden.