Skip to main content
main-content

Inhaltsverzeichnis

Frontmatter

Einleitung

Frontmatter

1. Grundkonzepte von GKS

Zusammenfassung
Das graphische Kernsystem GKS ist ein internationaler Graphikstandard. Ausführliche Betrachtungen über die verschiedenen Graphikstandards finden sich in [GÖB] oder [ENDE2]. Um GKS richtig einordnen zu können, unterscheiden wir bei den Graphikstandards folgende Kriterien:
  • Typ: Standard für graphische Funktionen oder Bilddateien.
  • Dimension: 2-D oder 3-D Graphik.
  • Status: offizieller ISO-Standard oder sogenannter Industrie-Standard
  • Abstraktions-Niveau: Wie abstrakt oder gerätenah ist der Standard?
  • Erfolg: Gelangen Implementierungen über ein Prototypen-Stadium hinaus?
Jörg Bechlars, Rainer Buhtz

2. Sprachanbindungen (FORTRAN und C)

Zusammenfassung
GKS ist ein Standard, der unabhängig von einer speziellen Programmiersprache festgelegt wurde. Für den Anwender allerdings stellt es sich als Unterprogrammbibliothek in einer konkreten Programmiersprache dar. Die meisten Implementierungen sind in FORTRAN [FOR] und C [C] durchgeführt worden, wobei allerdings auch auf einer FORTRAN- oder C-Implementierung weitere Sprachanbindungen realisiert sein können. Um tatsächlich die Portabilität der Anwendungsprogramme auf verschiedenen GKS-Implementierungen zu gewährleisten, wurden die Sprachanbindungen für GKS ebenfalls als Standard verabschiedet ([GKSL1],[GKSL4]). Es werden darin die Namen der Unterprogramme und die Realisierung der abstrakten GKS-Datentypen in der konkreten Programmiersprache definiert. In diesem Buch wird GKS zusanunen mit der FORTRAN-Sprachanbindung beschrieben. Die C-Sprachanbindung ist im Anhang enthalten. Die Beispielprogramme sind in FORTRAN geschrieben, dürften allerdings C-Programmierern keine Verständnisschwierigkeiten bereiten.
Jörg Bechlars, Rainer Buhtz

3. Für ganz Eilige ...

Zusammenfassung
...und für alle, die nicht das gesamte Buch einmal von vorn bis hinten durcharbeiten wollen, bevor sie mit der Arbeit anfangen, ist dieses Kapitel gedacht.
Jörg Bechlars, Rainer Buhtz

Level 0a

Frontmatter

4. Polyline-Ausgabe

Zusammenfassung
Die meisten graphischen Anwendungen geben auch Linien aus — und diese minimale Anforderung wurde auch zu allen Zeiten von allen Graphikpaketen erfüllt. Während früher die gesamte Graphik letztlich über die Ausgabe von Linien abgewickelt wurde, ist in GKS das Polyline eins von fünf gleichberechtigten Ausgabe-Primitiven. Daher erscheint es sinnvoll, den Einstieg in GKS über solche vertrauten Anwendungen zu beginnen.
Jörg Bechlars, Rainer Buhtz

5. Workstations

Zusammenfassung
Im Gegensatz zu älteren Graphiksystemen, die speziell auf ein Gerät zugeschnitten waren oder lediglich eine Bilddatei erzeugen konnten, die hinterher von Postprozessoren visualisiert wurde, kann ein Anwendungsprogramm mit Hilfe von GKS jedes graphische Gerät direkt ansteuern. Das ist für Geräte mit Eingabefähigkeit durchaus wörtlich zu nehmen. Reine Ausgabegeräte — also Plotter — werden üblicherweise wie Drucker von einem Spooler bedient. In diesem Fall erzeugt GKS zunächst eine Datei, die anschließend weitergereicht wird.
Jörg Bechlars, Rainer Buhtz

6. Kontextregeln und Fehlerbehandlung

