DE19839065C2 - Verfahren zum Konfigurieren eines Druckertreibers in einem Quellcomputer - Google Patents

Description

Diese Erfindung bezieht sich auf ein Verfahren zum Konfigurieren eines Druckertreiber in einem Quellcomputer.

Ein Gerätetreiber ist ein Softwaremodul, dessen Funktion darin besteht, Details des Gerätebetriebs von sowohl An­ wendungsprogrammen als auch dem Betriebssystem in einem Hostcomputer bzw. Quellcomputer zu trennen. Wenn ein Drucker versendet wird, werden allgemein eine Platte oder Platten einem Drucker bei­ gefügt, und dieselben umfassen einen Druckertreibercode, der auf dem Hostcomputer installiert werden soll. Derartige Treiber sind für das Umwandeln von Anfragen von einem Anwen­ dungsprogramm in einen Befehlsstrom, der durch den Drucker verstanden und ausgeführt werden kann, verantwortlich.

Druckertreiber handhaben Text, Vektoren und Rasterbilder auf unterschiedliche Arten. Rasterbilder sind Pixelbittabellen (Pixelbitmaps), die durch Beschreiben der Farbe jedes Pixels in dem Bild definiert sind. Aufgrund der Datenmenge, die notwendig ist, ihn eine Rasterbittabelle zu beschreiben, ist eine beträchtliche Verarbeitungszeit erforderlich, um derar­ tige Daten für eine Übertragung zu einem verbundenen Drucker vorzubereiten. Der Verarbeitungsgrad, den ein Druckertreiber an den Rasterbittabellendaten durchführt, die von einem An­ wendungsprogramm kommen, variiert abhängig von den Fähigkei­ ten des Druckers und den Erfordernissen des Benutzers. Bei­ spiele der Operationen, die an einem Rasterbittabellenbild durch einen Druckertreiber durchgeführt werden, umfassen folgende Handlungen:

• - Farb/Raum-Transformationen - bei denen Rot/Grün/­ Blau-Werte in Schwarz-, Cyan-, Magenta- und Gelb­ werte transformiert werden.
• - Bildverarbeiten - bei dem eine Kontrastkorrektur und Farbausgleichshandlungen durchgeführt werden.
• - Bittiefenumwandlung - bei der ein Halbtönen und/ oder andere Zitterhandlungen (Ditherhandlungen) ausgeführt werden, um die Bildgraustufendarstellung zu verbessern.
• - Bilddrehung - bei der ein Bild um einen gegebenen Winkel gedreht wird.
• - Skalieren - bei dem ein Bild durch beispielsweise eine Pixelreplikation, eine Auflösungssynthese oder einen weiteren Skalieralgorithmus bezüglich der Größe vergrößert oder verkleinert wird.
• - Schneiden - bei dem lediglich eine Region eines Bildes zu einem Drucker übertragen werden soll.
• - Komprimierung - bei dem Bilddaten komprimiert wer­ den, um die Menge der erforderlichen Daten zu redu­ zieren, die zu dem Drucker übertragen werden sol­ len.

Abhängig von der Natur eines Druckauftrags kann jede der obigen Verarbeitungshandlungen in dem Druckertreiber, dem Betriebssystem und dem Drucker auftreten oder überhaupt nicht auftreten.

Von der Verarbeitungsgeschwindigkeit aus gesehen, ist die langsamste Funktion, die durch den Hostcomputer ausgeführt wird, die Übertragung der Druckdaten zu dem Drucker. Die Verarbeitungshandlungen, die innerhalb des Hostcomputers oder innerhalb des Druckers auftreten, treten mit einer wesentlich höheren Rate als die verfügbare Datenübertra­ gungsgeschwindigkeit zwischen dem Hostcomputer und dem Drucker auf. Dementsprechend können die resultierenden Leistungsverbesserungen wesentlich sein, wenn die Bild­ datenmenge, die zu dem Drucker übertragen wird, minimiert werden kann.

Historisch wurde die Aufgabe des Verarbeitens von Rasterbit­ tabellendaten in einem Druckertreiber unter Verwendung eines monolithischen, statischen Codestücks durchgeführt. Derarti­ ge Druckertreiber kombinieren oftmals Verarbeitungsschritte für Effizienzzwecke. Beispielsweise werden bei vielen aktu­ ellen Druckertreibern das Skalieren, das Zittern (Dithern) und die Komprimierung gleichzeitig durchgeführt. Folglich kann das Modifizieren einer beliebigen dieser Prozeduren im wesentlichen ein Neuschreiben des gesamten Druckertreiber­ codes betreffen. Da die Merkmale des Treibers und des Druckers zur Entwurfszeit bestimmt werden, ist der Drucker­ treibercode ferner "statisch". Folglich wird der Drucker geschrieben, um zu den Fähigkeiten eines spezifischen Gerä­ tes zu passen. Beispielsweise werden Annahmen, die über die Geschwindigkeitsleistung des Hostcomputers, die Netzband­ breite etc. gemacht werden, festgelegt, und sobald der Druckertreiber freigegeben wurde, können diese Annahmen nicht verändert werden. Wenn die neuen Bildverarbeitungs­ prozeduren verfügbar sind, oder Hardwareverbesserungen vor­ genommen werden, die potentiell die Effizienz des Bittabel­ lenverarbeitens verbessern, muß als ein Resultat der gesamte rasterverarbeitende Teil eines Druckertreibers überprüft werden und potentiell neu geschrieben werden, um diese Ver­ besserungen aufzunehmen. Eine derartige Neuschreibhandlung ist sowohl teuer als auch zeitaufwendig.

Die DE 196 15 177 A1 beschreibt ein Verfahren und ein System zur Anpassung eines Druckertreibers an eine Anwendung, z. B. auf einem PC, wobei zunächst versucht wird, den Druckertrei­ ber über aus einer Datenbank von Anwendungsparametern be­ kannte Parameter (Flags) für die spezielle Anwendung einzu­ stellen bzw. anzupassen, und wenn dies nicht gelingt, diese Anpassung über ein Dienstprogramm vorzunehmen, das die Ein­ stellung von bestimmten Flags, die bekanntermaßen Probleme verursachen, ermöglicht, wobei diese Einstellungen für die spezielle Anwendung in einer Datenstruktur gespeichert wer­ den.

