Expertenforum: Plädoyer für Metafiles
Metafiles entsprechen der Struktur, die GEM intern für Grafiken verwendet: Trotzdem gibt es zur Zeit nur wenige Programme, mit denen sie sich als Bildschirmgrafiken laden lassen. Mit unserem Listing »SHOWMETA« geht's!
Grafik-Software für Atari-Rechner kennt keine Formatstandards. Der Datenaustausch zwischen den Programmen ist damit nicht nur erschwert, sondern in einigen Fällen sogar unmöglich. Unterstützt durch die Entwicklung des »GEM-Metafile« (Vektorgrafik) und »GEM-Image« (Rastergrafik) ist die Einigung auf ein von allen Programmen unterstütztes Format durchaus keine Utopie mehr.
Trotzdem führen Software-Hersteller immer noch gewichtige Gründe gegen den Metafile-Standard an. Ein häufiges Argument ist die unzureichende Dokumentation. Tatsächlich waren die ersten Beschreibungen von »DRI« in wesentlichen Punkten fehlerhaft. Für die gegenwärtige Situation gilt das kaum noch. Mittlerweile sind Metafiles nicht nur ausreichend besprochen, sondern gewährleisten auch eine flexiblere Handhabung als die meisten Vektorgrafikprogramme. Wesentlichen Anteil daran hat die sachgerechte »GEM/3«-Dokumentation. Kernstück der Definition: Bezierkurven und Grauverläufe, die eine spezielle Problematik darstellen, sind unmißverständlich beschrieben.
Dadurch läßt sich der Aufbau eines Metafiles gründlicher als bisher definieren: GEM wurde ursprünglich für den 80x86-Prozessor von Intel konzipiert. Daten werden folglich im Intelformat (erst Low-Byte dann High-Byte) abgelegt. Da aber Metafiles aus Worten (1 Wort = 2 Byte) bestehen, werden mit einer einfachen Schleife ganze Dateien konvertiert.
Am Dateikopf stehen, wie bei fast allen Dateiformaten, unverzichtbare Informationen: Die Länge dieses Headers, wie dieser Vorspann genannt wird, ist jeweils variabel. Normalerweise ist er 24 Worte, also 48 Byte lang.
Wichtig sind im wesentlichen vier Worte, die das Koordinatensystem der Zeichnung definieren. Zwei weitere Werte informieren über das jeweilige Seitenformat (in 1/10 mm). Die vollständige Definition des Headers wird durch unser Listing plausibel.
Daten hinter dem Dateikopf entsprechen in etwa dem »VDI«-Parameterblock mit »control«-, »ptsin«und »intin«-Array. Den Anfang macht das Control-Array. Das erste Wort enthält, wie »control[0]«, die VDI-Funktionsnummer (Opcode). Die folgenden beiden Worte enthalten die jeweilige Anzahl des »Ptsin«- und des »Intin«-Arrays. Im VDI-Parameterblock belegen sie »control[1]« und »control[3]«.
Im letzten Wort des Control-Arrays findet man die Nummer für Subfunktionen (Sub-Opcode). Sie wird z.B. für VDI-Escapes (VDI #5) und GDPs (Generalized Drawing Primitive, VDI # 11) benötigt. Der Opcode vereint gleich mehrere Funktionen.
Die folgenden Daten des »ptsin«- und »intin«-Arrays lassen sich folgendermaßen interpretieren: Die Wortzahl des »intin«-Arrays gibt »control[1]« vor. Das »ptsin«-Array verfügt über eine entsprechende Zahl von Koordinatenpaaren. Also die doppelte Anzahl der Worte von »control[3]« (!).
Metafile-Daten sind jeweils in einem geräteunabhängigen Format angegeben. Entweder sind sie im Header gespeichert oder im normalisierten Koordinatensystem (NDC) abgelegt. Nur in wenigen Fällen entsprechen sie den Werten, die für das Zielformat (z.B. den Bildschirm) gebraucht werden. Deshalb müssen sie projiziert werden. Dabei lassen sich nicht alle Einträge des »PTSIN«-Arrays nach der gleichen Methode umsetzen. Verschiedene Wertetypen werden abgelegt.
Es gibt normale Koordinatenpaare, die sich durch Subtraktion der unteren Grenze umwandeln lassen. Dazu werden sie anschließend mit der Größe des neuen Koordinatensystems multipliziert und im letzten Durchgang durch die vorherige Koordinatengröße dividiert. Die Funktion »conv_all« erklärt diesen Vorgang genauer.
Der zweite Werte-Typ besteht aus Längenangaben, wie sie etwa der Radius eines Kreises darstellt. Da es sich hier nicht um absolute Koordinaten, sondern um relative Werte handelt, ist die Subtraktion der unteren Grenze nunmehr tabu.
Eine Sonderstellung nehmen die drei Funktionen »vst_height«, »vsl_width« und »vsm_height« ein. Hier lassen sich die Daten »NDC-relativ« einsetzen. Der Wert für eine Liniendicke kann zwischen 0 und 32768 liegen.
Diese wenigen Angaben reichen bereits aus, eine Metafile-Leseroutine zu schreiben. Es gibt allerdings einige Erweiterungen des GEM/3-Formats, die auch TOS-Anwendern hilfreich sind. Wichtiger Bestandteil präziser Zeichnungen sind Bezierkurven.
MS-DOS-Anwendern sind Zeichnungen wie die Postscript-Standardgrafik bekannt. Ohne Bezierkurven wären diese computergrafischen Kunstwerke kaum umzusetzen gewesen. »Digital Research« hat im GEM 3.1 die Definition des Programms »GEM-Artline« übernommen. Für Bezierkurven gibt es zwei neue Funktionen innerhalb der »GDPs« mit den Nummern 12 und 13. »GDP 12« arbeitet mit einer Bezier-Poly-Linie. »GDP 13« benutzt ein Bezier-Polygon.
Das PTSIN-Array enthält, wie »v_polyline«, eine Liste der Koordinaten. Im »intin«-Array steht eine Bytefolge mit Steuercodes für die Bezierkurve, deren untere beiden Bits z.Z. relevant sind.
Das gesetzte unterste Bit deutet den Start eines neuen 4-Punkt-Beziers (Startpunkt, Stützpunkt 1, Stützpunkt 2, Endpunkt) an. Durch Setzen des zweiten Bits wird eine Verschiebung der aktuellen Koordinaten bewirkt. Dabei wird nicht gezeichnet. Derart lassen sich auch komplexe Objekte darstellen.
Damit Programme, die keine Beziers unterstützen, trotzdem Artline-Bilder verarbeiten können, hat sich »CCP«, der Hersteller von Artline, eine Übergangslösung einfallen lassen. Derzeit werden Beziers als Polylines (VDI #6) oder Polygone (VDI # 9) abgelegt. »CCP« hat nun einen Schalter definiert, der automatisch auf Beziers umschaltet. Die Funktion läßt sich mit GDP 13 einschalten. Dabei wird die Anzahl der Koordinatenpaare auf »1« gesetzt.
Ausgeschaltet wird, indem eine »0« als Platzhalter für die Zahl der Punkte angegeben wird. So können auch Programme Bezierbilder ausgeben, die normalerweise diese Funktion nicht unterstützen. Statt gefüllter und ungefüllter Bezierkurven werden Polylinien bzw. Polygone gezeichnet. Die Rundungen der Originalzeichnungen sind dann aber auf dem Bildschirm nicht zu sehen.
»GEM/3« bietet mit der Funktion »vs_gray_override« ein Werkzeug für Rasterverläufe. Sie hat den VDI-Opcode # 133 und benötigt nur einen Parameter mit einer Zahl zwischen 0 und 1000. Damit läßt sich der Sättigungsgrad eines Rasters angeben, mit dem alle Fülloperationen durchgeführt werden. Das aktuelle Füllmuster wird nicht mehr berücksichtigt.
Beziers halten langsam auch Einzug in die Atari-Gemeinde. In Düsseldorf wurde von Atari FSM-GDOS vorgestellt, das neben skalierbaren Fonts auch Bezierkurven in bester GEM/3-Manier beherrscht.
Unser Listing enthält ein Programm, mit dem GEM-Metafiles als Grafik auf beliebigen Bildschirmen ausgegeben werden (ähnlich wie »Guck«). Das Programm wird mit der Desktop-Funktion »Anwendung anmelden« installiert und erhält die Extension ».GEM«. Beim Anklicken eines Metafiles lädt »SHOWMETA« die Zeichnung automatisch auf den Bildschirm.
Das Listing ist mit Turbo-C 2.0 entwickelt worden. Ein kleiner Programmteil ist für den »MAS68k«-Assembler von Borland geschrieben und sollte zum Compilat hinzugelinkt werden.
Michael Bernards