Big Times - frei wählbare Zeichensätze unter MultiTOS
Das neue MultiTOS-AES soll ein neues Feature bieten: frei wählbare AES-Fonts.
Die AES waren schon immer in der Lage, verschiedene Zeichensätze und Zeichensatzgrößen zu verarbeiten. Insbesondere der 10-Punkt-Standardzeichensatz ist dem Anwender bekannt. Er ist in allen TOSVersionen bereits im ROM vorhanden, muß also nicht erst zur Laufzeit ins System geladen werden. Er kann weder »eingeschaltet« noch aus dem Speicher entfernt werden, und ein GDOS ist zu seiner Verwaltung ebenfalls nicht nötig.
Mit ihm wurden Menütitel dargestellt und Dialogboxen gezeichnet. Er ist das erste, was der Anwender vom TOS zu sehen bekommt, sieht man einmal von dem »Atari«-Logo der TOS-Versionen 2.06 und 3.06 ab.
Darüber hinaus lernt der Anwender bald den »small«-Font kennen. Dieser Zeichensatz wird von vielen Applikationen für kleinere Knöpfe benutzt, beispielsweise legt »1st Word plus« eine Reihe von Funktionstasten auf den Bildschirm, deren Bedeutung das Programm in kleinen Buchstaben angibt.
Von der intensiven Anwendung dieser Zeichen sei dem Programmierer an dieser Stelle dringend abgeraten. Zum einen leidet die Lesbarkeit mitunter extrem unter den winzigen Wörtern, so daß die Bedienung sich insbesondere für den Einsteiger erschwert. Zudem sollte unbedingt bedacht werden: Ataris »Falcon 030« besitzt erstmals die Fähigkeit, Monitorbilder im interlaced Videoformat zu erzeugen. Diese Videosignale sind vom Amiga durch ihr Flackern bekannt. Auf dem Falcon gewinnen sie jedoch deshalb an Bedeutung, weil Fernsehbilder ebenfalls interlaced, also in Halbbildern zu etwa 50 Hz (ca. 25 Bilder pro Sekunde) vorliegen. Der Falcon 030 zielt auf das Marktsegment Heimbereich; es ist damit zu rechnen, daß zumindest in der Anfangsphase sehr viele dieser Geräte auch an Fernsehern betrieben werden. Aufgrund des massiven Flackerns der Fernsehbilder werden die winzigen Buchstaben fast unlesbar. Wer professionelle Videostudios als Vergleich heranzieht, wird feststellen, daß Profis kleine Schriftzüge um jeden Preis meiden.
Der AES-Standardzeichensatz ist also derjenige, der das Aussehen des Systems maßgeblich beeinflußt. Leider war es bisher sehr schwierig, andere Zeichensätze an seiner Stelle zu realisieren. Das gängigste Verfahren war, die TOSROMs auszulesen, mit einem neuen Zeichensatz zu patchen und in EPROMs zu brennen.
Flickwerk
Der größte Nachteil liegt jedoch auf der Hand: Zum einen kann ein einmal eingebrannter Zeichensatz später nicht ohne weiteres verändert werden, zum anderen bleibt die Größe des Zeichensatzes von der Modifikation unberührt. Ein kleinerer oder größerer Zeichensatz erfordert dann schon erheblich mehr Geschick bei der Implementation.
Seit viel zu langer Zeit reisen Vorführmodelle der Falcons durch die Lande, im Gepäck neue TOS- und MultiTOS-Versionen. Bei genauem Hinsehen stellte sich heraus, daß einige Anbieter zu Präsentationszwecken größere AES-Standardzeichensätze installiert haben. Diesmal jedoch nicht mit Hilfe einiger Hacks, sondern durch einen von Atari eröffneten Weg: über eine Konfigurationsdatei, deren Aufbau noch in der Schmiede ist und über den wir an dieser Stelle nicht näher eingehen werden.
Im Zusammenhang mit den, besonders in Deutschland oft benutzten, erweiterten Objekttypen gab es jedoch schnell Probleme: Viele Dialogroutinen gehen verständlicherweise davon aus, daß die AES den bekannten 10-Punkt-Zeichensatz verwenden und reagieren auf die Umstellung nicht, was in der Praxis zu drei verschiedenen Font-Größen in ein und demselben Dialog führte. Darüber hinaus passen die AES beim Resource-Fixing die Dialoggröße an die Größe des verwendeten AES-Zeichensatzes an und nicht etwa an die feste Größe des 10-Punkte-Fonts. Das führte schon immer zu allerlei Verwirrung, beispielsweise bei der Darstellung von Icons in den Auflösungen »ST-Mid« und »ST-Low«, in denen die Zeichensätze eine andere Höhe/Breite-Proportionalität verwenden als in allen anderen Bildschirmmodi.
Es wird also notwendig werden, daß die Programmierer ihre Routinen an alternative Zeichensätze und Zeichensatzgrößen anpassen. Zumindest für monospaced-Fonts dürfte der Arbeitsaufwand nicht allzu hoch sein.
Leider hat Atari im vorliegenden Beta-TOS noch keine AESFunktionen implementiert, mit der Programme die Parameter des AES-Standard-Fonts erfragen könnten. Das wird sich hoffentlich bis zur endgültigen Veröffentlichung der neuen AES ändern. Da Atari jedoch die Wartephase immer wieder verlängert hat, wurde eine Interimslösung für die anstehenden Präsentationen unverzichtbar.
Wir möchten an dieser Stelle einen Lösungsansatz vorstellen, weisen aber ausdrücklich darauf hin, daß das ausschließlich für die Zeit bis zur Veröffentlichung einer verläßlicheren Auskunftsfunktion Sinn macht.
Die Idee basiert auf der Tatsache, daß jedes Programm beim Öffnen einer virtuellen Workstation das Handle der physikalischen Workstation benötigt, welche die AES beim Starten des GEM-Systems geöffnet haben. Dazu verwenden Sie den Aufruf »graf_handle()«, der neben einigen belanglosen Informationen das besagte Handle zurückliefert. Nun kann dieses Handle dazu verwendet werden, die eingestellten Font-Parameter der physikalischen Workstation mit Hilfe der Funktion »vqt_attributes()« zu erfragen. Das war‘s? Nein, denn wie eingangs erwähnt, benutzen die AES einen kleinen und einen großen Font - und je nachdem, welcher von beiden zuletzt Verwendung fand, wird das Ergebnis des »vqt_attributes()«-Calls ausfallen. Es ist also sicherzustellen, daß unmittelbar vor Aufruf der »vqt_attributes()«-Funktion die AES auf den »größeren« Zeichensatz umgestellt wurden. Das wird im vorliegenden Listing dadurch erreicht, daß ein Zeichen per »objc_draw()« auf den Schirm gegeben wird und der Aufruf mit »wind_update()« geklammert ist, um die zwischenzeitliche Ausgabe eines anderen Programms oder Accessories zu unterbinden. Nach Ausgabe des Zeichens ist der ursprüngliche Zustand wiederherzustellen, was im Beispiellisting durch »vro_cpyfm()«-Aufrufe sichergestellt wird. Wem das zu aufwendig ist, der kann sich auch verlassen, daß ein mit dem Schreibmodus »ODER« geschriebenes Leerzeichen den Bildschirminhalt nicht verändert. Das setzt voraus, daß der Anwender keinen Zeichensatz benutzt, der aus irgendwelchen Gründen das Leerzeichen anderweitig belegt. Eine andere Belegung macht nicht viel Sinn. Wir haben uns dennoch für das Puffern entschieden, sofern Speicher erhältlich ist, was in der Startup-Phase eines Programms sehr wahrscheinlich ist.
Ein anderes Verfahren wäre, das Zeichen zu clippen, so daß ebenfalls keine Veränderung des Bildschirminhalts eintritt. Das setzt jedoch voraus, daß die AES solche Fälle nicht als Sonderfälle erkennen und nicht darauf reagieren. Zugegeben, auch dieser Fall ist unwahrscheinlich. Wir haben uns dennoch dagegen entschieden - sicher ist sicher. (uw)
/*
@(#) AES-Font erfragen/fonz.c
@(#) Laurenz Prüßner (c) 1992
Compiler: Pure-C.
Achtungt Codesegment, nicht einzeln lauffähig.
*/
#include <vdi.h>
#include <aes.h>
#include <portab.h>
#include <stdlib.h>
#define FALSE 0
#define TRUE !FALSE
/* Input: */
extern WORD v_planes; /* Anzahl der Planes der Bildauflösung */
extern WORD v_handle; /* Handle der virtuellen VDI-Workstation
extern WORD a_handle; /* Handle der physikalischen Workstation (AES) */
/* OutPut: */
WORD a_font, a_fsize, a_frotation; /* globale Ausgabevariable */
VOID fix_types( OBJECT *tree, WORD obj, WORD parent )
{
/* AES-Fontgröße ermitteln
static WORD tested = FALSE;
MFDB puf, screen = {0, 0, 0, 0, 0, 0, 0, 0, 0 };
WORD p[8], attribs[10], x, y, w, h, wl, hl, dummy;
OBJECT teststring =
{
-1, -1, -1, G_STRING,
LASTOB, NORMAL,
(LONG)“ „ /* Leerzeichen! */,
0x0000, 0x0000, 0x0001, 0x0001
} /* Beispielobjekt */
if (!tested)
{
rsrc_fix (&teststring, 0, -1);
fix_types_sub (&teststring, 0, -1);
form_center (&teststring, &dummy, &dummy, &dummy, &dummy);
obj_extend (&teststring, 0, &x, &y, &w, &h);
/* MFDB füllen */
puf.fd_w = w;
puf.fd_h = h;
puf.fd_wdwidth = (puf.fd_w + 15) >> 4;
puf.fd_stand = 0;
puf.fd_nplanes = v_planes;
puf.fd_addr = malloc( 2 * ((LONG) puf.fd_wdwidth) * h * v_planes);
if ((LONG) puf.fd_addr)
{ /* Hintergrund retten */
wl = w - 1;
hl = h - 1;
p[O] = x;
p[1] = y;
p[2] = x + wl;
p[3] = y + hl;
p[5] = p[4] = 0;
P[6] = wl;
p[7] = hl;
graf_mouse (M_OFF, OL);
wind_update (BEG_UPDATE);
vro_cpyfm (v_handle, S_ONLY, p, &screen, &puf);
/* Objekt zeichnen */
objc_draw (&teststring, 0, 8, x, y, w, h);
}
/* AES-Zeichensatz ermitteln */
vqt_attributes (a_handle, attribs);
if ((LONG) puf.fd_addr)
{ /* Hintergrund wiederherstellen */
p[1] = p[0] = 0;
p[2] = wl;
p[3] = hl;
p[4] = x;
p[5] = y;
p[6] = x + wl;
p[7] = y + hl;
vro_cpyfm (v_handle, S_ONLY, p, &puf, &screen);
wind_update (END_UPDATE);
graf_mouse (M_ON, OL);
free (puf.fd_addr);
}
/* Werte des AES-Zeichensatzes eintragen
a_font = attribs[0];
a_fsize = attribs[7];
a_frotation = attribs[2];
tested = TRUE;
}
/* Extended Types einpassen */
fix_types_sub (tree, obj, parent);
}
Laurenz Prüßner