Die US-A-5,515,481 offenbart ein Verfahren und eine Vorrich­ tung zum Drucken eines Bilds oder Dokuments, das durch einen Graphiksprachenstrom definiert ist. In diesem Strom sind graphische Beschreibungen für Rahmen in einer Seite und Do­ kumentlayoutinformationen enthalten, die beschreiben, wie die Rahmen auf der Seite plaziert werden. Ein besonderes Merkmal des Verfahrens und der Vorrichtung besteht darin, diesen Strom der Graphiksprache in die graphischen Beschrei­ bungen für die Rahmen in einer Seite, und in die Dokument­ layoutinformationen zu trennen, und in unterschiedlichen pi­ pelinemäßigen Schnittstellen auszugeben. Der Graphik­ sprachenstrom bzw. der Teil des Stroms, der die graphischen Beschreibungen für Rahmen enthält, wird zu einem Graphik­ sprachenprozessor gesendet, der denselben in Maskeninforma­ tionen und Hintergrundinformationen, auf die die Maskenin­ formationen angewendet werden, trennt. Der Prozessor bear­ beitet die Maskeninformationen und Hintergrundinformationen unabhängig voneinander, um Rahmenraster zu erzeugen und ver­ wendet die Dokumentenlayoutinformationen, um die Rahmen­ raster auf die Seite abzubilden. Das beschriebene Verfahren kann sowohl in einem Druckertreiber als auch einem Drucker, bzw. zu einem Teil in einem Druckertreiber und zum anderen Teil in dem Drucker implementiert sein.

Die US-A-5,029,327 beschreibt ein System, bei dem Daten in Form von Datenzeichenfolgen in einem Eingangspuffer einer Ausgabevorrichtung eingegeben werden, um diese temporär zu speichern. Die Daten können Daten für Zeichen, graphische Daten, Steuercodes, usw. sein. Der Eingangspuffer ist an eine Datenverarbeitungseinheit gekoppelt, die Daten folgend von dem Eingangspuffer holt, dieselben analysiert und sie gemäß der Analyse verarbeitet. Enthalten die Daten als einen Steuercode einen Schreibsteuercode, so werden bezeichnete Datenzeichenfolgen von der Datenverarbeitungseinheit in ei­ nem Datenzeichenfolgenspeicher gespeichert. Enthalten die Daten als Steuercode einen Lesesteuercode, so werden be­ zeichnete Datenzeichenfolgen aus dem Datenzeichenfolge­ speicher von der Datenverarbeitungseinheit gelesen. Häufig oder wiederholt angezeigte, gedruckte, etc. Daten werden in dem Datenzeichenfolgespeicher gespeichert, um ein effektives Arbeiten der Ausgabevorrichtung in Verbindung mit dem Host­ system zu ermöglichen. Die Verarbeitungseinrichtung ist fer­ ner mit einer Ausgabeeinheit verbunden, die eine Ausgabeein­ heit für einen Drucker, eine Anzeige, etc. sein kann. Daten­ zeichenfolgen, die von dem Hostsystem geliefert werden, wer­ den nun abhängig von dem Steuercode direkt zu der Ausgabe­ einheit weitergegeben, um dieselben auszudrucken oder anzu­ zeigen, oder wiederholt anzuzeigende Datenzeichenfolgen wer­ den vorher mit Hilfe des Steuercodes (Schreibsteuercode) in dem Datenzeichenfolgespeicher gespeichert, um sie später nochmals wiederholt abhängig von dem Steuercode (Lesesteuer­ code) ausgeben zu können. Dies reduziert die Datenübertra­ gungsmenge zwischen dem Hostsystem und der Ausgabevorrich­ tung.

Die Aufgabe der vorliegenden Erfindung besteht darin, ein Verfahren zum Konfigurieren eines Druckertreibers zu schaffen, der ohne weiteres modifizierbar, effizient und optimal konfigurierbar ist.

Diese Aufgabe wird durch ein Verfahren zum Konfigurieren eines Druckertreibers gemäß Anspruch 1 gelöst.

Ein Vorteil des erfindungsgemäßen Druckertreibers besteht darin, daß derselbe eine leichte Modifikation seines Raster­ verarbeitungscodes, ohne die Notwendigkeit für ein Neu­ schreiben des gesamten Rastercodes, ermöglicht.

Ein weiterer Vorteil des erfindungsgemäßen Druckertreibers besteht darin, daß derselbe eine verbesserte Druckertreiber­ prozedur aufweist, mit der eine Rasterbittabellenverarbei­ tungspipeline konfiguriert werden kann, um die Verarbei­ tungseffizienz der Rasterbittabelle zu maximieren.

Noch ein weiterer Vorteil des erfindungsgemäßen Druckertrei­ bers besteht darin, daß derselbe die Leistungsfähigkeiten von sowohl einem Hostcomputer als auch einem verbundenen Drucker berücksichtigen kann, wenn eine Entscheidung bezüg­ lich einer optimalen Konfiguration einer Verarbeitungspipe­ line getroffen wird, um Rasterbittabellenbilder handzuhaben.

Ein konfigurierbarer Druckertreiber, der sich in einem Host- (Quell-)Computer befindet, kann auf eine Druckauftragsan­ frage durch Manipulieren einer Quellbittabelle vor der Über­ tragung derselben zu einem Zieldrucker ansprechen. Der Druckertreiber umfaßt mehrere, im wesentlichen unabhängige Bittabellenmanipulationsprozeduren, die verbunden werden können, um eine Bildverarbeitungspipeline zu schaffen. Das Verfahren der Erfindung bestimmt anfangs, welche Bitta­ bellenmanipulationen in dem Quellcomputer durchgeführt wer­ den sollten, um die Bittabellendatenmenge zu minimieren, die zu dem Zieldrucker gesendet werden soll, oder um die Verar­ beitungseffizienz der Druckauftragsanfrage zu maximieren. Basierend auf der vorher erwähnten Bestimmung wird eine Bit­ tabellenprozessorpipeline aus gespeicherten Bittabellenmani­ pulationsprozeduren zusammengefügt, um Manipulationen der Quellbittabelle in dem Quellcomputer durchzuführen. Die Bit­ tabellenmanipulationen werden dann unter Verwendung der zu­ sammengefügten Bittabellenprozessorpipeline durchgeführt. Die resultierende verarbeitete Rasterbittabelle wird dann zu dem Zieldrucker übertragen.

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 eines Quellcomputers, der ange­ paßt ist, um die Erfindung auszuführen;

