Mit Speedo in die Zukunft? Entwicklungsstand des ATARI-Vektorzeichensatzsystems
Nachdem die erste öffentliche Version von Speedo sich offensichtlich einiger Beliebtheit erfreute, aber immer noch einige Kinderkrankheiten mit sich herumschleppte, hat ATARI nun die Version 4.20 freigegeben. Mit dieser Release werden zumindest einige der Probleme der Urversion behoben und kleinere Fehler korrigiert.
Für den Anwender sicherlich die spürbarste Änderung betrifft das Laden der Zeichensätze bei der Benutzung von Ausgabegeräten unter Speedo. Noch bis zur Version 4.11 wurde sowohl beim Start jeder GDOS-Applikation als auch vor jedem ordnungsgemäßen Druckvorgang das komplette Schriftsystem geladen (oder zumindest durchsucht). Auch wenn man nur die mitgelieferten Zeichensätze angemeldet hatte, war das System immer einige Zeit mit sich selbst beschäftigt. In der aktuellen Version nun lädt die Betriebssystemerweiterung in dieser Situation nur noch die alten Pixel-Schriftsätze (sofern überhaupt noch im System angemeldet) immer wieder nach. Die Vektorzeichensätze werden nur ein einziges Mal in das System integriert, was bei Verwendung von alternativen Desktops (EASE, Gemini etc.) gleich beim Systemstart geschieht. Somit fällt die Wartezeit nur noch einmal und praktischerweise auch noch genau dann an, wenn man dem Rechner sowieso nicht die volle Aufmerksamkeit widmet.
Konfliktvermeidung
Als ein ernstes Problem in der Zeichensatzverwaltung stellte sich in der Version 4.11 der Konflikt von Zeichensatzkennung von Pixel-Zeichensätzen und Vektorschriften heraus. Konnte man bislang nur den Rat aussprechen, die Kombination beider Zeichen satztypen zu vermeiden, hat ATARI nun eine veränderte Kodierung ins Spiel gebracht. Vektorzeichensätze erhalten beim Laden durch das System automatisch einen ID-Offset von 5000. Damit können ID-Konflikte zwar nicht restlos ausgeschlossen werden, aber da die verfügbaren Pixel-Schriftfamilien eher im Bereich <= 255 angesiedelt waren, ist eine solche Überschneidung sehr unwahrscheinlich. Wichtig war diese neue Auskodierung aber vor allem deswegen, weil der ATARI-Systemzeichensatz (ID 1) mit einem der Bitstream-Swiss-Schnitte (Swiss 721 light) kollidierte.
Auch an die Systemfunktionen hat ATARI noch einmal Hand angelegt und ein paar kleinere Änderungen umgesetzt. Die gravierendste Änderung ist die Einführung der neuen Funktion vst_width(), die analog der schon von Beginn an im GDOS existierenden Funktion vst_height() die absolute Zeichenbreite festlegt. Damit kann man das System nun zwingen, bei den durch vst_height() vorgegebenen Zeichenhöhen auch die Breite (s. Kasten) der Zeichen zu manipulieren. Damit geht natürlich gerade bei Pixel-Schriften die originale Proportionierung verloren, was evtl, auch zu Lasten der Lesbarkeit geht. Sinn voll kann das aber dann sein, wenn man versucht, die in bestimmten Ausgabemedien (hier sind nat. vor allem Drucker angesprochen) fest vorgegebenen Schriftarten im System möglichst naturgetreu nachzubilden.
Anwesenheitskontrolle
Für Programme ist es in der Regel recht wichtig zu erfahren, ob und wenn ja welche Geräte zur Verfügung stehen. Dazu boten sich bislang nur zwei Verfahren an:
a) Das Programm scannt die Datei ASSIGN.SYS ,von Hand und ermittelt, welche Geräte unter welcher ID anzusprechen sind,
oder
b) das Programm öffnet der Reihe nach alle Geräte über die Systemfunktion vjopnwki) und prüft, ob der zurückgelieferte Handle einen Fehler signalisiert.
Beide Verfahren können aber nur unzureichend diese Aufgabe erfüllen. Im Fall a) weiß man zwar, daß der Benutzer das Gerät in der Steuerdatei eingetragen hat, aber ob es tatsächlich existiert, kann nur vermutet werden. Es existiert also ein Unterschied zwischen dem, was das Programm dann nach außen an den Benutzer weiterreicht, und dem, was an Systembedingungen tatsächlich vorliegt. Verfahren b) sieht da schon cleverer aus, allerdings auch nur auf den ersten Blick, denn man muß alle Geräte abklappem, die im System erlaubt sind. Spricht man nur Drucker an, sind's 10 (IDs 21-30), will man aber auf jedes im System erlaubte Medium zugreifen, sind es derer mehr als 50 (IDs 11-60 und ggf. >91). Dabei muß man jedesmal Treiberladezeiten und Timeouts abwarten und kann zum Schluß nicht einmal Auskunft darüber geben, wie das Gerät heißt.
Hoffnung schöpfte die Programmierer-schaft, als mit Speedo die Funktion vqt_devinfo() zur Verfügung gestellt wurde. Aber entgegen den geweckten Hoffnungen liefert die Funktion auch erst dann Angaben, wenn man versucht, den Ausgabetreiber anzusprechen. Trotz vielfältigen Eingaben bei ATARI bleibt es auch unter Speedo 4.20 bei diesem Verfahren und nur der Freude darüber, daß man so wenigstens den bis zu 26 Zeichen langen Namen des Druckers ermitteln kann (s. Quellcode).
#define FIRST_PRN_ID 21
#define LAST_PRN_ID 30
#define PRn_NAME_LEN 26
void get_speedo_printers( int ScreenVHandle, int dev_names[] )
{
int exists,i,handle=0,
work_in[128],
work_out[57]=(0);
char name[32];
/* Alle Treiber abklappern */
for(i = FIRST_PRN_ID; i <= LAST_PRN_ID; i++)
{
work_in[0] = i;
work_in[1] = 1;
work_in[2] = 1;
work_in[3] = 1;
work_in[4] = 1;
work_in[5] = 1;
work_in[6] = 1;
work_in[7] = 1;
work_in[8] = 1;
work_in[9] = 1;
work_in[10] = 2;
handle = ScreenVHandle;
/* Versuche den Treiber anzusprechen */
v_opnwk(work_in,&handle,work_out);
if(handle > 0)
{
/* Treiber meldet sich, also den Namen und die */
/* Verfügbarkeit abfragen •/
vqt_devinfo(handle,i,&exists,name);
switch(axiata)
{
case 1: /* Ausgabegerät ist ansprechbar */
strncpy(dev_names[1], name, PRN_MAKE_LeN);
if(dev_names[i][0] == '\0')
strcpy(dev_names[i], "(keine Speedo-Device)');
break;
case 0: /* Ausgabegerät ist nicht ansprechbar */
strncpy(dev_names[i],"n.a.");
break;
case -1: /* Fehler aufgetreten */
strncpy(dev_names[i], "Systemfehler");
break;
}
v_clswk(handle);
}
else
strncpy(dev_names[i],"");
}
}
Dieses Programm demonstriert die neue Speedo-Funktion vqt_devinfo
Inquire device Status Information (VDI248)
Liefert den Namen und die Verfügbarkeit der angesprochenen Ausgabeeinheit Prototyp:
void vqt_devinfo( int handle, int devnum, int *devexits, char *devstr);
GEM-Arrays:
contrl = 248
contrl+2 = 0
contrl+6 = 1
contrl+12 = handle
intin devnum (Treibernummer in der ASSIGN.SYS)
contrl+4 = 1
contrl+8 = Länge des Treibernamens
intout
intout+2 ... = devstr (der Treibername)
ptsout devexists (-1 = Fehler, 0 = Device not installed, 1 = Device installed )
Set character width, absolute mode (VDI 231)
Analoger Aufruf zu vst_height Setzt die absolute Zeichenbreite in Pixeln. Anmerkung: Genau wie beim Funktionspaar vst_arbpt(),vst_setsize() muß der Aufruf für das Setzen der Breite nach dem Setzen der Höhe geschehen, da eine neue Höhenangabe den Wert der Breitenangabe auf Systemwerte zurücksetzt Also zuerst die Zeichenhöhe mit vst_height() festlegen und dann eine bestimmte Zeichenbreite mit vst_width() setzen.
Prototyp:
void vst_height( int handle, int width. int *char_width, int *char_height, int *cell_width, int *cell_height),
GEM-Arrays:
contrl = 231
contrl+2 = 1
contrl+4 = 2
contrl+12 = handle
ptsin = 0
ptsin+2 = width
ptsout = char_width
ptsout+2 = char_height
ptsout+4 = cell_width
ptsout+6 = cell height
Die neuen Speedo-Funktionen
Druckertreiber
Ein bislang immer noch problematischer Bereich ist die Zusammenarbeit von Speedo mit Ausgabelreibem alter Bauart. Speedo prüft beim Laden der Ausgabetreiber, ob sie einen _FSM_HDR-Eintrag besitzen und stellt nur im Erfolgsfalle die Vektorzeichensatze zur Verfügung. Der angesprochene Eintrag wird durch das von ATARI vertriebene Device Developing Kit bei der Compilierung neuer Treiber automatisch angelegt, so daß zumindest für die Treiber dieser Schiene der Speedo-Support funktioniert. Installieren Sie zum erstenmal Speedo und wundem sich, daß beim Druck überhaupt nichts oder nur der Pixel-Teil eines Dokumentes auf dem Papier erscheint, sollten Sie schleunigst prüfen, ob Ihre Treiber Speedo-kompatibel sind. Am leichtesten läßt sich das mit dem bei Speedo mitgelieferten Accessory (DRIVERS.ACC) prüfen. Erscheint dort in der Druckerauswahl bei dem von Ihnen angemeldeten Druckertreiber in Klammem angefügt 'not Speedo', haben Sie in der Regel schon das Problem gefunden. Um Ihr Schriftbild wieder in den Griff zu bekommen, müssen Sie nun nur noch diesen Treiber durch ein Äquivalent mit Speedo-Support ersetzen.
Unabhängigkeitserklärung
Eine weitere wichtige Veränderung bei den Interna ist die Lossagung vom Line-A-Code. Ja, richtig gelesen. Obwohl ATARI seit langem selber davon abrät, Line-A zu benutzen, hat man sich im eigenen Hause wohl zunächst nicht an diese Prämisse gehalten und die Versionen 4.Ix über Line-A implementiert. Um aber die Systemunabhängigkeit (andere Grafikkarten, VDI-Ersätze) zu gewährleisten bzw. das Multitasking nicht unnötig zu stören, laufen nun alle Ausgaben über VDI-Calls.
Kleinkram
Neben den größeren Eingriffen in den GDOS-Kern blieb auch noch Zeit, einige kleinere Bugfixes anzubringen, so daß nun unter anderem auch die PostScript-Codierung der Zeichensätze funktioniert. Das vrtjcopxfmO der Treiber erfuhr ebenso eine Überarbeitung wie die fehlerhafte Implementierung der vst_height()-Funktion bei großen Höhenangaben.
Erwähnenswert ist auch noch eine Änderung im Verhalten der Funktionen vqt_advance() und vqt_width(). Bislang mußte man zusätzlich zu den gelieferten Ausmaßen der Zeichen die Offsets für Schrägstellung und eine Pixel-Konstante (2 Pixel) in Eigenregie addieren. Unter Speedo 4.20 werden diese Werte nun schon miteinberechnet. Setzen Sie also in Ihren Programmen die oben genannten Funktionen ein. um z.B. den Cursor zu positionieren, sollten Sie auf die jeweilige Speedo-Version eingehen oder besser noch auf die vqt_(f_)extent()-Funktionen umsteigen.
The real world
Insgesamt ist die aktuelle Version von Speedo eine dem allgemeinen VDI-Konzept angemessene Umsetzung von Vektorschriften auf den ATARI. Mittlerweile haben sich ja auch die meisten noch aktiv gepflegten GDOS-Applikationen an die Besonderheiten des Speedo angepaßt und unterstützen diese neuen Fähigkeiten so weit wie möglich.
Abschließend sollte aber nicht verschwiegen werden, daß das VDI in seiner jetzigen Form nicht geeignet ist, um zukunftsträchtige Entwicklungen auf dem ATARI zu forcieren. Bei kaum einem anderen Teil des Betriebssystems zeigt sich so klar, daß die Konzepte, die sich hinter dem TOS (mit seinem Ausgabeteil GDOS) verbergen, im wesentlichen nur angedacht sind und einer generellen Überarbeitung bedürfen.
Dabei liegen die Dinge sowohl bei der Benutzerfreundlichkeit als auch bei den Nutzungsmöglichkeiten des Systems durch Programme im Argen. Es ist gar nicht einzusehen. warum sich der unerfahrene Benutzer auf dem ATARI mit diversen Dateien (und deren Inhalten) herumschlagen muß, um das Ausgabesystem zur Mitarbeit zu bewegen, während es auf dem Apple Macintosh ausreicht, die Daten in den Systemordner zu kopieren. Dabei wäre es mit einfachen Mitteln leicht erreichbar, ein ähnliches Verhalten auch auf dem ATARI nachzubilden. Dies gilt natürlich nicht nur für SpeedoGDOS, sondern auch für die gesamte Systemarchitektur des ATARI.
Das Einzwängen von Speedo in das alte GDOS-Konzept hat neben der Einschränkung der Möglichkeiten auch zur Folge, daß alte Fehler aus der Vergangenheit mit in die Zukunft geschleppt werden. Hier wird unter anderem auch die Betriebssicherheit dadurch gefährdet, daß die Pixelzeichensätze einige Unzulänglichkeiten haben. So müssen beispielsweise in einem Pixel-Zeichensatz alle Zeichen innerhalb des im Zeichensatz-Headers angegebenen Bereiches definiert sein. Nicht definiert bedeutet in dem Codierverfahren der Pixel-Zeichensätze. daß es die Breite 0 hat. Beim Versuch, solche Zeichen (mit Breite 0) auszugeben, hat aber auch das aktuelle Speedo. genauer gesagt die damit verbundenen Ausgabetreiber, soseine Probleme. Im Regelfall führt das zu einem sang- und klanglosen Absturz. Viele Pixel-Schriften aus PD-Sammlungen, vor allem jene, die aus Konvertierungen von anderen Schriftsystemen herrühren, weisen solche nicht definierten Zeichen auf.
Das etwas traurige Resümee der ganzen Angelegenheit: gute Bemühung, schlechte Umsetzung.
Erik Dick