Zusammenfassung
Wie jedes andere Graphikpaket benætigt auch GKS einen festen Startaufruf, mit dem das System als Ganzes initialisiert wird. Nach den Diskussionen des vorigen Kapitels wissen wir, daß OPEN WORKSTATIONzur Initialisierung einer einzelnen Workstation benutzt wird und daher im Programrn an unterschiedlichen Stellen mehrfach aufgerufen werden darf, urn verschiedene Workstations — auch simultan — zu æffnen.
Jörg Bechlars, Rainer Buhtz

7. Polymarker-Ausgabe

Zusammenfassung
In den vergangenen drei Kapiteln haben wir die wichtigsten Konzepte, die zur einfachen Ausgabe mit GKS (also zum Level 0a) gehören, diskutiert. Ausgehend vom Polyline als dem wohl vertrautesten graphischen Element lernten wir das Attributkonzept von GKS mit den Bundles, Bundle Representations, Individual Attributes und Aspect Source Flags kennen. Ferner besprachen wir die zweistufige Koordinatentransformation in GKS mit der Normalization Transformation, die die Benutzerwelt auf den abstrakten NDC Space abbildet, sowie der Workstation Transformation, die die Abbildung des NDC Space auf die physikalische(n) Zeichenfläche(n) der Workstation(s) regelt. Schließlich diskutierten wir noch die Fehlerbehandlung und -protokollierung in GKS. Mit diesem Wissen versehen, können wir nun wieder etwas mehr wirkliche Graphik betreiben und genauer auf die restlichen Ausgabe-Primitive von GKS eingehen.
Jörg Bechlars, Rainer Buhtz

8. Textausgabe

Zusammenfassung
Kaum eine Graphikanwendung kommt ohne Beschriftung aus. Daher enthält GKS — wie fast jedes Graphiksystem — die Möglichkeit, einen Text auszugeben. Trotz allen Komforts, den wir in diesem Kapitel noch kennenlernen werden, geht es nur um Beschriftungen, die den Umfang einer einzigen Zeile nicht überschreiten.
Jörg Bechlars, Rainer Buhtz

9. Fill-Area-Ausgabe

Zusammenfassung
Die bisher besprochenen Ausgabefunktionen Polyline, Polymarker und Text umfassen die klassische Liniengraphik, die schon in der Frühzeit der graphischen Datenverarbeitung auf den damals verfügbaren Stift-Plottern die Ausgabe von Koordinatenachsen und Funktionsgraphen möglich machte. Der immer stärkere Trend zu Graphikbildschirmen und Plottern auf Rasterbasis führte inzwischen jedoch zu neuen Graphikanwendungen, die sich mit Hilfe dieser Primitives nicht oder nur mit unverhältnismäßig großem Aufwand realisieren lassen, wie z.B. thematische Kartographie oder die Ausgabe von Rasterbildern. Daher gibt es in GKS zwei weitere Ausgabefunktionen Fill Area (Füllgebiet) und Cell Array (Zellmatrix), die in diesem und im nächsten Kapitel besprochenen werden.
Jörg Bechlars, Rainer Buhtz

10. Cell-Array-Ausgabe

Zusammenfassung
Zur Ausgabe eines Rasterbildes dient eine eigene Ausgabefunktion, das Cell Array (Zeltmatrix). Ein Cell Array ist (wie das uns schon bekannte Pattern Array) eine zweidimensionale Matrix von Colour Indices und wird in einem von zwei Eckpunkten definierten Rechteck dargestellt.
Jörg Bechlars, Rainer Buhtz

11. Pixel-Rückgabe