Fig. 2 die Beziehung von Quell- und Ziel-Rechtecken und Schneiderechtecken;

Fig. 3 eine schematische Ansicht von Softwaresteuerelemen­ ten, die verwendet werden, um eine Bittabellenpro­ zessorpipeline ansprechend auf eine Druckauftrags­ anfrage zu konfigurieren;

Fig. 4 ein Logikflußdiagramm auf einer hohen Ebene, das den Betrieb der Bittabellenprozessorpipelineelemen­ te ansprechend auf eine Druckauftragsanfrage dar­ stellt; und

Fig. 5 ein logisches Flußdiagramm, das den Betrieb einer Lastausgleichsprozedur darstellt, die bestimmt, welche Softwaresteuerelemente in die Bittabellen­ prozessorpipeline aufgenommen werden sollten, um eine Bittabellendatenmenge zu minimieren, die zu einem Zieldrucker gesendet werden soll.

Wie es im folgenden offensichtlich werden wird, umfaßt ein Druckertreiber, der die Erfindung enthält, eine Mehrzahl von objektorientierten, modularen Softwarebittabellenverarbei­ tungsprozeduren, die in eine Bittabellenprozessorpipeline konfiguriert werden können. Die modulare Architektur des Druckertreibers ermöglicht die Hinzufügung von neuen Proze­ duren ohne eine Modifikation von derzeit existierenden Bit­ tabellenprozeduren. Beispielsweise kann eine neue Bildver­ arbeitungsprozedur durch lediglich Erzeugen einer neuen Bit­ tabellenverarbeitungsprozedur und Einfügen derselben in die Prozessorpipeline hinzugefügt werden. Eine derartige Hand­ lung erfordert weder eine Modifikation der Basisarchitektur des Druckertreibers noch ein Neuschreiben der verbleibenden Verarbeitungsprozeduren der Pipeline. Ferner können durch Modifizieren eines Auslaßendes der Bittabellenprozessorpipe­ line die Ausgaberasterdaten derart formatiert werden, daß dieselben mit jeder Druckersprache kompatibel sind.

Der modulare Entwurf der Bittabellenverarbeitungsprozeduren ermöglicht eine dynamische Konfiguration der Bittabellenver­ arbeitungspipeline, um es zu ermöglichen, daß ein bestimmter Satz von Bittabellenbildverarbeitungsfunktionen in dem Host- (Quell-)Computer ausgeführt werden kann, und daß die ver­ bleibenden Bildverarbeitungsfunktionen in dem Drucker ausge­ führt werden können. Derartige Handlungen ermöglichen es, daß das Rasterverarbeiten bezüglich der Druckergeschwindig­ keit, der Bildqualität oder der Rückkehr-zur-Anwendung-Zeit optimiert werden kann.

Die Bittabellenprozessorpipeline kann ferner basierend auf Bedingungen, wie z. B. dem Eingangs/Ausgangs-Verkehr, der Hostprozessorgeschwindigkeit oder dem verfügbaren Host­ speicher, modifiziert werden. Bei Druckern, die ein Ska­ lieren, d. h. das Drucken eines Bilds auf einer Seite, deren Höhe oder Breite in Pixeln sich von dem Original unterschei­ det, unterstützen, kann beispielsweise der Druckertreiber unter Verwendung z. B. des Skalierens entscheiden, daß die Skalierhandlungen in dem Drucker und nicht in dem Hostpro­ zessor durchgeführt werden. Wenn jedoch das Skalieren in dem Hostprozessor die Datenmenge reduzieren wird, die zu dem Drucker gesendet werden soll, kann der Druckertreiber ent­ scheiden, die Skalierhandlung in dem Hostprozessor durchzu­ führen. Eine derartige Entscheidung wird auf Informationen über die Geschwindigkeit des Hostprozessors gegenüber der Geschwindigkeit des Eingabe/Ausgabe-Kanals basieren.

Darüberhinaus kann der Druckertreiber ferner einen Bitta­ bellenverarbeitungsalgorithmus basierend auf einer Auswahl eines Benutzers implementieren. Die Pixelreplikation ist eine Skalierprozedur, die ein Bild durch Weglassen von Pixeln hinunterskaliert und das Bild durch Wiederholen von Pixeln hinaufskaliert. Eine derartige Skalierhandlung wird ausgewählt, wenn dem Benutzer die Geschwindigkeit wichtiger ist als die Bildqualität. Die Auflösungssynthese, die ein fortgeschritteneres Verfahren des Skalierens ist, das Pixel­ werte interpoliert, wird ausgewählt, wenn der Benutzer den Wunsch nach der besten Bildqualität anzeigt.

Die Bittabellenprozessorpipeline der Erfindung ist ohne wei­ teres auf verschiedene Druckertypen anpaßbar. Beispielsweise kann der Treiber den Drucker abfragen, und dann die Prozes­ sorpipeline basierend auf den Farb- oder Halbtön-Fähigkeiten des Druckers konfigurieren.

Nun Fig. 1 zuwendend, umfaßt der Hostcomputer 10 eine zen­ trale Verarbeitungseinheit (CPU; CPU = Central Processing Unit) 12, die über ein Bussystem 14 mit sowohl einem Spei­ cher 16 als auch einem Eingabe/Ausgabe-(E/A-)Modul 18 gekoppelt ist. Das E/A-Modul 18 ermöglicht Kommunikationen zwischen dem Hostcomputer 10 und einem Drucker 20. Der Spei­ cher 16 liefert Speicher für sowohl die Bilddaten als auch die Softwareprozeduren, die durch die CPU 12 verwendet wer­ den, um die Rasterbittabellenbildverarbeitungsprozeduren durchzuführen, die im folgenden beschrieben sind. Dement­ sprechend umfaßt der Speicher 16 ein Anwendungsprogramm 22, von dem angenommen wird, daß dasselbe ein Bittabellenbild 24 erzeugt hat, das zu dem Drucker 20 übertragen werden soll. Um die Übertragung auszuführen, enthält eine Druckertreiber­ prozedur 26 die Funktionen, die das Bittabellenbild 24 ver­ arbeiten, um dasselbe für eine Übertragung durch das E/A- Modul 18 vorzubereiten.

