Mehr Schub! Drucken übers System
Zeichenprogramme tun sich sehr schwer mit der Ausgabe von Grafiken auf dem Drucker. Meist grundlos! Das Betriebssystem TOS, das ATARI in seinen Rechnern ausliefert, bedient sich bekannterweise einer genormten Schnittstelle zur grafischen Ausgabe sämtlicher Daten. Warum sie also nicht benutzen?
Die grafische Schnittstelle, das VDI, das für alle Ausgaben verantwortlich ist, ähnelt grob dem Grafischen Kernsystem „GKS“. Seine Funktionen lassen sich in folgende Gruppen einordnen: Kontrollfunktionen, Attributfunktionen, Auskunftsfunktionen, Ausgabefunktionen, Rasterfunktionen, Eingabefunktionen und die sogenannten „Escapes“ - mehr oder weniger frei erfundene Zusatzfunktionen zur Ansteuerung hardwarespezifischer Features. Damit wäre auch gleich der wesentliche Vorteil genannt: egal, ob auf einen Bildschirm, einen Drucker beliebigen Herstellers oder in eine Datei ausgegeben wird, für das Programm ändert sich prinzipiell nichts, solange ein entsprechender VDI-Treiber das Umsetzen der GEM-Befehle auf die Hardware besorgt. Soviel zur Theorie.
In der Praxis sieht das leider etwas schwieriger aus. Ein nicht zu unterschätzender Grund für die Probleme, die vielen Programmierern erst beim Eincodieren bewußt werden, ist die bedauerliche Tatsache, daß einige Funktionen auf manchen Geräten gar nicht zur Verfügung stehen.
Das betrifft zum einen die bereits erwähnten Escapes, die per definitionem spezielle Features der verwendeten Treiber ansprechen und manchmal völlig undurchdacht erscheinen. Hier wird beispielsweise eine Hardcopy ausgelöst - klar, daß eine solche Funktion nicht auf einer Drucker-Workstation funktioniert - was wäre schließlich auch die Hardcopy eines Ausdrucks? Was allerdings eine solche Funktion im Bildschirmtreiber verloren hat, wird wohl ewig ein Geheimnis bleiben. Darunter befinden sich auch solche Anachronismen wie der „Alpha“-Modus, in dem ein Gerät plötzlich seine Grafikfähigkeiten verliert und nur noch als Text-Terminal ansprechbar ist.
Manche Escape-Funktionen wünschte man sich für alle Workstations, sie stehen aber nur für bestimmte zur Verfügung. Warum eine Funktion, die ein GEM-Image-File nicht nur ausgeben, sondern auch skalieren kann, ausschließlich Drucker- und Metafile-Treibern Vorbehalten sein soll, wird kaum jemand nachvollziehen können.
Und warum die Funktion „ESCAPE 2000” (wer um alles in der Welt hat sich diesen Namen ausgedacht?), die dazu dient, die letzte gedruckte Seite mehrfach auszugeben, ausschließlich ATARIs SLM-Druckern Vorbehalten bleiben soll, wird auch kaum jemand begreifen. Es wäre vermutlich ein Kinderspiel, diese Funktion allen Druckertreibern zur Verfügung zu stellen.
Ein weiteres Problem war jahrelang die Ausgabe von Schrift auf dem Drucker. Die von GEM verwendeten Schriften mußten für jede Workstation einzeln angemeldet werden - vom Anwender, wohlgemerkt, dem in der Regel kaum klarzumachen war, was er sich denn unter einer ASSIGN.SYS-Datei vorzustellen habe.
Das Resultat war, daß viele Schrifttypen auf dem Bildschirm zur Verfügung standen, beim Ausdruck jedoch nicht an die höhere Auflösung des Druckers angepaßt werden konnten und damit beim Ausdruck ausfielen.
Damit hat ATARI glücklicherweise mittlerweile aufgeräumt. Das nun in einer neuen, korrigierten Fassung vorliegende SpeedoGDOS beseitigt dieses Problem ein für allemal. Darüber hinaus hat ATARI alle schwerwiegenden Kritikpunkte ([1],[2], [3], [4]) an SpeedoGDOS beseitigt, so daß das Programm, das mittlerweile in der stark überarbeiteten Version 4.2 vorliegt, wirklich jedem Anwender uneingeschränkt empfohlen werden kann.
Zwar kann SpeedoGDOS auch keine Raster-Fonts skalieren, alle mitgelieferten Vektorzeichensätze hingegen paßt es an die jeweilige Auflösung des verwendeten Druckers an.
ATARI empfiehlt Anwendern wie Programmierern, auf die gemeinsame Verwendung von Raster- und Vektor-Fonts zu verzichten, obschon SpeedoGDOS dies grundsätzlich gestattet und auch das Problem der ID-Kollisionen ([3], [4J) mittlerweile dadurch gelöst ist, daß die VDI-IDs der Vektor-Fonts grundsätzlich verschoben werden und nicht mehr identisch mit denen der Bitstream-ID sind, die bei Bedarf separat abgefragt werden kann. Folglich bestehen mehr und mehr Programme auf den Einsatz der flexiblen Vektorzeichensätze - es ist abzusehen, daß Rasterzeichen schon bald völlig in Vergessenheit geraten.
Eines der bislang größten Probleme bleibt jedoch die Ausgabe von Bitmap-Rastern - sprich: Bildern. Hier ist das Problem jedoch prinzipiell anders gelagert als bei den Rasterzeichensätzen. Denn Bilder lassen sich sehr wohl vergrößern und verkleinern, und die dabei auftretenden Qualitätsverluste lassen sich - mit entsprechend hohem Rechenaufwand - herauspolieren. Nun wäre es vielleicht etwas viel verlangt, vom VDI-Treiber zu erwarten, daß er diese Aufgabe übernimmt. Daß so etwas zwar durchaus möglich ist, zeigen andere Betriebssysteme, jedoch sind diejenigen Programme, die Rasterbilder verarbeiten, in der Regel selbst in der Lage, derartiges zu übernehmen. Die Problematik ist jedoch eine andere: die VDI-Rasterfunktionen gehören nämlich nicht zu denjenigen. die Digital Research als „zwingend“ für Druckertreiber vorgeschrieben hat. Demzufolge muß der Programmierer davon ausgehen, daß sie nicht vorhanden sind.
Das wiederum stellt ihn vor schier unlösbare Probleme: Wie soll er die Bilddaten zum Drucker bringen?
Dieses Problem hat die Programmierer schon sehr viel Zeit und Nerven gekostet. Entsprechend vielfältig sind ihre Lösungen. Manche Systeme verlassen sich gar nicht erst auf die VDI-Druckertreiber, sondern stellen eigene Treiber zur Verfügung - die denkbar schlechteste Lösung. Denn damit ist der Kunde auf Gedeih und Verderb auf den Hersteller angewiesen.
Andere kopieren das Raster einfach direkt mit einer selbstgestrickten Routine in den Speicher des Druckertreibers - auch eine sehr wacklige Sache, da der Treiberspeicher nicht zusammenhängend sein muß und die Methode zur Bestimmung der Treiberadresse ebenfalls unzuverlässig ist.
Wieder welche schreiben jedes Pixel und jede Linie einzeln in den Drucker -was zwar das sicherste, aber auch das langsamste ist, denn allein die Übertragung einer DIN-A4-Seite an den Treiber kann damit Minuten dauern.
Zuletzt benutzen einige „userdefined Patterns“, vom Programmierer selbstdefinierte Füllmuster, was jedoch einen recht großen algorithmischen Aufwand bedeutet und bei Farbdruckern erst seit kurzem einigermaßen funktioniert - genauer: seitdem die Hamburger Firma „Scilab“ die bestehenden Farbtreiber-Kits diesbezüglich überarbeitet und korrigiert hat.
Alles in allem ein recht trostloses Bild für Zeichenprogramme.
ATARI, auf diese Probleme angesprochen, reagierte überraschend zügig. Und zwar gab Sunnyvale kurzerhand eine Rasterkopierfunktion für die Benutzung mit Druckertreibern frei, deren Funktion bislang nicht garantiert war. vrt_cpyfm() heißt die Funktion, die es nicht nur gestattet, Raster aus dem Speicher auf die Drucker-Workstation zu kopieren, sondern die außerdem in der Lage ist, das Raster dabei mit einer beliebigen Farbe zu versehen, falls ein Farbdrucker Verwendung findet. In älteren Druckertreibern, so hieß es aus den USA, könne dies zu Problemen führen, sämtliche SpeedoGDOS-Treiber seien jedoch in der Lage, vrt_cpyfm() ordnungsgemäß auszuführen.
Die Sache hat allerdings einen kleinen Haken: da einige Druckertreiber die Bildschirmseite nicht als zusammenhängenden Speicherblock aufbauen, sondern ihn scheibenweise generieren, wird diese Funktion „gespoolt“. Da das Quellraster größer als eine Speicherscheibe (ein „Band“) sein kann, wird der vrt_cpyfm()-Aufruf erst ausgeführt, wenn ein v_updwk()-call den Ausdruck startet. Der eigentliche Kopiervorgang findet also unter Umständen erst während des Drückens statt.
Diese kleine Komplikation könnte dann auch der Grund dafür sein, daß das Zeichenprogramm „Papillon“, das als bislang einziges die Möglichkeit anbietet, über vrt_cpyfm() zu drucken, in seinen älteren Versionen noch nicht mit allen Druckertreibern passable Ergebnisse liefert.
Immerhin ist es jedoch den Programmierern hoch anzurechnen, daß sie überhaupt auf die Idee gekommen sind, diese Rasterkopierfunktion zu verwenden - zumal es bislang keine offizielle Dokumentation darüber gab und streng genommen ja auch noch immer nicht gibt.
Programme, die diesen Trick verwenden möchten, müssen also dafür Sorge tragen, daß das Quellraster zum Zeitpunkt des Ausdrucks im Speicher noch genau dort steht, wo es beim vrt_cpyfm()-call gestanden hat. Das ist jedoch alles andere als ein unlösbares Problem.
Literatur:
[1] L. Prüßner. „Sekt oder Selters“, ST-Magazin 4/93, Seite 64ff., AWi Verlag.
[2] L. Prüßner, „Summertime Blues“, ST-Magazin 6/93, Seite 56f., AWi Verlag
[3] L. Prüßner, „Fertig - oder nicht?“, ST-Magazin 7/93, Seite 88f., AWi Verlag.
[4] L Prüßner, „Treibjagd”, ST Magazin 8/93. Seite 48f., AWi Verlag.
Laurenz Prüßner