Zusammenfassung
In den vergangenen beiden Kapiteln haben wir mit Cell Array und Pattern die Ausgabe zweidimensionaler Farbmatrizen kennengelernt und vorausgesetzt, daß die Daten unabhängig von GKS berechnet oder von einer Datei eingelesen wurden. In diesem Kapitel lernen wir, wie man diese Farbmatrizen mit eigener Graphik erzeugen kann. Wir skizzieren zwei Anwendungen:
Pattern-Anwendung: Man erzeugt mit beliebigen Ausgabefunktionen wie Poly-line, Text oder Fill Area eine Graphik. Nachdem man die Graphik als Rasterbild vom Bildschirm eingelesen hat, definiert man sie als Pattern. Mit Hilfe eines Metafiles (siehe Kapitel 14) wird dieses Pattern sogar für andere GKS-Programme nutzbar.
Jörg Bechlars, Rainer Buhtz

12. Zwei „Hintertüren“: GDP und Escape

Zusammenfassung
Wie bei allen Standards gibt es auch bei GKS seitens der Anwender Wünsche, die über den Standard hinausgehen. Das veranlaßt wiederum die kommerziellen GKS-Anbieter, zusätzliche Funktionen zur Verfügung zu stellen. Der Preis für die Nutzung dieser Erweiterungen ist der Verlust an Portabilität zwischen verschiedenen GKS-Anbietern. Während die eher verdeckten Abhängigkeiten von verschiedenen Implementierungen und Geräteklassen Gegenstand des folgenden Kapitels sind, werden hier zwei GKS-Funktionen besprochen, die nur in ihrem Aufruf genormt sind und für Erweiterungen zur Verfügung stehen (Originalton GKS: „a standard way of being non-standard“). Der Vorteil dieser Methode ist, daß dem Anwender Probleme beim Linken seiner Programme bzw. Programmabstürze erspart bleiben und stattdessen das Fehlen einer Funktion in der Fehlerprotokolldatei vermerkt wird.
Jörg Bechlars, Rainer Buhtz

13. Portabilität von GKS-Anwendungen

Zusammenfassung
Mit GKS wurde es erstmals möglich, graphische Anwendungen zu entwickeln, die sowohl interaktiv als auch portabel sind. Das bedeutet jedoch nicht, daß jede Anwendung auf jedem Graphikgerät sinnvolle Ergebnisse liefert. Im letzten Kapitel haben wir zwei GKS-Funktionen kennengelernt, mit denen wir uns explizit von einem GKS-Anbieter abhängig machen. Ziel dieses Kapitels ist es, die impliziten Grenzen der Portabilität offenzulegen. Zuerst legen wir allerdings fest, welche Voraussetzungen für eine Untersuchung der verschiedenen Abhängigkeiten erfüllt sein müssen:
  • Die Anwendung selbst ist rechnerunabhängig programmiert.
  • Eine GKS-Implementierung mit passender Sprachanbindung und ausreichendem Level (siehe Kapitel 1) steht zur Verfügung.
  • Die GKS-Implementierung selbst ist korrekt und erfüllt die Anforderungen einer Zertifizierung (siehe Literaturverzeichnis [KIPF]).
Jörg Bechlars, Rainer Buhtz

14. Bilddateien

Zusammenfassung
Zur Speicherung und zum Austausch von Bildern dienen sogenannte Bilddateien (Metafiles). Sobald man eine Graphik zu einem späteren Zeitpunkt oder mit einem anderen Programm weiterbearbeiten will, benötigt man eine Bilddatei. Wichtig ist die Tatsache, daß die Graphik auf einer Bilddatei geräteunabhängig gepeichert ist und sich noch auf beliebigen Graphikgeräten ausgeben läßt. Weiterhin werden Metafiles benötigt,
  • um aufwendige Anwendungsprogramme, die keine Interaktion des Benutzers benötigen, im Stapelbetrieb ablaufbar zu machen.
  • um weiterverarbeitbare Graphiken austauschen zu können, ohne gleichzeitig die erzeugenden Programme und Daten zugänglich zu machen.
Jörg Bechlars, Rainer Buhtz

Level 1a

Frontmatter

15. Segmente