Die Druckertreiberprozedur 26 umfaßt eine Lastausgleichspro­ zedur 28, die eine zu fällende intelligente Entscheidung darüber ermöglicht, welche Verarbeitungsprozeduren in eine Bittabellenprozessorpipeline innerhalb des Hostcomputers 10 aufgenommen werden, um das Bittabellenbild 24 zu verarbei­ ten. Eine Bittabellenprozessorprozedur 30 ist der Steuer­ prozeß, der die Bittabellenprozessorpipeline gemäß den Ent­ scheidungen konfiguriert, die durch die Lastausgleichsproze­ dur 28 erlangt wurden. Die Bittabellenprozessorprozedur 30 kann aus einer Anzahl von Bittabellenverarbeitungsprozeduren auswählen, um eine Prozessorpipelineverbindungsliste 32 ein­ zurichten, die die Bittabellenprozessorpipeline konfigu­ riert.

Jede der zusätzlichen Prozeduren, die in dem Speicher 16 ge­ speichert ist, ist ein Softwaresteuerelement, das eine Mo­ difikation des Bittabellenbilds 24 gemäß Benutzeranweisungen ermöglicht. Diese Prozeduren umfassen
eine Schneidequellrechteckprozedur 34, die dazu dient, um die Datenmenge zu reduzieren, die durch die Pipeline verarbeitet wird, wobei das Schneiderechteck in den Quellraum projiziert wird und verwendet wird, um einen "grobes" Schneiden des Quellbilds durchzuführen. Ein genaues Schneiden ist so lange nicht möglich, bis sich die Bittabelle in dem Zielraum befindet;
eine Bittabellenleseprozedur 36, die folgende Pixel­ zeilen aus dem Rasterpixelbild liest und diese Zeilen zu einer nächsten Prozedur in der Bittabellenprozessor­ pipeline liefert. Diese Prozedur ist aufgrund der Viel­ zahl der Bittabellenformate notwendig;
eine Bittabellenskalierprozedur 38, die die Bittabelle von dem Quellraum in den Zielraum übersetzt. Dieselbe skaliert ein Rasterbittabellenbild entweder hinauf oder hinunter, um zu bewirken, daß dasselbe in ein Rechteck paßt, das durch den Zieldrucker eingerichtet wird. Typischerweise wird die physische Größe des Bilds ei­ gentlich nicht verändert, sondern vielmehr ist das Ver­ hältnis zwischen der Quelle und dem Ziel das Verhältnis zwischen der Bildschirmauflösung in dem Hostcomputer und der Druckerauflösung. Da der Drucker allgemein ein höheres Auflösungsniveau aufweist, sind mehr Pixel er­ forderlich, um das Druckerbild zu füllen;
eine Bittabellenschneideprozedur 40, die in dem Ziel­ raum wirkt und jegliche Pixel entfernt, die außerhalb der Schneideregion liegen;
eine Bittabellenzitterprozedur 42, die die Rasterbit­ tabelle von einem Farbraum in einen weniger leistungs­ fähigen Farbraum umwandelt. Insbesondere verarbeitet die Zitterprozedur (Ditherprozedur) Regionen von Pixeln und wandelt die Pixelwerte darin in Werte um, die ver­ besserte Graustufendarstellungen zeigen; und
eine Bittabellenkomprimierungsprozedur 44, die eine verarbeitete Rasterbittabelle in ein komprimiertes Format zur Übertragung zu dem Drucker (z. B. unter Verwendung des Lauflängencodierens) umwandelt.

Allgemein beginnt die Verarbeitung einer Rasterbittabelle dadurch, daß das Betriebssystem dem Druckertreiber eine Quellbittabelle, ein Quellrechteck, ein Zielrechteck und ein Schneiderechteck (siehe Fig. 2) liefert. Danach werden unter der Steuerung der Bittabellenprozessorprozedur 30 jene Pi­ xel, die in das geschnittene Quellrechteck fallen, für ein anschließendes Verarbeiten aufgeteilt. Das geschnittene Quellrechteck ist das Schneiderechteck, das in den Quellraum unter Verwendung des Verhältnisses zwischen dem Quell- und dem Ziel-Rechteck als Skalierfaktor projiziert wird. Wie in Fig. 2 dargestellt, ist der Quellraum der Koordinatenraum des Hostcomputerbildschirms (der üblicherweise eine Auf­ lösung von 37,80 Punkten/cm (= 96 Punkte/Zoll) aufweist). Der Zielraum ist der Koordinatenraum des Druckers (der eine Auflösung von 236,22 Punkten/cm (= 600 Punkten/Zoll oder höher) aufweist).

Sobald die geschnittene Quellrechteckaufteilung durch die Schneidequellrechteckprozedur 34 berechnet ist, werden die Pixel der Quellbittabelle, die in das geschnittene Quell­ rechteck fallen, durch die Bittabellenleseprozedur 36 Zeile für Zeile gelesen. Diese Pixel werden zu der Bittabellen­ skalierprozedur 38 weitergeleitet, bei der ein geeignetes Skalieren des Bittabellenrasterbilds durchgeführt wird. Als nächstes werden die skalierten Bittabellenrasterdaten zu der Bittabellenschneideprozedur 40 weitergeleitet, bei der die Pixel außerhalb des Schneiderechtecks entfernt werden. Eine derartige Handlung ist aufgrund von Rundungsfehlern notwen­ dig, die auftreten, wenn das Schneiderechteck in den Quell­ raum projiziert wird, um das geschnittene Quellrechteck zu bilden.

Danach werden die verarbeiteten Rasterbilddaten zu einer Zitterprozedur 42 gespeist, die eine erforderliche Zitter­ handlung durchführt. Dann werden die gezitterten Rasterbit­ tabellendaten durch die Komprimierungsprozedur 44 kompri­ miert und zu dem Drucker 20 übertragen.

Es ist offensichtlich, daß, obwohl jede der oben beschriebe­ nen Prozeduren als schon in dem Speicher vorhanden gezeigt ist, derartige Prozeduren auf entfernbaren Medien, wie z. B. der Platte 48 (z. B. eine Magnetplatte oder eine Kompakt­ platte), gespeichert werden können. Unter derartigen Bedin­ gungen werden die Steuerprozeduren von der Platte 48 in die CPU 12 heruntergeladen und werden verwendet, um das Verfah­ ren der Erfindung durchzuführen.

Nun Fig. 3 zuwendend werden weitere Details der Steuerele­ mente, die durch die Erfindung verwendet werden, beschrie­ ben. Ein Softwaresteuerelement, wie es im folgenden ver­ wendet wird, bezieht sich auf ein Softwarecodemodul, das eine Schnittstelle, ein Verhalten und einen Zustand (eben­ falls als Klasse in der objektorientierten Programmtermino­ logie bekannt) umfaßt. Es sei bemerkt, daß Fig. 3 die Booch-Notation verwendet, wie sie in "Object-Oriented Analy­ sis and Design", Booch, G., Benjamin/Cummings Publishing, Redwood City, CA. 1994, beschrieben ist.

Fig. 3 ist eine schematische Darstellung der Beziehungen der Softwaresteuerelemente, die verwendet werden, um eine Bitta­ bellenprozessorpipeline 50 zu konfigurieren. Die Bittabel­ lenprozessorprozedur 30 und die Prozeduren in der Bittabel­ lenprozessorpipeline 50 erben bestimmte Schnittstellen von einer Bittabellenstrategie 62. Eine gemeinsame Schnittstelle spezifiziert die Arten der Anfragen, die an ein Software­ steuerelement, d. h. ein Objekt, gemacht werden können. Ins­ besondere müssen der Bittabellenprozessor 30 und jedes Soft­ waresteuerelement auf die folgenden Anfragen ansprechen kön­ nen: Holen der Bits pro Pixel; Holen des Begrenzungskastens; Holen der Puffergröße; Holen der nächsten Zeile; Holen der Palettentabelle; Holen des vorhergehenden Knotens; und Ini­ tialisieren.

Jede der Anfragen in der Bittabellenstrategie 62 kann durch den Bittabellenprozessor 30 zu der Bittabellenkomprimie­ rungsprozedur 44 gesendet werden, die das letzte Software­ steuerelement in der Prozessorpipeline 50 ist. Jedes Soft­ waresteuerelement kann lediglich eine Anfrage zu dem näch­ sten, stromaufwärts positionierten Softwaresteuerelement senden. Folglich verarbeitet beim Empfang einer Anfrage von dem Bittabellenprozessor 30 die Bittabellenkomprimierungs­ prozedur 44 die Anfrage. Während dieselbe die Anfrage verar­ beitet, kann es notwendig sein, daß dieselbe eine Anfrage an ein nächstes Stromaufwärtssoftwaresteuerelement (d. h. die Bittabellenzitterprozedur 42) macht. Ferner kann es not­ wendig sein, daß die Bittabellenzitterprozedur 42 eine An­ frage in der Stromaufwärtsrichtung durchführen muß, um an­ zusprechen, etc.

Im wesentlichen implementiert dieses Kommunikationsprotokoll eine "Zieh"-Prozedur, bei der ein Stromaufwärtssoftwaresteu­ erelement lediglich in der Stromabwärtsrichtung mit einer Antwort auf eine empfangene Anfrage ansprechen kann. Ein Stromabwärtssoftwaresteuerelement kann jede der Anfragen, die durch die Bittabellenstrategieschnittstelle definiert ist, senden. Wenn sichergestellt wird, daß jedes Software­ steuerelement auf jede der Schnittstellenanfragen ansprechen kann, die durch die Bittabellenstrategie 62 bezeichnet sind, ist es dementsprechend sichtbar, daß ein Standardisierungs­ niveau, wie z. B. zwischen den Softwaresteuerelementen, er­ möglicht wird. Wenn ein neues Softwaresteuerelement in die Prozessorpipeline 50 ausgetauscht wird oder zu derselben hinzugefügt wird, muß dasselbe ferner lediglich auf Zieh­ anfragen von einem Softwaresteuerelement ansprechen, das weiter stromabwärts in der Verarbeitungsrichtung positio­ niert ist, und das jede beliebige der oben erwähnten An­ fragen zu dem nächsten Stromaufwärtselement senden kann, ohne das dasselbe die Identität des Stromaufwärtselements kennen muß.

Jedes der Softwaresteuerelemente, das mit einem "A" markiert ist, ist ein "abstraktes" Steuerelement, das Schnittstellen definiert, die ein "konkretes" Steuerelement implementieren wird. Beispielsweise definiert die Bittabellenkomprimie­ rungsprozedur 44, was allen Komprimierungsprozeduren gemein­ sam ist. Die konkreten Komprimierungsprozeduren, wie z. B. die Keine-Komprimierung-Prozedor 52, die Lauflängencodie­ rungskomprimierungsprozedur 54 oder die JPEG-Komprimierungs­ prozedur 56 können implementiert werden und in die Pipeline 50 eingefügt werden, solange sich dieselben alle an die Klasseneinschränkungen halten. Auf eine ähnliche Art und Weise definiert die Bittabellenzitterprozedur 42, was allen Zitterprozeduren gemeinsam ist. Eine konkrete Zitterprozedur ist eine mono-geordnete Zitterprozedor 58 oder weitere Zitterprozeduren (nicht gezeigt). Die Bittabellenskalierpro­ zedur 38 definiert, was allen Skalierprozeduren gemeinsam ist, wie z. B. Replikationsmaßstäbe 60.

Jede der Anfragen, die durch die Schnittstelle ermöglicht wird, die in dem Bittabellenstrategiesteuerelement 62 ver­ merkt ist, bezeichnet eine Operation, die angefragt werden kann, um durch ein Softwaresteuerelement in der Prozessor­ pipeline 50 durchgeführt zu werden. Beispielsweise wird die Anfrage "HoleNächsteZeile" durch den Bittabellenprozessor 30 zu der Bittabellenkomprimierungsprozedur 44 weitergeleitet. Diese Anfrage wird stromaufwärts durch die Bittabellen­ zitterprozedur 42, die Bittabellenschneideprozedur 40, die Bittabellenskalierprozedur 38 zu der Bittabellenleseprozedur 36 weitergeleitet. Dort spricht die Bittabellenleseprozedur 36 auf die Anfrage durch Zugreifen auf eine nächste Pixel­ datenzeile der Bittabelle 24 und Zurückgeben der Bitta­ bellenpixeldatenzeile zu der Bittabellenskalierprozedur 38, die eine Skalierhandlung an denselben (gemäß einer Ein­ stellung, die während einer Initialisierungsphase der Pro­ zessorpipeline 50, die im folgenden beschrieben ist, spezi­ fiziert wird) durchführt, an.