Zusammenfassung
Mit diesem Kapitel beginnt nicht nur ein neuer GKS-Level, sondern auch ein neues Lernziel: Kapitel 1 bis 14 behandeln alles zur graphischen Ausgabe, Ziel ist die Erstellung wunschgemäßer Bilder. Kapitel 15 bis 28 behandeln interaktive Graphik mit Bildmanipulation; hier ist das Ziel ein wunschgemäßes Verhalten interaktiver Anwendungsprogramme. Wir behandeln zuerst die Möglichkeiten der Bildmanipulation und anschließend die graphische Eingabe (ab Kapitel 19).
Jörg Bechlars, Rainer Buhtz

16. Dynamische Bildänderungen

Zusammenfassung
Dieses Kapitel setzt das Workstation-Kapitel (Kapitel 5) fort. Die Behandlung dynamischer Bildänderungen ist eine Workstation-Eigenschaft, die sich erst nach Einführung des Segmentbegriffs beschreiben läßt. Die wichtigsten Merkmale sind im folgenden aufgeführt:
  • Eine dynamische Bildänderung kann durch die Setzung von Workstation- oder Segment-Attributen verursacht werden. Sie liegt dann vor, wenn bereits gezeichnete Bildteile nachträglich geändert werden.
  • Auf jeder Workstation kann es dynamische Bildänderungen geben, die sich ohne spürbaren Zeitaufwand (immediately) realisieren lassen (Beispiele aus Kapitel 5: Colour Table auf Raster-Bildschirmen, Zoom auf Vector-Refresh-Bildschirmen), während die übrigen dynamischen Bildänderungen eine Bildregenerierung (implicit regeneration) erforderlich machen. Achtung: Bei der Bildregenerierung geht Graphik außerhalb von Segmenten verloren.
  • Zur Vermeidung unbeabsichtigter Bildänderungen empfehlen wir folgendes: Workstation-Attribute stellt man am besten bei leerer Zeichenfläche ein, also nach dem OPEN WORKSTATION oder CLEAR WORKSTATION. Darauf wurde bereits in Kapitel 5 hingewiesen. Genauso setzt man Segment-Attribute — wir besprechen sie im folgenden Kapitel — am besten beim leeren Segment, also direkt nach CREATE SEGMENT.
Jörg Bechlars, Rainer Buhtz

17. Segment-Attribute

Zusammenfassung
Im letzten Kapitel lernten wir, wie man mit Hilfe der Segmente und der dynamischen Änderung von Workstation-Attributen gewisse Manipulationen an einem bestehenden Bild vornehmen kann. Wesentlich interessanter ist im allgemeinen die Bildmanipulation mit Hilfe der sogenannten Segment-Attribute, die wir in diesem Kapitel besprechen werden. Bei der Definition des Segmentbegriffs wurde festgelegt, daß der Inhalt eines Segments nach dessen Erzeugung nicht mehr zu ändern ist. Es ist also nicht möglich, einem fertigen (geschlossenen) Segment z.B. noch einen Strich hinzuzufügen. Vielmehr erstrecken sich alle Manipulationen auf das Segment als Ganzes, und zwar auf gewisse Aspekte, die das Aussehen des Segments bestimmen, eben auf seine Attribute.
Jörg Bechlars, Rainer Buhtz

Level 2a

Frontmatter

18. Kopieren von Segmenten

Zusammenfassung
Alles was wir bisher über Segmente gelernt haben — wie Bildmanipulationen oder Bilderneuerung — spielte sich innerhalb einer Workstation ab. Der konzeptionell einer Workstation zugeordnete Segmentspeicher wird in GKS als Workstation Dependent Segment Storage (WDSS) bezeichnet.
Jörg Bechlars, Rainer Buhtz

Level 0b

Frontmatter

19. Eingabe für Einsteiger

Zusammenfassung
Das gesamte Segmentkonzept, das wir in den letzten Kapiteln besprochen haben, dient hauptsächlich dazu, Bilder manipulieren zu können. Sinnvoll einsetzbar sind diese Bildmanipulationen allerdings erst im Zusammenhang mit Eingabefunktionen, mit deren Hilfe sie interaktiv am Bildschirm vorgenommen werden können. Aber schon für wesentlich schlichtere Aufgaben wie die Steuerung des Programmablaufs werden Eingabemöglichkeiten benötigt. GKS stellt dem Anwendungsprogrammierer verschiedene Eingabemöglichkeiten zur Verfügung.
Jörg Bechlars, Rainer Buhtz

20. Eingabemodell

Zusammenfassung
Nachdem wir im letzten Kapitel eine praxisbezogene Einführung in die einfachsten Benutzungsarten interaktiver Graphik mit GKS gegeben haben, schließt sich nun ein etwas mehr theoretischer Teil an. Die exakte Beschreibung der graphischen Eingabe ist nämlich nicht so einfach, wie die Beschreibung der Ausgabe. Ein graphisches Ausgabegerät kann eben z.B. Linien zeichnen. Wie das im einzelnen realisiert wird, muß niemand wissen. Das Anwendungsprogramm ruft die entsprechenden GKS-Funktionen auf, und das Bild entsteht. Bei diesem Vorgang kommunizieren nur das Anwendungsprogramm und die Workstation.
Jörg Bechlars, Rainer Buhtz

21. Locator-Request-Eingabe

Zusammenfassung
Nach den allgemeineren Betrachtungen des vorigen Kapitels kommen wir nun zur Diskussion der einzelnen Eingabeklassen in GKS. Als erste Eingabeklasse besprechen wir den Locator, die Eingabe einer Position. Wie bei allen Koordinaten oder Punkten hat es der GKS-Anwender mit Weltkoordinaten zu tun. Das macht die Locator-Request-Eingabe etwas komplizierter. Während die Transformation von einem Punkt auf der Zeichenfläche in das NDC-Quadrat mit der inversen Workstation-Transformation eindeutig möglich ist, ist die weitere Transformation von NDC- in Weltkoordinaten eine inverse Normalisierungstransformation, von denen mehrere in Frage kommen können. Daher besteht der Eingabewert (Measure) eines Locator Device aus
  • einer Position auf der Zeichenfläche in Weltkoordinaten.
  • einer Nummer, die angibt, welche Normalization Transformation herangezogen wurde. Mit der Inversen dieser Transformation wurde aus der NDC-Position die Position in Weltkoordinaten berechnet.
Jörg Bechlars, Rainer Buhtz

22. Stroke-Request-Eingabe

Zusammenfassung
Zu den wichtigen Anwendungen von Graphikeingabe gehört das Digitalisieren: Der Anwender fährt mit einem Stift eine Linie entlang (z.B. Grenzlinie eines Staates auf einer Landkarte). Dabei gelangt entweder manuell (durch Aufdrücken des Stiftes) oder automatisch (nach gewissen Zeit- oder Abstandskriterien) eine Punktserie ins Anwendungsprogramm. Das Anwendungsprogramm kann diese Punktserie dann wieder als Polylines ausgeben und auf diese Weise z.B. Landkarten erzeugen. Wichtiger ist noch das Abspeichern der Daten in einer Datenbank zur weiteren Verarbeitung.
Jörg Bechlars, Rainer Buhtz

23. Valuator-Request-Eingabe

Zusammenfassung
Valuator-Eingabe bedeutet, einen Wert innerhalb eines zulässigen Bereichs einzugeben. Eine Methode, Zahlenwerte mit GKS von der Tastatur ins Anwendungsprogramm zu transportieren, haben wir bereits kennengelernt. Wir lasen die Zahl erst einmal mit REQUEST STRING als String ein und wandelten den String dann mit Hilfe einer FORTRAN-Funktion um. Die Einzelheiten sind in Kapitel 19 nachzulesen.
Jörg Bechlars, Rainer Buhtz