Die skalierte Pixeldatenzeile wird als nächstes stromabwärts zu der Bittabellenschneideprozedur 40 zurückgegeben, bei der eine Schneidehandlung durchgeführt wird. Dann wird die Pi­ xeldatenzeile zu der Bittabellenzitterprozedur 42 zurück­ gegeben, bei der eine erforderliche Zitterprozedur (wenn überhaupt) durchgeführt wird, und dann wird die Pixeldaten­ zeile zu der Bittabellenkomprimierungsprozedur 44 zurückge­ geben, bei der dieselbe für eine Übertragung zu dem Drucker 20 komprimiert wird. Während des Einrichtens der Prozessor­ pipeline 50 wird eine der Komprimierungsprozeduren 52, 54 oder 56 spezifiziert und über die Bittabellenkomprimierungs­ prozedur 44 ausgeführt.

Wie in Fig. 4 gezeigt, beginnt die Prozedur, um die Pro­ zessorpipeline 50 einzurichten, damit, daß der Druckertrei­ ber 26 (Fig. 1) einen Druckauftrag von der Anwendung 22 (Kasten 70) empfängt. Der Druckertreiber 26 spezifiziert die Art der Ausgabe, die von der Prozessorpipeline 50 gewünscht wird, und definiert beispielsweise den Typ der erforder­ lichen Komprimierung, die Größe der Quell- und Ziel-Kästen, eine Schneideregion für das Quellrechteck (wenn benötigt), den Farbraum, einen Zittermodus und eine Zittermatrix, wenn benötigt (Kasten 72). Der Zittermodus weist den Bittabellen­ prozessor 30 an, welcher Typ des Zitterns durchzuführen ist.

Als nächstes wird eine Lastausgleichsprozedor durchgeführt (Kasten 74), um eine Konfiguration der Verarbeitungspipeline 50 zu ermöglichen, die die Verarbeitungsgeschwindigkeit des Druckauftrags maximiert. Dementsprechend ist die Prozessor­ pipeline 50 angeordnet, um die Datenmenge zu minimieren, die zu dem Drucker gesendet werden soll, oder um einen Vorteil aus den Druckerfähigkeiten durch Zuweisen von bestimmten Bildverarbeitungsfunktionen an den Drucker zu ziehen. Wenn der Drucker ein Hardwarezittermodul umfaßt, und das Raster­ bittabellenbild eine bestimmte Größe überschreitet, kann beispielsweise die Lastausgleichsprozedur entscheiden, daß die Verarbeitungseffizienz dadurch verbessert wird, daß be­ wirkt wird, daß die Zitterprozedur in dem Drucker durchge­ führt wird.

Im wesentlichen bestimmt die Lastausgleichsprozedur 28, ob die Rasterbittabellendatenmenge stark genug durch Skalier-, Schneide- und Zitter-Handlungen in der Prozessorpipeline 50 reduziert werden kann, um die Zeit zu reduzieren, die erfor­ derlich ist, um die Daten zu dem Drucker zu übertragen. Ein Beispiel einer Prozedur zum Minimieren der Datenmenge, die zu dem Drucker gesendet werden soll, ist in Fig. 4 gezeigt und wird im folgenden detaillierter beschrieben.

Um neu zu iterieren, teilt jedes Softwaresteuerelement, das in die Prozessorpipeline 50 konfigurierbar ist, eine gemein­ same Eingabe/Ausgabe-Schnittstellencharakteristik. Wenn ein beliebiges Softwaresteuerelement für ein anderes Software­ steuerelement eingesetzt oder zu der Prozessorpipeline 50 hinzugefügt wird, muß sich dasselbe dementsprechend le­ diglich an die Schnittstellenverfahren von allen anderen Softwaresteuerelementen halten. Da jedes Softwaresteuer­ element auf einer Daten-"Zieh"-Basis wirkt, muß das Soft­ waresteuerelement ferner lediglich konfiguriert sein, um auf die Schnittstellenanfragen anzusprechen, die in der Bitta­ bellenstrategie 62 gezeigt sind. Letztlich kann, obwohl je­ des Softwaresteuerelement in der Prozessorpipeline 50 ledig­ lich auf eine empfangene Anfrage ansprechen kann, dasselbe jede beliebige der Schnittstellenanfragen, die in der Bitta­ bellenstrategie 62 zu finden sind, zu einem Softwaresteuer­ element senden, das sich weiter stromaufwärts in der Pro­ zessorpipeline 50 befindet.

Zurückkehrend zu Fig. 4 baut der Bittabellenprozessor 30, wenn der Bittabellenprozessor 30 die Lastausgleichsprozedur 28 abgeschlossen hat, die Prozessorpipelineverbindungsliste 32 auf, die die Prozessorpipeline 50 definiert. Die Bitta­ bellenprozessorprozedur bewirkt unter Verwendung der Pro­ zessorpipelineverbindungsliste 32, daß eine Initialisie­ rungsanfrage von Element zu Element, die in der Verbindungs­ liste 32 (Kasten 76) aufgelistet sind, weitergeleitet wird. Wenn ein Softwaresteuerelement eine Initialisierungsanfrage empfängt, ist demselben bekannt, daß alle Stromaufwärtssteu­ erelemente in der Prozessorpipeline 50 initialisiert wurden, und daß dasselbe sich folglich selbst initialisieren kann. Wenn das Softwaresteuerelement Arbeit gemäß den Resultaten der Lastausgleichsprozedur erledigen muß (d. h., daß das­ selbe als Teil der Prozessorpipeline 50 konfiguriert ist), gibt das Initialisierungsverfahren ein Wahr zurück, und das Softwaresteuerelement wird in die Prozessorpipeline 50 ein­ gebunden. Wenn dies nicht der Fall ist, gibt das Initiali­ sierungsverfahren ein Falsch zurück, und dieses Software­ steuerelement wird gelöscht. Die Prozessorpipeline 50 ist folglich startend mit einer ausgewählten Bittabellenkompri­ mierungsprozedur 44 (d. h. Keine-Komprimierung-Prozedur 52, RLE-Komprimierungsprozedur 54 oder JPEG-Komprimierungspro­ zedur 56) und bis zu der Bittabellenleseprozedur 36 hochar­ beitend aufgebaut.

Sobald die Initialisierung der Softwaresteuerelemente in der Prozessorpipelineverbindungsliste 32 abgeschlossen wurde, ist die Prozessorpipeline 50 bereit, um die Handhabung der Rasterbittabelle 24 zu beginnen. Dementsprechend gibt der Bittabellenprozessor 30 eine Anfrage "HoleNächsteZeile" zu der Bittabellenkomprimierungsprozedur 44 aus, die die Anfra­ ge stromaufwärts weiterleitet. Die Anfrage erreicht die Bit­ tabellenleseprozedur 36, die durch Zugreifen auf eine näch­ ste Zeile der Bittabelle 24 (Kasten 78) anspricht, und es wird ein Stromabwärtsverarbeiten dieser Zeile durchgeführt, sowie dieselbe jedes Softwaresteuerelement erreicht. Die Prozedur fährt solange fort, bis alle Zeilen verarbeitet wurden.

Fig. 5 stellt ein spezifisches Beispiel der Lastausgleichs­ prozedur 28 dar, die eine Konfiguration der Bittabellenpro­ zessorpipeline 50 auf eine Art und Weise ermöglicht, um die Datenmenge zu reduzieren, die zu dem Drucker 20 übertragen werden soll. Wie es im folgenden offensichtlich werden wird, entscheidet sich die Lastausgleichsprozedur 28, die ver­ schiedenen Softwaresteuerelemente in dem Hostcomputer 10 zu implementieren, es sei denn, daß die Zuordnung von einem oder mehreren dieser Steuerelemente zu dem Drucker 20 dazu führen wird, daß weniger Daten zu dem Drucker gesendet wer­ den, und eine Beschleunigung des Druckauftrags resultiert.

Anfangs stellt die Lastausgleichsprozedur 28 die Variable "QuellbitsProPixel" auf gleich der Anzahl der Bits pro Pixel in der Bittabelle ein. Auf diesen Wert wird durch Senden einer Anfrage "HoleBitsProPixel" zu der Bittabelle (Kasten 80) zugegriffen. Danach wird dann, wenn die Ausgabe der Pro­ zessorpipeline 50 spezifiziert ist, um zu einem lediglich monochromen Drucker gespeist zu werden, und die Anzahl der Quellbits pro Pixel 8 überschreitet, die Variable Quellbits­ ProPixel auf gleich 8 eingestellt (Entscheidungskasten 82 und Kasten 84). Diese Handlung wird vorgenommen, da ein monochromer Drucker lediglich 256 Graustufen wiedergeben kann, so daß 8 Bit pro Pixel adäquat sind. Wenn im Gegensatz dazu ein anderer als ein monochromer Drucker verwendet wird (Entscheidungskasten 82), bewegt sich die Prozedur direkt zu einem Entscheidungskasten 86, bei dem bestimmt wird, welche Zitteroption angefragt wurde.

Man erinnere sich, daß das Ziel dieser Prozedur darin be­ steht, die Datenmenge zu reduzieren, die zwischen dem Host­ computer 10 und dem Drucker 20 übertragen wird. Wenn kein Zittern angefragt wird, bestimmt dementsprechend die Proze­ dur als nächstes, ob die Größe des Zielbilds nach dem Schneiden und Skalieren kleiner als die Größe des Quellbilds (Entscheidungskasten 88) ist. Wenn ja, dann kann kein Nutzen daraus gezogen werden, daß bewirkt wird, daß der Drucker 20 das Verarbeiten durchführt, das zu dem geschnittenen Ziel­ größenbild führt. Es sei bemerkt, daß "GeschnitteneZiel­ größe" der Bereich in Zielpixeleinheiten des Schnitts zwi­ schen dem Schneiderechteck und dem Zielrechteck (siehe Fig. 2) ist. Ferner ist "Quellgröße" der Bereich in Quellpixel­ einheiten des Quellrechtecks.

Dementsprechend wird, wie in Kasten 90 gezeigt, ein Beispiel eines Replikationsskalierelements 60 (Fig. 3) erzeugt und in die Pipeline 50, wenn benötigt, gestellt. Ferner wird ein Beispiel eines Bittabellenschneidens erzeugt und in die Pipeline, wenn benötigt (Kasten 92), gestellt.

Zurückkehrend zu Entscheidungskasten 86 wird, wenn die Zitterhandlung optional ist, eine Zitterhandlung in dem Hostcomputer lediglich dann durchgeführt, wenn die gezitter­ ten Bilddaten, die zu dem Drucker geleitet werden, weniger sind als die nicht-gezitterten Bilddaten. Wie in Entschei­ dungskasten 94 gezeigt, wird dies durch Vergleichen des Zielgrößenbilds, nach dem Schneiden, mit dem Quellgrößenbild multipliziert mit der Anzahl von Quellbits pro Pixel, be­ stimmt. Im allgemeinen wird ein zielgrößengeschnittenes Bild nach dem Zittern ein Bit pro Pixel zeigen. Wenn die Anzahl der Bits (bei einem Bit pro Pixel) in dem gezitterten Ziel­ größenbild kleiner als die Anzahl der Bits in dem Quellpi­ xelbild ist, lohnt es sich folglich Skalier-, Schneide- und Zitter-Handlungen in der Prozessorpipeline 50 in dem Host­ prozessor 10 (siehe Kasten 96) durchzuführen. Wenn im Gegen­ satz dazu das gezitterte, geschnittene Zielgrößenbild größer als die Anzahl der Bits in dem Quellbild ist, dann wird, anstatt daß die Datenmenge, die übertragen werden muß, er­ höht wird, die Bittabelle, so wie sie ist, zu einer Verar­ beitung durch den Drucker gesendet.