24. Choice-Request-Eingabe

Zusammenfassung
Choice-Eingabe bedeutet, aus einem vorgegebenen Satz von Alternativen eine auszuwählen. Auch beim Thema Choice haben wir bereits eine (behelfsmäßige) Methode kennengelernt. Der Anwender trifft die Auswahl, indem er die Alternativen als Text-Strings eingibt (das Programm verzweigt dann in Abhängigkeit von den eingegebenen Texten):
REAL X(100),Y(100)
CHARACTER*1 STR
...
CALL GMSG ( IWK, ’Bitte P fuer Polyline,’ )
CALL GMSG ( IWK, ’M fuer Polymarker eingeben’ )
CALL GRQST ( IWK, 1, ISTAT, L, STR )
IF(ISTAT.EQ.0) GOTO 999
IF(STR.EQ.’P’ ) THEN
CALL GPL ( 100, X , Y )
ELSE
CALL GPM ( 100, X , Y )
END IF
...
Jörg Bechlars, Rainer Buhtz

25. String-Request-Eingabe

Zusammenfassung
Im letzten Kapitel des Level 0b kommen wir nun noch einmal ausführlich auf eine Eingabeklasse zurück, die wir schon in Kapitel 19 bei der Einführung in die Eingabe mit GKS kennengelernt haben: den String.
Jörg Bechlars, Rainer Buhtz

Level 1b

Frontmatter

26. Pick-Request-Eingabe

Zusammenfassung
In diesem Kapitel wollen wir nun die entscheidenden Hilfsmittel kennenlernen, um interaktiv das bestehende Bild zu manipulieren. Unter Manipulation verstehen wir dabei nicht das Hinzufügen graphischer Information zum Bild, sondern etwa das Verschieben, Vergrößern oder Löschen von Bildteilen. Erinnern wir uns an die Diskussionen in Kapitel 15: Nur Segmente können manipuliert werden — und zwar nur als komplette Einheit. Daraus folgt, daß die Anwendungen, die in diesem Kapitel besprochen werden, nur mit einer GKS-Implementierung realisierbar sind, die auch Segmente unterstützt, also mindestens den Level lb realisiert. Bildmanipulation ist also in erster Linie das dynamische Ändern von Segmentattributen (Kapitel 17).
Jörg Bechlars, Rainer Buhtz

Levels 0c, 1c und 2c

Frontmatter

27. Sample-Eingabe

Zusammenfassung
Im SAMPLE und EVENT Mode — beide sind erst in den GKS-Levels 0c, lc und 2c verfügbar — hat man die Möglichkeit, unabhängig vom Programm Eingabewerte zu verändern und mit Hilfe des Echos diese Veränderungen auch beobachten zu können. Während im EVENT Mode (siehe folgendes Kapitel) der Bediener bestimmt, welcher Eingabewert dem Programm mitgeteilt wird, fragt im SAMPLE Mode das Anwendungsprogramm die aktuellen Eingabewerte ohne jeglichen Eingriff des Bedieners ab.
Jörg Bechlars, Rainer Buhtz

28. Event-Eingabe

Zusammenfassung
In beiden Betriebsarten Request und Event werden dem Anwendungsprogramm nur vom Bediener ausgewählte Eingabewerte mitgeteilt. Während allerdings im Request Mode das Anwendungsprogramm dem Bediener vorgibt, wann er welche Eingaben zu tätigen hat, läßt sich im Event Mode ein Programm so gestalten, daß der Bediener von sich aus jederzeit auf das Programm Einfluß nehmen kann. Daher braucht man sich nicht zu wundern, daß die heutzutage üblichen Benutzeroberflächen (X-Windows, Motif u.a.) Event-orientiert arbeiten. Bedient eine Anwendung mehrere Benutzer gleichzeitig, ist der Event Mode praktisch unverzichtbar.
Jörg Bechlars, Rainer Buhtz

Backmatter

Weitere Informationen