Schließlich wird, wenn die Zitteroption (Entscheidungskasten 86) immer auf Zittern eingestellt ist, dann das Skalieren und Zittern in der Prozessorpipeline 50 durchgeführt (Kasten 96). Dies ist deshalb so, da der Kundencode dies anfragt, selbst wenn dies die Datenmenge erhöhen kann. Kunden führen diese Anfrage durch, wenn dieselben gerätbereite Bittabellen manipulieren müssen. Es sei bemerkt, daß ein "Kunde" ein weiterer Teil des Druckertreibers ist, der eine Bittabelle verarbeiten muß, z. B. der Teil, der schnittstellenmäßig mit dem Betriebssystem verbunden ist.

Claims (7)

1. Verfahren zum Konfigurieren eines Druckertreibers (26), der sich in einem Quellcomputer (10) befindet, abhängig von einer Druckauftragsanfrage durch Manipu­ lieren einer Quellbittabelle vor der Übertragung zu einem Zieldrucker (20), wobei der Druckertreiber (26) mehrere, im wesentlichen unabhängige, Bittabellenmani­ pulationsprozeduren (34, 36, 38, 40, 44, . . .) auf­ weist, mit folgenden Schritten:

• a) Bestimmen eines Satzes von Quellcomputerbittabel­ lenmanipulationen, die in dem Quellcomputer (10) durchgeführt werden sollen, abhängig von der Art eines Druckauftrags, um die Verarbeitungseffizienz der Druckauftragsanfrage zu maximieren;
• b) Zusammenfügen einer Bittabellenprozessorpipeline (50) aus den Bittabellenmanipulationsprozeduren (36, 38, 40, 42, 44, . . .), um den Satz der Quell­ computerbittabellenmanipulationen (36, 38, 40, 42, 44, . . .) an der Quellbittabelle (24) auszuführen, wobei die Bittabellenmanipulationsprozeduren (36, 38, 40, 42, 44, . . .) in einer erforderlichen Bit­ tabellenverarbeitungsreihenfolge angeordnet wer­ den, derart, daß, wenn ein Bittabellensegment durch die Bittabellenprozessorpipeline (50) fort­ läuft, alle Bittabellenverarbeitungshandlungen in einer vorgeschriebenen Reihenfolge durchgeführt werden, und wobei eine beliebige Bittabellenmani­ pulationsprozedur (36, 38, 40, 42, 44, . . .) in der Bittabellenprozessorpipeline (50), die eine Anfra­ ge von einer Bittabellenmanipulationsprozedur (36, 38, 40, 42, 44, . . .) empfängt, die weiter stromab­ wärts in der Bittabellenprozessorpipeline (50) po­ sitioniert ist, lediglich mit einer angeforderten Handlung ansprechen kann, und ferner lediglich ei­ ne Kommunikation mit einer Bittabellenmanipula­ tionsprozedur (36, 38, 40, 42, 44, . . .) einleiten kann, die unmittelbar stromaufwärts von derselben positioniert ist; und
• c) Durchführen von Bittabellenmanipulationen unter Verwendung der Bittabellenprozessorpipeline (50), die in dem Schritt b) zusammengefügt wird.

2. Verfahren gemäß Anspruch 1, bei dem die Verarbeitungs­ effizienz der Druckauftragsanfrage durch Minimieren einer Bittabellendatenmenge maximiert wird, die zu dem Zieldrucker (20) gesendet werden soll.

3. Verfahren gemäß Anspruch 1, bei dem jede Bittabellen­ manipulationsprozedur (36, 38, 40, 42, 44, . . .), die einen Teil der Bittabellenprozessorpipeline (50) auf­ weist, die in dem Schritt b) zusammengefügt wird, auf jede Anfrage eines Satzes von gemeinsamen mehreren An­ fragen ansprechen kann, die die Bittabellenprozessor­ pipeline (50) hinauf gesendet werden.

4. Verfahren gemäß einem der Ansprüche 1 bis 3, bei dem der Druckertreiber (26) eine Bittabellenprozessorpro­ zedur (30) zum Steuern von Operationen der Bittabel­ lenprozessorpipeline (50) aufweist, und bei dem die Bittabellenprozessorpipeline (50) mit einer Eingangs­ bittabellenleseprozedur (36) beginnt, mit einer Aus­ gangsbittabellenmanipulationsprozedur (44) endet, und mindestens eine Zwischenbittabellenmanipulationsproze­ dur (38, 40, 42, 44, . . .) aufweist, und wobei Anfra­ gen, die von der Prozessorprozedur (30) während des Schritts c) empfangen werden, lediglich von der Aus­ gangsbittabellenmanipulationsprozedur (44) zu der Ein­ gangsbittabellenleseprozedur (36) durch beliebige Zwischenbittabellenmanipulationsprozeduren (38, 40, 42, 44, . . .), die sich zwischen denselben befinden, gesendet werden.

5. Verfahren gemäß einem der Ansprüche 1 bis 4, bei dem die Bittabellenmanipulationsprozeduren (36, 38, 40, 42, 44, . . .) mindestens folgende Prozeduren aufweisen: eine Bittabellenleseprozedur (36), eine Bittabellen­ skalierprozedur (38), eine Bittabellenschneideprozedur (40), eine Bittabellenzitterprozedur (42) und eine Bittabellenkomprimierungsprozedur (44).

6. Verfahren gemäß einem der Ansprüche 1 bis 5, bei dem die Bittabellenmanipulationsprozeduren (36, 38, 40, 42, 44, . . .) gemeinsame Schnittstellen mit dem Druckertreiber (26) aufweisen, um ein schnittstellen­ mäßiges Verbinden von weiteren Bittabellenmanipula­ tionsprozeduren (36, 38, 40, 42, 44, . . .) ohne die Er­ fordernis, andere Bittabellenmanipulationsprozeduren (36, 38, 40, 42, 44, . . .) zu modifizieren, zu ermög­ lichen.

7. Verfahren gemäß einem der Ansprüche 1 bis 6, bei dem das Bestimmen des Schritts a) mindestens auf Bild­ charakteristika der Quellbittabelle (24) und Charak­ teristika eines entsprechenden Bildes, das durch den Zieldrucker (20) erzeugt werden soll, basiert.