More Joy of GDOS^{∗} Version 2.9

Gerd Castan 06.05.1996

∗Deutsche Version gepostet in de.comp.sys.st und maus.gui.gem; englische Version in comp.sys.atari.st

Inhaltsverzeichnis

1 Technisches 6

2 Einleitung 6

3 Motivation 7

4 Änderungen 7

5 Briefe an die Leser 8 5.1 Programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2 Drucker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3 Bitmap-Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4 ISO-Modula-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.5 TOS 5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6 VDI-Treiber 9 6.1 Tintenstrahldrucker mit 150, 300 … dpi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2 Tintenstrahldrucker mit 180, 360 … dpi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3 9-Nadeldrucker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.4 24-Nadeldrucker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.5 Laserdrucker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.6 Atari - Laserdrucker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.7 Bildschirmtreiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6.7.1 LineA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.7.2 Setscreen und Getscreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.7.3 NVDI und WARP 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.8 Sonstige Treiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.8.1 Memory-Treiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.8.2 Plottertreiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.8.3 Druckertreiber für NVDI 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6.9 Was fehlt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7 Fehler 15

8 Fonts 16 8.1 Die Begriffe ”Font“ und ”Schnitt“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.2 Die Begriffe ”Format“ und ”Darstellung“ . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

9 Bitmap-Fonts 17

10 Vektorfonts 17 10.1 FSM-GDOS-Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.2 Bitstream Fontware-Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.3 Bitstream Speedo-Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.4 Type 1-Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

10.4.1 Multiple Master (MM) Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.4.2 Type 1-GX-Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

10.5 TrueType-Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.5.1 TrueType für Windows 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.5.2 TrueType GX-Fonts bzw. TrueType 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 20 10.5.3 TrueType für Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

10.6 Calamus-Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.7 Vergleich der Vektorformate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

10.7.1 Kurven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.7.2 Hints, instructions, switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.7.3 Interne Auflösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.7.4 Lineare und optische Skalierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

10.8 Konversion zwischen den Vektorfontformaten . . . . . . . . . . . . . . . . . . . . . . . . . 23

11 Drucker 23

12 Programme 24

13 Hilfsprogramme 26 13.1 fontfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 13.2 Outline Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 13.3 Druckertreiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13.4 ASSIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13.5 FONTCHK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13.6 FONTCNV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13.7 GEMFont . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13.8 FontMonger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.9 Font-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.10X4U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.11Charmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.12GDOS-Font . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.13REFONT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.14Arkus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

14 Fontselektoren 29 14.1 The quick brown fox. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 14.2 UFSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 14.3 XUFSL, HuGo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.4 Magic von Helli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.5 FontSel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.6 Weitere Fontselektoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.7 Minimalanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.8 Wünschenswerte Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

14.8.1 Attribute und Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.8.2 Fenster und Eventverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14.8.3 Verschiedenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

14.9 Über Dialoge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

15 Vertrieb 32 15.1 Atari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.2 BELA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.3 Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.4 Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.5 Working Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.6 X Window System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 15.7 COMPO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 15.8 IMG-0300 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 15.9 FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 15.10SciLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 15.11Star Division . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 15.12Thierry Rodolfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 15.13Sonstige . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

16 GDOS-Versionen 34

16.1 Die Fossile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 16.1.1 Atari-GDOS 1.X und AMCGDOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 16.1.2 ABC-GDOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 16.1.3 G+Plus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 16.1.4 G+Flair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

16.2 Ein Schritt nach vorne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 16.2.1 FontGDOS 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 16.2.2 FSMGDOS 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

16.3 Aktuelle Entwicklungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 16.3.1 SpeedoGDOS 4.0 und 4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 16.3.2 SpeedoGDOS 4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 16.3.3 SpeedoGDOS 5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 16.3.4 NVDI bis Version 2.51 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 16.3.5 NVDI 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 16.3.6 NVDI 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 16.3.7 NVDI 4.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

16.4 Kommentare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

17 Source 41

18 Tips und Tricks für Anwender 41 18.1 Pixelmüll beim Drucken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 18.2 NEC P6+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 18.3 HP DeskJet 550C, 560C und DeskWriter 510, 520 . . . . . . . . . . . . . . . . . . . . . . 42 18.4 Überschriebene Speedo-Schnitte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

19 Tips und Tricks für Programmierer 42 19.1 Fontgröße und Pixelgröße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 19.2 Treiberauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 19.3 Das Metafile-Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

20 Erweiterte Sub-Opcodes für Metafiles 45 20.1 Die unterstützten Sub-Opcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 20.2 Die Gruppeninformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 20.3 Der Objektschatten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 20.4 Die Füllfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 20.5 Der Vektortext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 20.6 Die Fenstereinstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

20.6.1 Fensterposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 20.6.2 Rastereinstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 20.6.3 Bezugsobjekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

20.7 Die Grautöne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 20.8 Bézier-Züge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 20.9 Zusammenfassen mehrerer VDI-Blöcke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

21 Standards 49 21.1 International Color Consortium Profile Format . . . . . . . . . . . . . . . . . . . . . . . . 49 21.2 TIFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 21.3 Character Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

21.3.1 Glyphen und Ligaturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 21.3.2 ascii, ISO 646 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 21.3.3 ISO 8859 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 21.3.4 UNICODE / ISO 10646 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

21.4 GEM-LIST-Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

22 Copyrights und Fonts 51 22.1 Bitstream-Fonts in Dokumenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 22.2 Urheberrecht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

22.3 Markenrecht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

23 Adressen 52

24 Sonstiges 55

24.1 Kritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

24.2 Lob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

24.3 In eigener Sache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

24.4 Warenzeichen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

24.5 Garantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Literaturverzeichnis 56

1 Technisches

Meine Mailadresse wird sich in absehbarer Zeit mehrmals ändern. Ich habe deshalb einen Alias, der die Mail dorthin weiterleitet, wo ich mich gerade aufhalte - und wenn es im Mausnet ist: G.Castan@physik.uni-stuttgart.de

Damit dieses Dokument auf Servern und Mailboxen leichter zu finden ist, bitte ich, einen einheitlichen Namen zu verwenden und sowohl die ascii- als auch die TEX-Version zu speichern: FILENAME = gdosi29 (deutsche Version) FILENAME = gdosi29e (englische Version) Auch wenn UNIX-Fileserver verwendet werden, sollte CR+LF und nicht nur LF verwendet werden.

Im WWW ist die deutsche Version (hoffentlich) immer unter http://www.uni-stuttgart.de/UNIuser/thphys/gerd/gdosi/gdosi.html. Diese Version ist nicht kopierbar, da sie absolute URLs enthält. Da Tabellen in GIFs umgewandelt werden, belegen die Files ausserdem über 2 MB.

2 Einleitung

Ich schreibe gerade an einem Programm, das seine Druckausgaben über GDOS macht. Auf der Suche nach Druckertreibern bin ich auf das Problem gestoßen, daß den Treibern oft keinerlei Dokumentation beiliegt.

Außerdem kommt es vor, daß es verschiedene Treiber mit gleichem Namen gibt. Aber worin unterscheiden sie sich?

Ich habe hier meine Erfahrungen zu GDOS knapp zusammengefaßt.

Diese Zusammenfassung soll nicht allgemein darauf eingehen, wie man als Programmierer Druckertreiber benutzt (Ausnahme sind vielleicht Probleme, die in der angegeben Literatur zu kurz kommen). Genausowenig wird hier das Konzept oder die Installation von Druckertreibern besprochen. Hier sei auf die Literatur am Ende verwiesen.

Vielmehr soll auf die einzelnen Treiber eingegangen werden:

• Wo bekommt man die Treiber, Programme und GDOS her?

• Wie unterscheidet man die verschiedenen Versionen?

• Welche Probleme gibt es damit?

• Welche Treiber kann man für bestimmte Drucker verwenden?

Wer zu einzelnen Treibern mehr Erfahrungen oder Fragen hat, der kann mir schreiben. Ich werde mir die Mühe machen, diese Zusammenfassung zu vervollständigen.

Mein Dank für sachdienliche Hinweise gilt folgenden Personen: Kay Prisille (MIGRAPH-Produkte, Calligrapher lite); Julian Reschke (IMG-0???); Volker Ritzhaupt; Jürgen Voorgang (Working Title - Produkte); Herwig Schelauske (Installation von GDOS, Namenskonventionen); Normen Kowalewski (Font-GDOS); Erik Dick (SpeedoGDOS); Patrick Dubbrow; Ulrich Roßgoderer (WYSIWYG); Stefan Hintz (CHARLY IMAGE); Ulli ”Huhu“ Ramps (Speedo 4.2); Laurenz Prüßner (SLM HS); Marcel Boom (1. Postkarte); Jörg Tochtenhagen (misc); Ralf Heckmann (Lektorat 8-); Andreas M. Köpfer (EASE, That’s write, MagiC!); Wilfried Behne (misc); Ulrich Kaiser (ABC-GDOS); Götz Hoffart (Noch ein Lektor); Thomas Künneth (G+Plus); Chris Ridd (G+Plus)

Gerd Castan.

3 Motivation

Es hat mich mit GDOS etwa zwei Stunden Programmierarbeit gekostet, die Bildschirmausgabe in meinem Programm in maximaler Qualität auf den Drucker zu bekommen. Und praktisch ohne zusätzlichen Aufwand erhalte ich Ausgaben auf Druckern, die ich überhaupt nicht kenne. Natürlich habe ich inzwischen deutlich mehr Zeit damit verbracht (unter anderem um dieses FAQ zu schreiben). Trotzdem sprechen viele Gründe für GDOS:

Wer vorhat, ein Programm mit Druckausgabe zu schreiben, tut gut daran, sich um die eigentlichen Aufgaben seines Programms zu kümmern.

Niemand ist bereit, für Druckertreiber mitzubezahlen, wenn es ein Konkurenzprogramm gibt, dessen Programmierer keinen Aufwand mit Druckertreibern haben und das Programm damit einfach billiger (und wahrscheinlich besser) ist.

Der Anwender hat neben dem Preisvorteil noch einen weiteren: Wenn er mehrere Programme hat, nehmen die Druckertreiber und Fonts nur einmal Platz auf der Platte weg.

Der (qualifizierte) Feedback zu meinem FAQ ist im Vergleich zu Herbst ’92, als ich damit begonnen habe, deutlich gestiegen. Durch Speedo scheint das Interesse der Programmierer an GDOS stark zugenommen zu haben.

4 Änderungen

Neue Kapitel/Infos sind mit + gekennzeichnet, geänderte mit *. Kleinere Änderungen sind nicht aufgeführt.

* 14.1 The quick brown fox

+ 22.2 Urheberrecht

+ 22.3 Markenrecht

* 16.3.6 NVDI 4.0

+ 16.3.7 NVDI 4.11

* [Beh95] nvdiguid enthält jetzt ein Patchprogramm, das kleinere Fehler aus NVDI 3.x und 4.x behebt.

* 10.7.4 Beispiel: Page vom Mai 1996 Seite 34 Die letzten Versionen: 2.4: 09.01.95 2.5: 21.02.95 2.6: 29.05.95 2.7: 17.08.95 2.8: 09.01.96 2.9: 06.05.96

5 Briefe an die Leser

Es hat sich als nicht sehr effektiv herausgestellt, mitten im Text auf Probleme aufmerksam zu machen. Ich möchte deshalb hier die Probleme zusammenfassen.

5.1 Programme

Die wenigsten der in 12 vorgestellten Programme besitze ich selbst. Ich kann auch nicht jedes Programm kennen, das irgendwo auf der Welt in eine Mailbox gelegt wird oder eine neue Versionsnummer hat. Die Programmierer sind also aufgefordert, Eigenwerbung zu treiben, und mir zu schreiben. Auch Anwendern nützt es, mir zu schreiben: wenn das Programm (durch die Erwähnung im FAQ) von mehr Personen benutzt wird, ist es wahrscheinlicher, daß es weiterentwickelt wird.

5.2 Drucker

Ich kann mir vorstellen, daß eine vollständige Tabelle in 11 sehr hilfreich bei der Suche nach einem Treiber für einen exotischen Drucker sein kann. Ich habe dazu aber bisher nur 2 konstruktive Mails bekommen. Und so wie die Tabelle zur Zeit aussieht, ist sie überflüssig. Soll ich sie rauswerfen?

5.3 Bitmap-Fonts

Ich habe eine Mail mit einer sehr ausführlichen Beschreibung des GDOS Bitmapfontformates erhalten. Die Veröffentlichung im FAQ habe ich aber abgelehnt, weil das auf der ganzen Welt nur von den ca. 3 Autoren von Fonteditoren und Fontkonvertern gebraucht wird. Wer anderer Meinung ist, soll mich vom Gegenteil überzeugen. Es sind ca 13 kB.

5.4 ISO-Modula-2

Ich wurde gebeten, folgende Anfrage zu veröffentlichen:

Gesucht: Portierung eines 100 % ISO-Modula-Compilers (mit Oberon-Erweiterung) eines englischen Herstellers (bisher portiert für UNIX, Mac, Windows, Amiga).

Profil: Informatiker mit Interesse an Compiler(bau). Erfahrung mit ANSI-C erforderlich, da der Quelltext in ANSI-C vorliegt. Englische Sprachkenntnisse (für email und doku). Internet-Zugang (für email und ftp)

Die Portierung läuft wahrscheinlich ohne kommerziellen Hintergrund (aber non-disclosure agreement) ab. Sie sollte den ATARIanern als Shareware zur Verfügung gestellt werden.

Kontakt: Gerd Castan (G.Castan@physik.uni-stuttgart.de)

5.5 TOS 5.0

Wer Lust hat gegen Bezahlung - und auch die nötige Ahnung hat - am TOS 4.9x mitzuarbeiten, der melde sich bei:

C-Lab Digital Media GmbH Postfach 700 303 22003 Hamburg

Tel-Nr.: 040-69 44 000

6 VDI-Treiber

Hier werden zu jedem Treiber Vertrieb, Fehler und zugehörige Fonts aufgelistet.

Die Treiber für NVDI 3 sind separat in 6.8.3 aufgestellt.

6.1 Tintenstrahldrucker mit 150, 300 … dpi

Name  Datum Länge Vertrieb  Fehler Sonst. Fonts
1 2
HP LJET 22.02.89 45512 BELA n.g. LS
HP LASER 25.09.89 36928 Atari,I  LS
LASERJET 06.03.91 54517 Atari  LS
LASERJET 27.01.92 60194 FontGDOS,I  n  LS, OTL
LASERJET 28.01.93 61907 SGDOS 4.0  n  LS, SPD
LASERJET 02.07.93 64408 SGDOS 4.2  n  LS,SPD,TT,T1
HPL150  12.04.86 51541 wt  150dpi LL
HPL300  24.04.86 51541 CL,wt  LS
DESKJET 13.05.92 45637 BELA  g.  LS?
DESKJET 14.05.91 46040 CL,WT  g.  300x600
DESKJET 06.03.91 54285 Atari,I  LS?
DESKJET ?  45618 ?  g.  LS
DESKJET ?  45285 ?  g.  LS
DESKJET5 14.05.91 46040 CL,WT  delta LS
DJ5  27.01.92 60600 FontGDOS,I  n  OTL
DJ5  ?  60538 ?
DJ5  28.01.93 62251 SGDOS 4.0  n  SPD
DJ5  02.07.93 64319 SGDOS 4.2  n  SPD,TT,T1
DJ550C  11.10.93 68870 SGDOS 5.0  n  LS,SPD,TT,T1
DJ550C  11.10.93 68870 T.R.  n  LS,SPD,TT,T1
DJ 550C2  14.04.94 68746 SGDOS 5.0  n  LS,SPD,TT,T1
DJ 500C  14.04.94 68761 SGDOS 5.0  n  LS,SPD,TT,T1
DJ 510  17.05.94 61921 SGDOS 5.0  n  LS,SPD,TT,T1
DJ 510T  17.05.94 61925 SGDOS 5.0  n  LS,SPD,TT,T1

Anmerkung: Die Treiber HP LJET und DESKJET können sowohl für (HP-kompatible) Tintenstrahl- als auch Laserdrucker verwendet werden. Der Unterschied besteht darin, daß die Daten gepackt (g.) oder nicht gepackt (n.g.) an den Drucker geschickt werden. delta bedeutet, daß die Daten delta-komprimiert werden.

6.2 Tintenstrahldrucker mit 180, 360 … dpi

Name  Datum Länge Vertrieb  Fehler Sonst. Fonts
1 2
BJ10E  20.11.90 45917 WT  NC
BJ10  20.11.85 45919 CL  NC
BJ10  28.08.91 45660 BELA  NC
BJ10  27.01.92 59715 FontGDOS,I  n  NC, OTL
BJ10  28.01.93 61428 SGDOS 4.0  n  NC, SPD
BJ10  02.07.93 63496 SGDOS 4.2  n  NC,SPD,TT,T1
STYLUS  25.04.94 60848 SGDOS 5.0  n  NC,SPD,TT,T1
MT90  21.12.90 44881 BELA  180dpi SP
PAINTJET 27.01.92 60005 FontGDOS  n  SP, OTL
PAINTJET ?  60173  SP
PAINTJET 28.01.93 61648 SGDOS 4.0  n  SP, SPD
PAINTJET 02.07.93 63642 SGDOS 4.2  n  SP,SPD,TT,T1
PAINTJET 14.08.92 60173 I  SP, OTL
PAINTJET 13.10.91 45934 WT  SP

Anmerkung: PAINTJET: 180x180: 2 bis 8 Farben, 90x90: 16 Farben. MT90 ist von Patrick Dubbrow. Bei Tintenstrahldruckern tritt ein Problem mit Bitmap-Fonts auf. Bei 300 dpi ist alles in Ordnung. 360 dpi - Fonts sind aber so optimiert, daß sie auf Nadeldruckern mit dicken Nadeln optimal aussehen. Auf Tintenstrahldruckern sehen diese Fonts viel zu dünn aus. Also entweder 300 (600, 1200 :-)) dpi-Drucker oder ausschließlich Vektorfonts verwenden.

6.3 9-Nadeldrucker

Name  Datum Länge Vertrieb  Fehler Sonst. Fonts
1 2
FX240DPI 22.12.89 45396 BELA  j  SR
FX80  22.12.89 45396 BELA,wt  n  EP
FX80 2  12.06.91 45396 I  EP
FX80  24.09.91 45525 CL  EP
FX80  16.12.87 45396 Atari  n  EP
FX80  27.01.92 59236 FontGDOS,I n n  FF EP, OTL
FX80  28.01.93 61111 SGDOS 4.0  n  EP, SPD
FX80  02.07.93 63177 SGDOS 4.2  n  EP,SPD,TT,T1
FX80HIGH 22.01.89 44730 Atari,I  n  SR
FX80 QD 24.09.91 45525 WT  EP
NX1000  27.01.92 58719 FontGDOS n n  EP, OTL
NX1000  28.01.93 60723 SGDOS 4.0  n  EP, SPD
NX1000  02.07.93 62717 SGDOS 4.2  n  EP,SPD,TT,T1
NX1000  14.08.92 58887 I  EP, OTL
OKI20  27.01.92 58491 FontGDOS n n  EP, OTL
OKI20  28.01.93 60495 SGDOS 4.0  n  EP, SPD
OKI20  17.03.93 60511 SGDOS 4.2  n  EP,SPD,TT,T1
OKI20  14.08.92 58659 I  EP, OTL
SMM804  16.12.87 44801 Atari  LB
SMM804 2 16.06.91 44801 I  LB
SMM804  27.01.92 59201 FontGDOS,I  n  LB, OTL
SMM804  28.01.93 61076 SGDOS 4.0  n  LB, SPD
SMM804  02.07.93 63142 SGDOS 4.2  n  LB,SPD,TT,T1

6 VDI-TREIBER 11 Anmerkung: FX80HIGH druckt normalen Text doppelt, FX240DPI nur einfach, FX80 QD druckt in vierfacher Dichte. NX1000 und OKI20 sind Farbtreiber mit 8 Farben.

6.4 24-Nadeldrucker

Name  Datum Länge Vertrieb  Fehler Sonst. Fonts
1 2
EPSON360 04.04.90 45619 BELA j NC
EPSON360 16.09.92 45547 WT  180x360
EPSLQPAR 14.02.91 44939 I
LQ 500  15.11.93 68068 T.R.  n  SP,SPD,TT,T1
LQ570  28.01.93 62051 SGDOS 4.0  n  SPD
LQ570  02.07.93 64228 SGDOS 4.2  n  SPD,TT,T1
LQ 800  15.11.93 68068 T.R.  n  SP,SPD,TT,T1
LQ 850  15.11.93 68068 SGDOS 5.0  n  SP,SPD,TT,T1
LQ 850  15.11.93 68068 T.R.  n  SP,SPD,TT,T1
LQ 1000  15.11.93 68068 T.R.  n  SP,SPD,TT,T1
LQ 1050  15.11.93 68068 T.R.  n  SP,SPD,TT,T1
LX800  14.11.93 67989 T.R.  n  SP,SPD,TT,T1
NB15  22.12.89 44881 BELA,wt  n  SP
NB15  16.12.87 44881 Atari,CL  n  SP
NB15 2  12.06.91 44881 I  SP
NB15  27.01.92 59121 FontGDOS,I n n  SP, OTL
NB15  28.01.93 60989 SGDOS 4.0 n n  SP, SPD
NB15  02.07.93 63055 SGDOS 4.2 n n  SP,SPD,TT,T1
NECP6  12.04.80 45199 wt  NC
NECP6  10.04.91 45619 BELA  j  NC
NECP6  06.02.86 44906 Atari,I  j  NC
NECP6 2  28.06.91 46557 I  NC
NECP  27.01.92 59516 FontGDOS j n  NC, OTL
NECP  28.01.93 61229 SGDOS 4.0  n  NC, SPD
NECP  02.07.93 63297 SGDOS 4.2  n  NC,SPD,TT,T1
NEC P  14.08.92 59516 I  NC, OTL
P24M  08.04.89 47104 I
P24ML  08.04.89 47104 I
P24MWID 08.04.89 47104 I
P24MWIDL 08.04.89 47104 I

6.5 Laserdrucker

Name  Datum Länge Vertrieb  Fehler Sonst. Fonts
1 2
RICOH12  23.06.92 45438 WT  400dpi
HP LJET  22.02.89 45512 BELA  n.g. LS
HP LASER 25.09.89 36928 Atari,I  LS
LASERJET 06.03.91 54517 Atari  LS
LASERJET 27.01.92 60194 FontGDOS,I  n  LS, OTL
LASERJET 28.01.93 61907 SGDOS 4.0  n  LS, SPD
LASERJET 02.07.93 64408 SGDOS 4.2  n  LS,SPD,TT,T1
HPL150  12.04.86 51541 wt  150dpi LL
HPL300  24.04.86 51541 CL,wt  LS
LJ4 300  12.01.94 61910 SGDOS 5.0  n  LS,SPD,TT,T1
LJ4 600  12.01.94 61910 SGDOS 5.0  n  SPD,TT,T1
DESKJET  13.05.92 45637 BELA  g.  LS
DESKJET  14.05.91 46040 CL  LS
DESKJET  06.03.91 54285 Atari,I  LS
CANONLBP 26.09.89 36980 Atari,I  LS
LBP  13.01.92 45453 WT  LS

6.6 Atari - Laserdrucker

Name  Datum Länge Vertrieb  Fehler Sonst. Fonts
1 2
SLM804 12.04.91 47496 BELA  n  LS
SLM804 16.12.87 45788 Atari,I,CL,wt  j  LS
SLM  12.12.90 48399 Language  LS
SLM  27.01.92 60036 FontGDOS,I  n  LS, OTL
SLM  28.01.93 61911 SGDOS 4.0  n  LS, SPD
SLM  02.07.93 63987 SGDOS 4.2  n  LS,SPD,TT,T1
SLM HS 17.01.94 63663 ROM  n  LS, SPD

SLM HS ist ein SLM-Treiber für den Falcon.

6.7 Bildschirmtreiber

Der Bildschirm wird (falls man die VDI-Funktionen benutzt) genauso als Ausgabegerät angesehen wie Drucker, Plotter etc. Daher können in der ASSIGN.SYS Fonts für den Bildschirm angemeldet werden wie für Drucker.

Normalerweise merkt man davon nichts, da sich die Treiber im ROM befinden. Diese können aber wie die Druckertreiber ersetzt werden (NVDI, WARP 9).

Anmerkung: Als Systemfont kann man bisher nur Fonts anmelden, die (wie die Originale) nicht proportional sind und eine Größe von 8*8 bzw. 8*16 Bits haben. Das ist keine Einschränkung des VDI, sondern der AES.

Mit neueren AES (ab 4.0?) ist es inzwischen kein Problem mehr, hier Fonts beliebiger Größe anzumelden (Variablen AE FONTID und AE FONTSIZE in der Datei GEM.CNF, siehe [Sche93]). Programmierer sollten darauf achten, daß ihre Programme damit zurechtkommen (ebenso wie mit beliebig breiten Scrollbalken).

Bitmap-Fonts, die für den Bildschirmtreiber 1 nicht angemeldet sind, stehen auch für die anderen Bildschirmtreiber nicht zur Verfügung.

6.7.1 LineA

Die sogenannten LineA-Routinen sind Unterprogramme der Bildschirmtreiber der ST-Serie, die als undokumentiert zu betrachten sind. Es handelt sich dabei um den hardwareabhängigen Teil dieser Treiber.

Der aufmerksame Leser ahnt es: tauscht man die Bildschirmtreiber aus, gibt es auch die LineA-Routinen nicht mehr. Dies ist beispielsweise bei den TTs der Fall.

Also niemals verwenden!

Auf die LineA-Variablen darf lesend zugegriffen werden. Ich sehe darin aber wenig Sinn.

6.7.2 Setscreen und Getscreen

Diese XBIOS-Funktionen (vor allem Setscreen) sollten eigentlich nicht verwendet werden.

Aber was rede ich. Für die, die’s trotzdem tun oder darunter zu leiden haben, daß es jemand getan hat:

Die Videohardware des 1040 STE und Mega STE hat einen Hardwarefehler. Wird mit Setscreen eine neue physBase angegeben (und wenn es dieselbe ist, die man mit Getscreen bekommen hat), kann es vorkommen, daß der Bildschirm gefaltet wird. Ursache dafür ist, daß damit zu einem beliebigen Zeitpunkt ein Register beschrieben wird, welches nur während bestimmter Phasen des Bildschirmaufbaus beschrieben werden darf.

Was ist zu tun?

Anwender: Die Programme NVDI und FALT OFF fangen diesen Fehler ab. Es hilft auch dem Programmierer dieses FAQ unter die Nase halten.

Programmierer: Setscreen erst gar nicht verwenden. Wer es trotzdem tut: falls physBase nicht verändert wird, darf nicht der Wert genommen werden, der mit Getscreen geholt wurde, sondern es ist der Wert -1 als physBase zu übergeben.

6.7.3 NVDI und WARP 9

Es gibt zwei verbreitete Programme, die die ROM-Treiber ersetzen: NVDI und WARP 9 (vormals QuickST). TurboST wurde früher von BELA vertrieben und wird nicht mehr weiterentwickelt.

Hat man sich erst einmal daran gewöhnt, will man nie wieder ohne leben: die Benutzeroberfläche kommt einem sonst zäh wie Honig vor. Ich will nie wieder ohne NVDI an einem Atari arbeiten. Andere behaupten dasselbe von WARP 9.

Bei NVDI werden die Treiber für die ST- und TT- und Falcon-Auflösungen durch stark optimierte Treiber ersetzt. Welche Treiber WARP 9 ersetzt, weiß ich leider nicht.

NVDI gibt es bei Behne&Behne und enthält neben den Treibern auch ein GDOS und ein Handbuch, das alle VDI-Aufrufe genau beschreibt. Seit Version 3.0 sind die VDI-Aufrufe nicht mehr im Handbuch enthalten.

WARP 9 gibt es bei CodeHead.

NVDI ist vor allem in Deutschland verbreitet, WARP 9 vor allem in den USA.

Im Gegensatz zu NVDI beschleunigt WARP 9 nur die Textausgabe. Graphik bleibt mit WARP 9 also fast so zäh wie vorher. WARP 9 arbeitet inzwischen auch mit MultiTOS zusammen. Es läuft auch auf dem Falcon, ich weiß aber nicht, ob es dabei auch alle Auflösungen unterstützt.

6.8 Sonstige Treiber

Name  Datum Länge Vertrieb  Fehler  Sonst.  Fonts
1 2
META  11.04.89 5644 I  MF
META  08.10.88 9325 BELA  MF
META  16.12.87 9325 Atari  MF
META 2  14.06.91 9325 I  MF
META  27.01.92 9718 FontGDOS  n  MF, OTL
META  28.01.93 9733 SGDOS 4.0  n  MF, SPD
META  02.07.93 11174 SGDOS 4.2  n  MF,SPD,TT,T1
MEMORY  27.01.92 58397 FontGDOS  n  LS, OTL
MEMORY  28.01.93 60265 SGDOS 4.0  n  LS, SPD
MEMORY  02.07.93 62331 SGDOS 4.2  n  LS,SPD,TT,T1
MEMORY 2 10.10.94 67274 T.R.  n  LS,SPD,TT,T1
CYPRESS  MEMORY
PSCRIPT  14.10.92 33016 WT
HPGL 08.07.91 48885 ST458 V 1.4r2
ZEBRA  07.12.91 45746 WT
T OFFICE  wt  98/196dpi
T OFFICE  wt  98/196dpi SPD
IMG-0300  Reschke,wt n  LS

IMG-0300 kann (nicht kommerziell) frei kopiert werden. Die anderen IMG-0???-Treiber sind von SciLab. ZEBRA ist für den Zebra Labelprinter.

6.8.1 Memory-Treiber

Ein Memory-Treiber macht nichts anderes als ein Bildschirmtreiber (siehe auch [Pru93c] und [Pru93b]). Nur landet das Ergebnis nicht im Bildschirmspeicher, sondern in einem anderen Speicher und kann von dort weiterverarbeitet werden.

Das übliche v openwk Binding hat nicht alle nötigen Parameter, um diesen Treiber zu öffnen. Falls nicht mit der Programmiersprache mitgeliefert, muß man dieses Binding selbst schreiben. Ein Listing dazu findet sich in [Pru93c].

Die oben aufgeführten Memory-Treiber können nur schwarz/weiß ausgeben und haben eine logische Auflösung von 300 dpi. Die von mir getesteten (Matrix-) Treiber verkraften es problemlos, wenn man Fonts anmeldet, die eigentlich für andere Treiber sind. Der Memory-Treiber sollte deshalb trotz der logischen Auflösung von 300 dpi auch mit Bildschirm-Fonts zurechtkommen.

Problematisch ist aber, daß die Aspect-Ration (das Verhältnis von Pixelbreite zu Pixelhöhe) im allgemeinen nicht mit der Bildschirmauflösung übereinstimmt. Das hat zur Folge, daß beispielsweise Kreise als Ellipsen dargestellt werden.

Mit NVDI ab Version 2.5 kann man die Ausgaben auch auf offscreen-Bitmaps machen. Man kann dort beliebige GDOS-Ausgaben machen und das Ergebnis dann gegebenenfalls in die Fenster des Bildschirms kopieren.

6.8.2 Plottertreiber

Mit dem Programm DATA scheint ein HPGL-Treiber vertrieben zu werden. Auch auf der PD-Diskette ST 458 befindet ein solcher Treiber. Wenn ich genaueres weiß, folgt an dieser Stelle mehr.

6.8.3 Druckertreiber für NVDI 3.0

NVDI 3.0 hat ein eigenes Treiberkonzept. Zu NVDI gehören sehr wenige Treiber, die aber sehr schnell, sehr klein und sehr flexibel sind.

Die Treiber im einzelnen:

Treiber  Datum
PINPRN.SYS  19.10.94
PAGEPRN.SYS 19.10.94
IMG.SYS  30.10.94
MEMORY.SYS 18.10.94
META.SYS  18.10.94
ATARILS.SYS 18.10.94

Zu jedem Treiber gehört ein .INF-File im GEMSYS-Ordner.

Je nach Farbfähigkeit des Druckers (einstellbar in MAKEPRN.APP) sollen die Druckertreiber andere Offsreen-Treiber zum Aufbau der Graphik verwenden (solche Kleinigkeiten stehen natürlich nicht im Handbuch).

Die Offscreen-Treiber:

Treiber  Datum Farben
OFF002.NOD  06.11.94 2
OFF004IP.NOD 06.11.94 4
OFF016IP.NOD 06.11.94 16
OFF256IP.NOD 06.11.94 256
OFF32KFL.NOD 06.11.94 32768

Sehr lobenswert ist die Flexibilität beim Anpassen an neue Drucker. Bei SpeedoGDOS braucht man einen Gewerbeschein und viel Geld, um sich als Entwickler eintragen zu lassen, um dann mit hohem Aufwand in C einen Treiber zu programmieren. Bei NVDI braucht man dagegen nur mit MAKEPRN.APP die Steuercodes für seinen Drucker einzugeben. Es ist also lediglich ein intensives Studium des Druckerhandbuchs notwendig, keine Programmierfähigkeiten.

Diese Steuercodes werden in den .INF-Dateien der jeweiligen Treiber gespeichert. Ein Wermutstropfen: man kann die Druckeranpassungen nicht einfach austauschen, da weder das Format der .INF-Dateien dokumentiert ist, noch ein Programm existiert, mit dem man die Anpassungen extrahieren oder hinzufügen kann. Lediglich ein kompletter Austausch der .INF-Dateien ist möglich. Einzige Lösung zur Zeit: die komplette .INF-Datei an 2B schicken.

Ein weiteres Problem, das im Handbuch nicht einmal erwähnt ist, besteht beim Anmelden von Bitmap-Fonts in der ASSIGN.SYS. Nehmen wir an, es seien für den PINPRN.SYS 180 dpi-Fonts angemeldet. Jetzt kann man leicht mit Hilfe des CPX auf 360 dpi schalten. Der Ausdruck wird dann aber katastrofürchterlich.

Des Rätsels Lösung: Es ist die Datei PINPRN.SYS ein zweites Mal unter anderem Namen (z.B. PIN-PRN2.SYS) in dem GEMSYS-Ordner zu kopieren. Dieser Treiber kann dann auch in der ASSIGN.SYS angemeldet werden, diesmal aber mit Fonts anderer Auflösung.

Fazit: Die Treiber sind konzeptionell wesentlich besser als die von SpeedoGDOS 5.0.

6.9 Was fehlt

Sind alle wunschlos glücklich?

7 Fehler

Mir bekannte Fehler der Druckertreiber sind:

1 Diese Treiber stellen auch Fonts mit dem Attribut hell ausgefüllt dar.

2 Nicht auf dem TT lauffähig.

3 Die EXTENDED ENQUIRE FUNCTION (VDI 102, vq extnd) liefert teilweise nicht die Werte zurück, wie sie beispielsweise im Profibuch dokumentiert sind.

4 Bei der Kombination der Attribute kursiv und outlined werden die Buchstaben von Bitmap-Fonts rechts abgeschnitten. Dieser Fehler ist unabhängig davon, welche Attribute sonst noch gesetzt werden. Er war in den Libraries der Treiber-Sourcen von Atari und ist damit wahrscheinlich in allen Treibern bis auf NVDI und SpeedoGDOS enthalten.

Steht in der Tabelle nichts über einen Fehler, so ist mir nicht bekannt, ob der Fehler auftritt, oder nicht.

Es scheint kein Zufall zu sein, daß Xact nur die Attribute fett, kursiv und unterstrichen unterstützt. (Siehe auch [Res92])

Ein weiterer Grund, der gegen die Verwendung der Attributs outlined spricht, ist folgender: Wenn man einen Treiber dazu zwingt, einen outlined- Font aus einem normalen Font zu berechnen, wird er grob gesagt um zwei Pixel breiter. Da ein Pixel (im Gegensatz zu einem angepaßten Font) eine auflösungsabhängige Breite hat, ist ein Text in jeder Auflösung unterschiedlich breit. Es ist aber völlig unerwünscht, wenn ein Text auf unterschiedlichen Druckern eine unterschiedliche Breite hat. Die einzige Methode, dem entgegenzuwirken, wäre Letterspacing. Das aber ist typographischer Pfusch.

8 Fonts

8.1 Die Begriffe ”Font“ und ”Schnitt“

Zunächst: was ist der Unterschied zwischen einem Font und einem Schnitt (englisch: face)?

Ruft man einen Fontselektor auf, sieht man beispielsweise Dutch 801 Roman, Dutch 801 Italic, Dutch 801 Bold, Dutch 801 Bold Italic. In diesem Fall haben wir 4 Schnitte, die zusammen einen Font bilden.

Bei Bitmap-Fonts ist die Trennung nicht ganz so einfach, weil die ganzen Attribute aus einer Datei berechnet werden. (Diese Berechnung ist im Prinzip auch bei Vektorfonts möglich, aber meiner bescheidenen Meinung nach Unsinn. Deshalb ist mir auch nicht selbst aufgefallen, daß diese Berechnung der Attribute bei einigen SpeedoGDOS-Versionen fehlerhaft ist, siehe auch 16.3.3.)

Bei Vektorformaten verwischt sich die Grenze mit den Multiple Master Fonts (siehe 10.4.1) und den TrueType GX Fonts (siehe 10.5.2) ebenfalls.

Auch ich halte die Trennung zwischen Font und Schnitt in diesem FAQ nicht ganz sauber durch. Das gilt insbesondere in diesem Kapitel über Fontformate (den Ausdruck Schnittformat gibt es nicht, und es hört sich seltsam an, wenn man sagt ”Diese Schnitte sind in jenem Fontformat gespeichert.“).

8.2 Die Begriffe ”Format“ und ”Darstellung“

Der Begriff ”Format“ wird im Zusammenhang mit Fonts doppelt verwendet, was doch etwas zu Konfusionen führt.

Einerseits unterscheidet man beispielsweise das TrueType-Format vom Type 1-Format (und anderen). Gleichzeitig unterscheidet man bei beiden noch einmal zwischen dem Macintosh-Format und dem Windows-Format (und anderen).

Um diese Verwirrung aufzulösen, definiere ich fuer dieses FAQ:

• Um zwischen TrueType, Type 1, Speedo… zu unterscheiden, verwenden wir weiterhin den Begriff Format • Um zwischen den Dateiformaten zu unterscheiden, verwenden wir den Begriff Darstellung (engl:

Representation). Dieser Begriff wird in Mathematik und Physik verwendet, wenn Gruppen zwar unterschiedlich aussehen, sich aber trotzdem samt Struktur bijektiv aufeinander abbilden lassen.

Dann läßt sich auch der etwas verwirrende Umstand, daß es das TrueType 1.0-Format (für Macintoshs) und das TrueType für Windows-Format sowohl in der Macintosh- als auch in der Windows-Darstellung gibt: Macintosh TrueType-Format in der Macintosh-Darstellung, Macintosh TrueType-Format in der Windows-Darstellung, TrueType für Windows-Format in der Macintosh-Darstellung, TrueType für Windows-Format in der Windows-Darstellung.

Es läßt sich dann auch einfacher ausdrücken, daß SpeedoGDOS 5.0 und NVDI 3.0 die Windows-Darstel-lung brauchen, unabhängig davon, ob es das Windows- oder Macintosh-Format ist.

9 Bitmap-Fonts

Die verwendeten Fonts sind Bitmap-Fonts im DR-Standardformat. Die Fonts müssen in der Intel-Darstellung gespeichert sein. Die Motorola-Darstellung wird von keinem GDOS unterstützt (siehe auch [Whe88] und Anhang).

Bei den GDOS-Bitmap-Fonts sind die Breiteninformationen sowohl im Bildschirmzeichensatz als auch in den Druckerzeichensätzen definiert. Leider waren die Fontdesigner etwas übereifrig und haben die Breite der Bildschirmzeichen vieler Fonts so angepaßt, daß sie besonders schön aussehen. Damit sind sie zwar schön, stimmen aber nicht mit den Druckerzeichensätzen überein und erlauben kein WYSIWYG.

Im Internet kursieren jede Menge Fonts, die nur für den Bildschirm und vielleicht noch für einen Drucker geeignet sind. Jeder, der diese Fonts verwendet, muß sich darüber im klaren sein, daß er Dokumente mit diesen Fonts niemals sauber über GDOS ausdrucken können wird.

Dagegen werden im Atari- und im BELA-Paket die jeweiligen Fonts für alle Druckertreiber des jeweiligen Pakets mitgeliefert (Im Atari-Paket fehlen die 360x360dpi-Fonts). Man kann dann - ein geeignetes Programm vorausgesetzt - jedes Dokument mit jedem Druckertreiber ausdrucken.

10 Vektorfonts

Vektorfonts enthalten keine einzelnen Pixel, sondern Algorithmen, die mit Hilfe von Umrissen und Hints das Aussehen von Zeichen beschreiben. Weil es sich um Algorithmen handelt (besonders schön bei zu beobachten), sind die Fonts im Gegensatz zu Bitmapfonts wie normale Programme durch Copyrights geschützt. Vergleiche dazu auch [Walsh].

Im folgenden kommt einiges an Hintergrundwissen über Vektorformate. Weshalb sollte sich aber der geneigte Leser die Mühe machen, das zu verinnerlichen? Schließlich kaufen wir für ein paar Mark eine Font-CD, wählen die 17 interessantesten Fonts für unser erstes Plakat aus und drucken das Ergebnis dann aus.

Die Probleme sind: Ich habe ein und denselben Schnitt in mehreren Formaten. Welchen soll ich nehmen? Manchmal habe ich nur beim Drucken, manchmal nur auf dem Bildschirm und manchmal nur bei bestimmten Größen Probleme. Warum?

Wer allerdings 17 Garamond-Schnitte von 17 Herstellern hat, sollte eher Zeitschriften wie die Page lesen, um zu wissen, welche er nehmen soll.

10.1 FSM-GDOS-Fonts

Die Vektorfonts im alten FSM-GDOS-Format der QMS/Imagen Corp. werden hier mit OTL bezeichnet.

Diese Fonts und Treiber sollten nicht mehr benutzt werden und sind hier nur der Vollständigkeit halber aufgeführt.

10.2 Bitstream Fontware-Fonts

Um eine Konfusion zu vermeiden sei erwähnt, daß es von Bitstream noch das Fontware-Format gibt, das beispielsweise keine Hints beherrscht.

Dieses Format hat nichts mit den hier besprochenen GDOS-Fontformaten zu tun.

10.3 Bitstream Speedo-Fonts

Die Vektorfonts im Speedo-Format der Firma Bitstream werden hier mit SPD bezeichnet.

Sie werden von allen SpeedoGDOS-Versionen und von NVDI ab Version 3.0 unterstützt.

Manche Schnitte von Bitstream haben ”BT“ im Namen, andere ”SWA“. BT steht für ”Bitstream Type“, ”SWA“ für ”Set Width Adjusted“. Die SWA-Schnitte unterscheiden sich im Design der Zeichen nicht von den korresponierenden Schnitten ohne SWA. Lediglich der Zeichenabstand ist verändert, damit die Bildschirmdarstellung mit den eingebauten Schnitten spezieller Drucker übereinstimmt. Es ist also sinnvoll, die SWA-Schnitte nur dann zu verwenden, wenn man tatsächlich einen solchen Drucker hat und weis̈, das̈ der Schnitt von dem Drucker mit dem druckereigenen Zeichensatz gedruckt wird. Das ist unter GDOS aber nie der Fall.

10.4 Type 1-Fonts

Type 1-Fonts gibt es in Macintosh- und MS-DOS/WINDOWS-Darstellung. Die Versionen unterscheiden sich nur in der internen Darstellung, nicht in der Information.

Mindestens eines dieser Formate wird von SpeedoGDOS ab Version 5.0a unterstützt. Ich habe allerdings schon Schnitte gefunden, die von SpeedoGDOS 5.0a nicht dargestellt werden können.

Eine Anmerkung am Rande: Es ist ein Irrtum anzunehmen, PS-Interpreter würden Type 1-Fonts verwenden, nur weil der Original PS-Interpreter von Adobe dies tut. Ein PS-Interpreter verwendet das Fontformat, das der Hersteller des Interpreters will. Nur auf eines kann man sich ziemlich sicher verlassen: ein PS-Dokument sieht auf dem Bildschirm anders aus als auf dem Drucker.

10.4.1 Multiple Master (MM) Fonts

ATM (Adobe Type Manager) 3.01 für Windows beherrscht jetzt zusätzlich Multiple Master Fonts, eine Erweiterung des Type 1-Formats. Mit dieser Technologie lassen sich nicht nur Höhe, Breite, Neigungswinkel und Rotation bei der Ausgabe angeben, man hat zusätzliche kontinuierliche Parameter, mit denen man aus verschiedenen Designachsen auswählt. Eine Designachse könnte von leicht nach fett gehen, eine weitere von serif nach sans-serif. Dies ist nicht ein einfacher Algorithmus, wie sonst bei GDOS, sondern der Fontdesigner bestimmt, wie und wo sich ein Schnitt verändert, wenn er fetter oder leichter wird. Der Fontdesigner bestimmt auch, welche Designachsen es gibt.

Dieser Abschnitt dient nur zur Bildung. SpeedoGDOS 5.0 beherrscht nur normale Type 1-Fonts und NVDI 3.0 gar keine.

Wenn man sich in [Hil95] die URW PrintWorks-CD anschaut, merkt man, daß URW intern eine solche Technologie auch besitzt. Vergl. auch [Kar92a]. Dieses hochinteressante Buch ist auch von URW.

Diese MM-Fonts sind doch eine Erweiterung des Type 1-Formats? Genau.

Unter Windows kann ich jetzt MM Fonts verwenden, aber was mache ich mit meinem alten Postscipt-Drucker? Kein Problem, der kann das trotzdem. Wie das? Ich habe doch schon erwähnt, daß Vektorfonts eigentlich Algorithmen darstellen. Adobe hat einfach einen neuen Operator definiert. Den beherrscht mein alter Postscript-Drucker doch nicht. Richtig. Man kann die Definition des Operators aber auch im Font selbst mitliefern. So wird das zur Zeit auch gemacht. Deshalb können das auch die alten Postscript-Drucker. Dann kann das aber auch der Scaler meines SpeedoGDOS, oder? Eben. Man müßte nur die Programmierschnittstelle anpassen. Aus diesem Grund gibt es auch für Windows eine neue ATM-Version. Super! Dann bräuchte ich auch nicht mehr 50 Schnitte pro Font kaufen. Und für ein Eis reicht dein Geld dann auch noch ;-)

Die MM-Technologie ist insofern nicht der Weisheit letzter Schus̈, als nur ein linearer Übergang zwischen extremschnitten möglich ist. Ein nichtlinearer Übergang wäre noch interessanter.

Der erste MM-Font überhaupt ist die Groteskschrift Myriad von Carol Twombly und Robert Slimbach.

10.4.2 Type 1-GX-Fonts

Diese Fonts haben die selben Fähigkeiten wie TrueType-GX-Fonts. Warum das so ist, steht in 10.5.2

10.5 TrueType-Fonts

Auch dieses Format gibt es in Macintosh- und MS-DOS/WINDOWS-Darstellung.

SpeedoGDOS ab Version 5.0a und NVDI ab Version 3.0 verarbeiten dieses Format unabhängig davon, ob es für Macintosh oder MS-DOS/WINDOWS ist. Das Microsoft-Format ist ein Superset des Apple-Formats.

Apple hat dieses Fontformat so definiert, daß es aus verschiedenen Tabellen besteht (etwa wie die Chunks im IFF-Format). Diese Tabellen haben im Header einen Namen und eine Länge eingetragen, so daß Programme und Scaler unbekannte Tabellen einfach überspringen können. Wer neue Tabellen definiert, muß diese bei Apple anmelden. Apple hat definiert, welche Tabellen im TrueType-Format vorhanden sein müssen und welche zusätzlich vorhanden sein können.

Für Macintoshs haben die TrueType-Dateien die Endung .suit. Die eigentlichen Daten stehen dabei im Resource-Fork.

Mir ist weder für SpeedoGDOS 5.0 ff noch für NVDI 3.0 ff eine offizielle Dokumentation bekannt, die beschreibt, welche Tabellen verwendet werden und welche zwingend notwendig sind.

10.5.1 TrueType für Windows 3.0

Microsoft hat von der Möglichkeit Gebrauch gemacht, neue Tabellentypen bei Apple anzumelden und einige davon als zwingend für Windows zu erklären.

Der Unterschied zwischen dem Apple-Format und dem Microsoft-Format ist also lediglich, daß Microsoft mehr Tabellen als zwingend notwendig erklärt hat. Außerdem ist beim Vorhandensein bestimmter Flags die Reihenfolge der Glyphen fest vorgeschrieben. Eine Definition des Microsoft-Formats findet sich in [Mic].

10.5.2 TrueType GX-Fonts bzw. TrueType 2.0

Apple hat das TrueType - Format für beliebige Designachsen erweitert. Damit haben wir hier eine Technologie, die den Multiple Master Fonts (siehe 10.4.1) entspricht.

Zusätzliche Features:

• Sie können Type 1 - Daten enthalten

• Automatische Substitution von Ligaturen

• Mehrere Baselines (z.B für Mathematische Formeln)

• Track-Kerning-Informationen (werden ab NVDI 3.02 benutzt)

Diese Features werden auf dem Mac vom Line Layout Manager (LLM) zur Verfügung gestellt und sind unabhängig vom darunterliegenden Scaler. Damit stehen diese Fähigkeiten (zumindest auf dem Mac) für alle Fonttechnologien zur Verfügung.

Informationen gibt es von der APDA, der Apple developer support organization (EMail: apda@applelink.apple.com). Dort gibt es das TrueType Book, das TrueType 1.0 beschreibt, und das QuickDraw GX Font Formats book, das die GX - Erweiterungen enthält.

Da TrueType 2.0 neue Tabellen enthält, müssen (im Gegensatz zu Multiple Master Fonts) die Scaler umgeschrieben werden, um diese Technologie zu verwenden.

10.5.3 TrueType für Windows NT

Statt die GX-Fontdefinition zu verwenden hat Microsoft für Windows NT noch ein neues Fontformat definiert, das insbesondere gegenüber TrueType 1.0 ca doppelt soviele Zeichen zwingend enthält.

10.6 Calamus-Fonts

Wo kann man näheres über dieses Format erfahren?

10.7 Vergleich der Vektorformate

Es gibt auf keiner Plattform nichtkommerzielle Programme, die ein Fontformat in ein anderes umwandeln können. Viele Fonts gibt es auch nur in einem Format.

Was aber macht eine Umwandlung so schwierig? Anders gefragt: Welche Informationen werden wie gespeichert?

10.7.1 Kurven

Zunächst sollten die Umrisse der Zeichen gespeichert werden. Hier gibt es aber viele Verfahren (vergl. [Kar92a]): Type 1 verwendet kubische Bézier-Kurven, TrueType verwendet quadratische Bézier-Kurven, Speedo verwendet kubische Bézier-Kurven.

Damit alle Fontformate für eine Applikation gleich aussehen, wandelt SpeedoGDOS auch TrueType-Zeichen für v getoutline in kubische Bézier-Kurven. Mir wäre es lieber, in diesem Fall optional quadratische Bézier-Kurven zurückzubekommen, die v bez fill dann auch verarbeiten sollte.

Quadratische Bézier-Kurven sind zwar deutlich schneller als kubische Bézier-Kurven, es werden aber ca. 4 mal soviele Punkte benötigt.

10.7.2 Hints, instructions, switches

Das nächste Problem ist die Darstellung bei geringer Auflösung des Mediums. Als unvoreingenommener Beobachter stellt man fest, daß die Speedo-Fonts auch auf dem Bildschirm immer recht ordentlich aussehen (davon abgesehen, daß einige Fonts von Hause aus nicht befriedigend sind).

Dagegen habe ich TrueType-Fonts gefunden, die auf dem Bildschirm an Häßlichkeit kaum zu überbieten sind. Das drückt sich beispielsweise darin aus, daß die beiden senkrechten Striche eines n unterschiedliche Dicken haben, einmal 1 Pixel und einmal 2 Pixel.

Die Methode zur Vermeidung solcher Rundungsfehler sind Hints. Hints haben je nach Hersteller unterschiedliche Namen: Hints bei Adobe, instructions bei Apple oder switches bei URW.

Dieses Verfahren wird von Speedo, Type 1 und TrueType beherrscht (nicht aber von Type 3 und CFN). Wenn Hints vom Format her möglich sind, heißt das noch lange nicht, daß sie auch verwendet werden (deshalb haben andere auch umgekehrte Erfahrungen mit den Formaten gemacht wie ich).

Also: Speedo-, Type 1- und TrueType-Fonts können auf dem Bildschirm sehr gut aussehen, während das bei Type 3 und CFN nicht möglich ist.

Bis jetzt ist angedeutet, was Hints machen und in welchen Formaten sie vorkommen. Aber wie machen sie das? Bestimmte Teile von Schriftzeichen haben eine Bedeutung, wie Serife, Bogen etc. Diese Bedeutung wird neben den Umrissen der Zeichen mitgespeichert. Mit dieser Information kann dann der Scaler dafür sorgen, daß beispielsweise alle senkrechten Striche im ’n’ auf dem Bildschirm gleich dick sind. Näheres siehe [Kar92a].

Type 1 zeichnet sich gegenüber anderen Formaten dadurch aus, daß es besonders wenig verschiedene Hints beherrscht. Durch die neue Multiple Master-Technologie (10.4.1) hat Type 1 aber wieder deutliche Vorteile.

Anmerkung: v getoutline liefert die Umrisse in der Größe, die für die Workstation aktuell eingestellt ist. Es ist darauf zu achten, daß je nach Größe die Hints zuschlagen oder auch nicht. Es ist geplant, v getoutline von der aktuellen Fontgröße unabhängig zu machen.

10.7.3 Interne Auflösung

Nach dem Problem der geringen Auflösung kommen wir nun zum Problem der zu hohen Auflösung, auch wenn man auf den ersten Blick kaum glauben mag, daß es hier ein Problem gibt. Siehe auch [Kar92b].

Zur Darstellung eines Fonts in einem Vektorformat muß zunächst ein internes Koordinatensystem gewählt werden. Dazu wird das Geviert (engl: em-Space; ein Quadrat, in das alle Buchstaben einer Schrift passen) unterteilt. Bei CFN geht dieses Geviert von 0 bis 16000, bei Type 1 (das entwickelt wurde, als es noch keine hochauflösenden Drucker gab) von 0 bis 1000. Das führt dazu, daß man mit Type 1-Fonts bei großen Buchstaben oder hoher Auflösung (also im Profibereich) Ecken sieht, wo keine hingehören (Laut [Kar92a] kann die interne Auflösung allerdings durch den DIV-Operator verbessert werden. Der Fonteditor muß das allerdings unterstützen. Wird dies regelmäßig gemacht? Und wird der Scaler dadurch viel langsamer?). CFN spielt hier seine Qualität voll aus.

Bei TrueType kann der Fontdesigner die Auflösung bis zu 16768 frei wählen, wobei Potenzen von zwei aufgrund der höheren Geschwindigkeit bevorzugt werden.

(Welche interne Auflösung hat OTL? Ist das Bitstream-Format, das in [Kar92a] erwähnt wird, identisch mit dem Speedo-Format?)

10.7.4 Lineare und optische Skalierung

Haben wir nun mit der Beschreibung des Umrisses, einer hohen internen Auflösung und den Hints einen beliebig skalierbaren Font? Ganz klar: Nein!

Ein Font, der für 16pt designt ist, sieht ganz anders aus, als ein um das 2-fache vergrößerter 8pt-Font (Siehe z.B in Knuth: The Book; Kopka: LaTEX [Kar92a], Page vom Mai 1996 Seite 34 etc.).

Ein gut designter Font ist nicht linear skalierbar.

Bei großen Fonts sind die senkrechten Striche im Vergleich zu den Zwischenräumen viel breiter als bei kleinen Fonts. Diese Information zur optischen Skalierung kann man aber auch in einem Font speichern.

Deshalb sollte auch ein Font, der auf dem Bildschirm 20 Pixel hoch ist, anders aussehen als einer, der auf einem Laserdrucker 20 Pixel hoch ist.

Den Rest dieses Abschnittes haben schon zu viele mißverstanden. Ich bin überhaupt der einzige mir bekannte, der hier ein Problem sieht. Das kann mindestens 3 Ursachen haben:

• Ich kann mich nicht ausdrücken.

• Ich habe ziemlich wirre Gedanken.

• Das Problem ist zu kompliziert, als daß hier überhaupt jemand ein Problem sieht.

Ich will es also noch einmal ganz neu formulieren.

Vektorfontformate geben dem Fontdesigner die Möglichkeit zu entscheiden, daß ein Schnitt unterhalb einer bestimmten Größe in Punkten oder in Pixeln anders aussieht. Es ist beispielsweise sinnvoll, einen Schnitt bei kleiner Größe in Punkten breiter werden zu lassen [Kar92a], und zwar unabhängig davon, wie gut der Drucker ist.

Stellen wir also einen kleinen Text in einem Fenster dar, sagen wir mit einer Größe von 8pt. Und der Fontdesigner hat entschieden, daß der verwendete Schnitt bei 8pt oder kleiner etwas breiter wird.

Ein zweites Fenster verwenden wir nun als Lupe, um den selben Text um den Faktor 2 vergrößert darzustellen. Fast jede Textverarbeitung hat eine solche Lupenfunktion.

Dieser zweite Text im Lupenfenster müßte jetzt eigentlich immer noch automatisch wie eine 8pt-Schrift verbreitert werden, ohne daß der Programmierer der Textverarbeitung etwas davon merkt.

Leider muß aber der Programmierer im Lupenfenster die Schrift in 16pt ausgeben, was dazu führt, daß die Entscheidung des Fontdesigners, diese 8pt-Schrift breiter darzustellen, ignoriert wird!

zur Lösung dieses Problems gibt es mehrere Wege:

1. Man gibt (als Programmierer) bei der Größenangabe zwei Werte an, die lineare Größe (hier 16 pt) und die optische Größe. An diese Methode müßten sowohl die Fontengine als auch die die Bindings angepaßt werden. Dies ist ein Vorschlag von mir, keine Realität.

2. Die einzig zur Zeit machbare Methode sind die Offscreen-Bitmaps, die NVDI beherrscht, sofern das EdDI-Cookie existiert. Beim Öffnen dieser Workstations ist die logische Pixelgröße anzugeben. Da man die logische Pixelgröße nicht nachträglich ändern kann, kostet jede einzelne optisch skalierte Fontgröße pro Dokument viel Speicherplatz. Insbesondere beim Ausdruck muß dann jede nicht standardmäßig optisch skalierte Schrift als Bitmap zwischengespeichert werden (egal ob vom Treiber oder vom Programm; ob Bitmaps vom Treiber gespeichert werden hängt von der GDOS-Version ab). Diese Methode kann leicht mehr Speicher kosten, als ein Normalanwender hat.

3. Eine weitere (noch nicht existierende) Möglichkeit wäre, wenn man mit v getbitmap info sowohl die lineare als auch die optische Skalierung frei wählen könnte.

4. Das einfachste Verfahren, das keinen Zwischenspeicher für Bitmaps erfordert, wäre die nachträgliche Einstellung der logischen Pixelgröße für alle logischen und physikalischen Workstations. Da die Scaler sowieso mit verschiedenen Pixelgrößen umgehen können, schätze ich, daß diese Methode am einfachsten in NVDI und SpeedoGDOS einzubauen wäre.

Das Problem des Lupenfensters wäre ganz einfach dadurch zu lösen, daß wir für das Lupenfenster eine andere virtuelle Workstation verwenden, für die wir die logische Pixelgröße halbieren. Dann könnten wir die Schrift in beiden Fenstern als 8pt-Schrift ausgeben, beide Texte würden – wie vom Fontdesigner gewünscht – breiter dargestellt, und trotzdem wäre die Schrift im Lupenfenster doppelt so groß.

Sollen dagegen vierschiedene optische Skalierungen in einem Dokument auftauchen, muß nachträglich die logische Pixelgröße geändert werden, oder man muß bei der Fontgröße die lineare und die optische Skalierung angeben.

Siehe auch Kapitel 19.1.

Hat das irgend jemand verstanden?

10.8 Konversion zwischen den Vektorfontformaten

Ich hoffe, daß der geneigte Leser nach den obigen Ausführungen versteht, daß die Konversion zwischen zwei Vektorfontformaten etwa so einfach ist wie das automatische Umwandeln eines hochoptimierten Programmes von einer Programmiersprache zur anderen.

Im einzelnen:

• Es gibt auf Ataris kein Programm, das zwischen den oben genannten Formaten konvertiert (man korrigiere mich bitte).

• Es gibt kein Programm auf irgendeiner Plattform, das vor den Augen der comp.fonts - Gemeinde besteht (laut comp.fonts FAQ). Es ist immer eine Nachbearbeitung von Hand notwendig.

• Für jedes Programm, das diese Aufgabe auch nur einigermaßen beherrscht, ist (mal richtig) Geld zu bezahlen. Die Suche nach brauchbaren PD- oder Sharewareprogrammen (auf irgendeiner Plattform) ist zwecklos.

11 Drucker

Hersteller  Drucker  Passende Treiber
NEC  P6+, P7+,  NECP…
P60, P70  NB15 (FX…, NX1000)
HP LaserJet II HP LJET
HP  DeskJet, LaserJet III, IV DESKJET (HP LJET)
CANON  BJ10E  BJ10
CANON  LBP 4/8  CANONLBP, LBP
Mannesmann-Tally MT 90  MT90
Epson  Stylus 800  STYLUS

Treiber in Klammern funktionieren, nutzen aber die Fähigkeiten des Druckers nicht optimal aus. Bei 24-Nadeldruckern bedeutet das, daß die Drucker im 9-Nadel-Modus betrieben werden. Bei HP-kompatiblen Laser- und Tintenstrahldruckern bedeutet das, daß die Daten nicht komprimiert werden, obwohl die Drucker das unterstützen.

Mit manchen DeskJet-Treibern soll es Probleme geben. Versuchen Sie es in diesem Fall mit einem LaserJet-Treiber. Der Ausdruck dauert dann aufgrund des größeren Datenvolumens etwas länger, die Probleme sollten aber behoben sein.

Die BJ10-Treiber bauen auf die Proprinter-Emulation auf. Der Drucker darf mit diesen Treibern nicht im Epson-Modus betrieben werden.

Beim Stylus sollte kein Treiber für 24-Nadler verwendet werden. Die einzelnen Nadeln der 24-Nadel-Drucker überlappen (im Gegensatz zum Stylus), weshalb die Treiber manche Punkte herausoptimieren und gar nicht erst drucken.

Was kompatibel heißt, bestimmen normalerweise nur die Hersteller der kompatiblen Drucker.

Anmerkungen:

• Wer seinen Drucker nicht in der Liste findet und einen passenden Druckertreiber dazu kennt, der schreibe mir.

• Auch wenn man schon einen passenden Druckertreiber für seinen Drucker gefunden hat, ist es durchaus sinnvoll, noch einige andere Druckertreiber auszuprobieren.

• Natürlich haben die FontGDOS-Druckertreiber ernsthafte Speicherplatzprobleme. Was aber den Ausdruck von Bitmap-Fonts anbelangt, so sind diese Treiber den anderen hier aufgeführten GDOS-Treibern in der Geschwindigkeit überlegen (Speedo-Treiber sind hier nicht berücksichtigt).

12 Programme

Es ist inzwischen selbstverständlich (wenn auch nicht üblich), daß alle Programme GDOS unterstützen.

Die folgende Aufstellung beschränkt sich auf Programme, die auch über GDOS ausdrucken.

Programmart  Programm  Vertrieb  Speedo
Chart/Meßwertanalyse Xact  SciLab  ja
MM-Graph  Overscan
Off-Axis ByTech Ja
DATA Professional 4  Ralf Wirtz
MessPlot Michael Siek (Shareware) (ja)
DPE  MAXON Sonderdisk
GRAPH  Hans-C Ostendorf (Shareware) ja
rho-Analyse  rhotron GmbH  ja
Graphik  Xact Draw  SciLab  ja
KandinskY  U. Roßgoderer (Shareware)  ja
TRIPLE D  U. Roßgoderer (Postcard)  ja*
Chagall  Trade-iT  ja*
Easydraw  MIGRAPH
TouchUp  MIGRAPH
GEM-View  D. Fiebelkorn (Shareware)  ja*
CHARLY IMAGE  Wilhelm Mikroel.  ja*
STELLA  Thomas Künneth  ja
GPCLIENT für GNUPLOT  ja
Tarkus  Eickmann Computer  ja
Tabellenkalkulation  LDW Power Calc 2  COMPO
K Spread 4  Omikron
Graal Calc 3  Editions Profil
Atari Works  Atari Corp.  ja
OPUS  Doug Harrison (PD)  nein
BASiChart  Dr. Ackermann  ja
TEXEL  ASH  ja

Programmart  Programm  Vertrieb  Speedo
Text/DTP  Calligrapher  Working Title
Wordflair II  H3
Timeworks Publisher GST/H3
G&D Text II  Hard & Soft
Cypress  (Gregor Duchalski)
papyrus (Gold) S R.O.M. ja
Infinity  ByTech GbR
Atari Works Atari Corp. ja
7Up  ja
1st Word Plus 4  GST/ICP  ja
Tempus Word  CCD  ja
Gut’nberg  BlowUp  ja
JAnE  DeltaLabs  ja
QED  Quellenberg/Felsch (PD)  ja
Signum!4  ASH  ja
TWIST 3 Office  MAXON  ja

Calamus

Fax  Junior Office  TKR  ja
Tele Office  TKR  ja
CoMa  SoftBär GbR  ja
Straight Fax!  Toad Computer  ja
Simulation dyn. Syst.  Dynasys  Digital Systems & Consulting
Text/Listendruck  IdeaList  Chr. Bartholme (Sharew)  ja
ProList  Richstein & Dick  ja
Chem. Darstellung  Monoklin 2.0  MAXON Sonderdisk
Chemograph Plus  DigiLab
Platinenlayout  Route iT! & Circu iT! Think!  ja
Platon  VHS  ja*
Vektorisierung  Convector Zwei  ZYN / TEAM
Hardcopy  rhocopy  rhotron
Disk-Inhaltsverzeich.  TreeView 2.4  Stephan Gerle
Fraktale  Fractals V  Harald+Martin Hansen
PS-Interpreter  Postman  SILICON Technology
Konkordanz  Concordance  SPIRIT WARE
Packershell f. MTOS  MARC 4.0  Think!  ja
Logikanalysator  CLA v2r1  Craig Graham (Shareware)  ja
Adreßverwaltung  Pegasus  Pergamon Software  ja
Symbolische Mathematik Riemann II  Begemann & Niemeyer
Solutions  Elan Software
Datenbank  Atari Works  Atari Corp.  ja
TWIST 3 Office  MAXON  ja
Notendruck  MIDI File Printer  ST 677 (PD)
CASE (Nassi-Shneider.) UpToCase  Michael Nolte  ja
Fakturierung  Kundendirektor Plus DeltaLabs  ja
Desktop  EASE ab V.3.1  ASH
Othello (Spiel)  Stello  Claus J. Pedersen  ja

Die Aufstellung stellt keine Wertung dar. Ich nehme alle Programme auf, die mir bekannt werden. Anmerkungen:

• Programme, die in der Speedo-Spalte mit ja* gekennzeichnet sind, unterstützen zwar SpeedoGDOS, machen davon aber keinen Gebrauch, geben also keine Texte aus.

• Xact kann auch ohne SpeedoGDOS Speedo-Fonts ausdrucken.

• Mit Wordflair II wird FSM-GDOS ausgeliefert. (Stimmt das noch?)

• Platon gibt lediglich Metafiles über GDOS aus.

• Ich habe es allerdings nicht geschafft, mit OPUS über GDOS auszudrucken.

Inzwischen habe ich erfahren, daß OPUS nicht die Fonts auswählt, mit denen es zurechtkommt, sondern das Drucken verweigert, sobald auch nur ein solcher Font installiert ist. Siehe auch 9.

• Programme, die nur auf Gerätenummer 21 drucken, sind out. (Opus und CLA) Siehe auch 19.2.

• 7Up benötigt Proportionalfonts (müßte das nicht nichtproportionale Fonts heißen?).

• Das Programm Tempus Word unterstützt nur Speedo- Fonts, druckt aber über eigene Treiber aus. Dieses ist anscheinend notwendig, da ja gleichzeitig auch Calamus-Fonts und das eigene Font-Format in einem Text verwendet werden können!

• Wie WordPlus 4 kann natürlich auch der ‘große’ Bruder That’s Write 3 Speedo-Fonts ohne Speedo nutzen. Ab Version 4 wird TW sogar auch TrueType und Type 1 Fonts ohne installiertes SpeedoG-DOS nutzen können (ist ja auch von den selben Leuten, die SpeedoGDOS 5.0 an TrueType und Type 1 angepaßt haben).

• LDW-PowerCalc: MAXON hat die Kundendatei vernichtet. Für Updates bitte bei COMPO melden.

• Tarkus druckt Etiketten, Formulare, Postkarten, Visitenkarten.

• Programme, die nur unter ABC-GDOS laufen, sind unter 16.1.2 aufgeführt.

• Signum!4 scheint nur mit NVDI 3.0x zu laufen, nicht aber mit SpeedoGDOS 5.x.

KandinskY Version 1.73 ist zu finden in ftp://ftp.cs.tu-berlin.de/pub/atari/Graphic/kand173

Apropos TEXEL: Nimmt man zu jedem Buchstaben des Namen MUCH den Folgebuchstaben, so kommt NVDI raus ;-))))) (genau wie HAL zu IBM und VMS zu WNT wird)

13 Hilfsprogramme

13.1 fontfix

Problemstellung: Bei manchen Bitmap-Fonts ist die Fonthöhe falsch eingetragen. Das wird durch dieses Programm erkannt und korrigiert.

Das Programm fontfix ist im Internet an folgenden Orten zu finden: ftp://ftp.uni-muenster.de/pub/atari/Applications/Dtp/Fonts/Gdos ftp://ftp.cs.tu-berlin.de /pub/atari/utils

13.2 Outline Fonts

Outline Fonts Accessory by CJG

Zweck: Bearbeitung der EXTEND.SYS-Datei für SpeedoGDOS. Die Datei enthält eine Beschreibung der Größen der Speedo-Caches, der Fonts und der voreingestellten Fontgrößen. Außerdem können die Caches auf Platte gespeichert und wieder geladen werden. Ein durchaus gelungenes Programm bis auf die Tatsache, daß die vorgeschlagenen Cachegrößen auf FSM-GDOS und nicht auf SpeedoGDOS abgestimmt sind.

Dateiname: OUTLINE.PRG alias OUTLINE.ACC, 67644 Bytes SpeedoGDOS 5.0: 49254 Bytes

Wird bei SpeedoGDOS mitgeliefert.

Warum schafft es Atari eigentlich nicht, die Programme mit einer Versionsnummer auszustatten?

13.3 Druckertreiber

GDOS Devices Accessory by CJG

Zweck: Bearbeiten der ASSIGN.SYS.

Dateiname: DRIVERS.PRG alias DRIVERS.ACC, 64878 Bytes SpeedoGDOS 5.0: DRIVER.PRG, 41592 Bytes

Bevor man dieses Programm startet, sollte eine Sicherheitskopie der ASSIGN.SYS angelegt werden! Dafür gibt es (mindestens) zwei Gründe. Erstens werden die Informationen über die Bitmap-Fonts kommentarlos hinausgeworfen und zweitens wird - falls man unter Benutzereigen den Knopf Hinzufügen drückt - die ASSIGN.SYS überschrieben, ohne daß man das mit Abbruch im Hauptmenu wieder rückgängig machen kann. An alle Programmierer: macht so etwas bloß nicht nach.

Sollte das Programm einmal keine Treiber anzeigen, ohne aber eine Fehlermeldung zu bringen, hilft es, ASSIGN.PRG laufen zu lassen.

Von meinen vielen Treibern zeigt dieses Programm nur die Speedo-Treiber an. Weiß jemand, wie das Programm das macht? Außerdem zeigt das Programm nicht den Filenamen an, sondern einen Namen, der als String im Treiber hinterlegt ist. Wie kommt man da dran?

13.4 ASSIGN

ASSIGN 1.0a ist von Dirk Sabiwalsky (PD).

Assign testet drei Dinge:

• Besitzen mehrere Zeichensätze die gleiche ID und haben unterschiedliche Namen (Typefaces)?

• Besitzen mehrere Zeichensätze die gleiche ID und die gleiche Pixelhöhe?

• Besitzen mehrere Zeichensätze den gleichen Namen (Typeface) und unterschiedliche IDs?

13.5 FONTCHK

Zweck: Testet GDOS-Fonts auf mögliche Fehler.

Das Programm wird beispielsweise bei ProList mitgeliefert.

13.6 FONTCNV

Zweck: Konvertiert GDOS-Fonts von der Motorola- in die Inteldarstellung

Das Programm wird beispielsweise mit ProList mitgeliefert.

13.7 GEMFont

Fonteditor, der auch Signum- und PK (TEX)- Fonts lesen kann. ftp://ftp.tu-clausthal.de/pub/atari/systools/gdos/gemfo120.lzh Bei dieser Gelegenheit gleich ein neueres unlzh oder lhxarc besorgen.

13.8 FontMonger

Konverter und Editor für verschiedene Vektorfontformate, auch Speedo. Läuft leider nur auf DOSen und MACs.

13.9 Font-ID

Font-ID ist ein kleines Freeware-Programm von Frank Schneider. Es zeigt die mit SpeedoGDOS oder GDOS installierten Fonts samt Font-ID in verschiedenen Punktgrößen in einem Fenster an.

Man kann sich also einen Überblick verschaffen, wenn man gerade kein Programm mit Fontselektor zur Hand hat oder dieses die Font-ID nicht anzeigt.

13.10 X4U

Speedo-Fonts enthalten wesentlich mehr Zeichen, als in einen Ascii-Zeichensatz abgebildet werden können. Mit diesem Programm von Peter Hellinger kann bestimmt werden, welches Zeichen bei einem gegebenen Ascii-Code erscheint. Vertrieben wird es von R.O.M.

Eigentlich wollte R.O.M. dieses Programm gratis auf die SpeedoGDOS 4.2-Disketten packen. Das ging aber nicht, weil Helli die MagicLib verwendet hat und das Programm deshalb zu groß wurde. R.O.M. hat es daher separat für 25 DM verkauft, was Helli, obwohl er von R.O.M. für die Auftragsarbeit bezahlt wurde, zu rechtlichen Schritten veranlasste. Ulli Ramps von R.O.M. wurde das zu bunt, und er erklärte X4U zu einem PD-Programm, was Helli wiederum zu rechtlichen Schritten veranlasste. (Fortsetzung im nächsten Abschnitt)

13.11 Charmap

Charmap heißt das Originalprogramm von Atari, das dasselbe macht, wie X4U, aber nicht freigegeben wurde.

Charmap heißt aber auch Peter Hellingers Weiterentwicklung von X4U, die in der Version 0.9 als Freeware frei kopiert werden darf. (To be continued)

13.12 GDOS-Font

Filename: GFONT112.LZH. Utility allgemein, Shareware-Eingeschränkt. GDOS-Font 1.12 (22.08.94) von Holger Weets @ OL. Zeigt und bearbeitet GDOS-Fonts und meldet sie in der ASSIGN.SYS an oder ab! =^{≫} Nie mehr von Hand die ASSIGN.SYS ändern, das erledigt alles GDOSFONT.

13.13 REFONT

Dieses Programm konvertiert Type 1-Fonts zwischen der Mac-, Unix- und Windows-Darstellung und TrueType-Fonts zwischen der Mac- und Windows-Darstellung. Zwischen T1 und TT kann es allerdings nicht konvertieren.

Dieses Programm gibt es (mindestens) für MS-DOS, Windows, OS/2 und UNIX.

13.14 Arkus

Arkus 1.16 ist ein Fontmanager von Pergamon Software.

14 Fontselektoren

Bei Fileselektoren hat man sich daran gewöhnt: Das Betriebssystem bietet nicht nur einen Fileselektor, sondern auch eine Schnittstelle, über die man systemweit alternative Fileselektoren anmelden kann.

Eine normierte Schnittstelle fehlt bei Fontselektoren, sie bieten ihre Dienste üblicherweise über Cookies an. Selbst der Aufwand, mehrere Fontselektoren über Cookies zu unterstützen, ist aber wesentlich geringer, als selbst einen solchen zu schreiben. Wäre da nicht… aber schauen wir uns zunächst die Kandidaten an.

Bei den Fontselektoren gab es in den letzten Monaten eine rasante Entwicklung, die sich noch nicht im FAQ niedergeschlagen hat. Die Beschreibung der einzelnen Selektoren ist also nicht mehr aktuell und es gibt neue Selektoren, die hier noch nicht aufgeführt sind.

14.1 The quick brown fox…

Sicherlich ist der eine oder andere genervt, weil in Fontselektoren (fast) immer dieser Satz ”The quick brown fox jumps over the lazy dog“ als Schriftbeispiel dargestellt wird. Warum wird gerade dieser Satz immer wieder verwendet? Die Antwort ist ganz einfach: Dieser kurze Satz enthält alle Buchstaben des Alphabets.

In einem Buch von Martin Gardner (falls mich die Erinnerung nicht trügt) habe ich eine ganze Reihe von deutschen und englischen Sätzen mit dieser Eigenschaft gefunden. Leider weis̈ ich nicht mehr, in welchem meiner 18 Bücher von Martin Gardner das war. Für Hinweise auf diese Sätze in allen Sprachen bin ich dankbar.

Hier einige Beispiele aus der PAGE 1/96: The quick brown fox jumps over the lazy dog I pack my box with five dozen liquor jugs Wolves exit quickly as fanges zoo chimps jabber Victors flank gyp who mixed job quiz Six big devils from Japan quickly forgot how to waltz Oozing quivering jelly fish expectorated by mad hawk

Fixquark vom weibtyp geschlejnzt Oh, welch Zynismus, quiekte Xavers jadegrüne Bratpfanne

Ähnliche Aufgaben hat das Wort ”OHamburgefons“. Dieses Wort enthält zwar nicht alle Buchstaben, aber alle wesentlichen Designelemente, aus denen die Buchstaben eines Alphabets zusammengesetzt sind. Beim Design einer neuen Schrift wird oft in der Reihenfolge der Buchstaben dieses Wortes vorgegangen.

Und für die Poeten unter den Fontselektorautoren (aus The Siege of Belgrade): An Austrian Army, awfully arrayed, Boldly by battery besieged Belgrade; Cossack commanders cannonading come, Dealing destruction’s devastating doom; ...

14.2 UFSL

UFSL von Michael Thänitz ist Freeware und darf jedem Programm beigelegt werden. Die letzte Version ist 0.97 vom 30. April 1994.

Fonts und Größe lassen sich angenehm auswählen. Nach freier Eingabe wird der Font nach einem Doppelklick auf die freie Eingabe angezeigt. Intuitiver fände ich einen Doppelklick auf das Beispiel.

Es fehlen die Attribute, und der Selektor steht nur als modaler Dialog zur Verfügung.

UFSL wird leider nicht weiterentwickelt.

14.3 XUFSL, HuGo

XUFSL 1.05 von Stefan Rogel ist der umfangreichste der hier besprochenen Fontselektoren. Insbesondere arbeitet er mit SpeedoGDOS 5.0 zusammen.

Dieser Fontselektor gefällt mir ganz ausgezeichnet. Die große Informationsvielfalt wird durch einen gut aufgeteilten Karteikartendialog sehr übersichtlich dargestellt. Auch daß die Schnitte in einem Popup ausgewählt werden, stört nicht mehr wie die vielen Popups in der Version 1.03.

Der Fontselektor zeigt alle wissenswerten Informationen zum ausgewählten Schnitt an; ebenso zeigt er den kompletten Ascii-Zeichensatz an. (Wenn man den jetzt auch noch ausdrucken könnte und auch noch der komplette 16 Bit-Zeichensatz zugänglich wäre…; aber so etwas wage ich von den anderen Fontselektoren noch gar nicht zu wünschen.)

XUFSL ist inzwischen von HuGo abgelöst.

14.4 Magic von Helli

Dieser Fontselektor ist Bestandteil von Magic 4.00 von Peter Hellinger et al. und nicht separat erhältlich. Magic selbst - nicht zu verwechseln mit dem Betriebssystem Mag!C - ist frei kopierbar. Nur für die Information, wie man damit umgeht, verlangt der Autor eine Gebühr.

Angenehm an diesem Selektor ist, daß er nichtmodal in einem Fenster zur Verfügung steht, wahlweise auch als FlyDial oder normaler Dialog.

Der Fontselektor läßt sich nur verwenden, wenn man die Eventverwaltung komplett Magic überläßt, was dem Programmierer eine feste Programmstruktur aufzwingt (funktionierendes muß neugeschrieben werden, anderes geht gar nicht mehr) und weitere Fehler nach sich zieht.

14.5 FontSel

FontSel von Holger Weets ist für die Programme voll kompatibel zu UFSL. Sehr schön ist, daß das Programm sehr kurz ist und auch die Fontattribute auswählen läßt.

Version 1.00 vom 11.5.94 zeigt mit Speedo 5.0a leider nur den Systemfont an.

14.6 Weitere Fontselektoren

Weiter arbeiten Hayo Schmidt, Christian Grunenberg und Wilfried Behne an (jeweils) einem Fontselektor. Die kenne ich aber alle nicht.

14.7 Minimalanforderungen

Ein Fontselektor muß mit allen Betriebssystemversionen zusammenarbeiten (TOS, MiNT, MultiTOS, MagiC!, Geneva). Er muß mit jeder Videohardware klarkommen, die VDI unterstützt und mit jeder GDOS-Version jeden verfügbaren Font anzeigen.

Jeder der oben genannten Fontselektoren scheitert an mindestens einer dieser Forderungen.

14.8 Wünschenswerte Eigenschaften

14.8.1 Attribute und Auswahl

Es ist furchtbar umständlich, weitere Eigenschaften eines Fonts in einem weiteren Dialog einstellen zu müssen. Deshalb sollten mindestens die üblichen Fontattribute (fett, outlined etc) einstellbar sein. Über diesen Wunsch kann man sich trefflich streiten. Aber für Vektorfonts wählt man die Attribute (in Form von Schnitten) aus, und es wäre inkonsistent, dies dann für Bitmapfonts nicht zuzulassen. Wenn diese Attribute vom Programm nicht verarbeitet werden, sollten sie unsichtbar gemacht werden können.

Ebensolches gilt für den Skew-Winkel.

Nicht jedes Programm kann mit jedem Font etwas anfangen. Deshalb sollte jedes Programm bestimmen können, welche Schnitte gar nicht angezeigt oder disabled angezeigt werden. Einige Programme können beispielsweise nur mit nichtproportionalen Schriften etwas anfangen. Zusätzlich (aber wegen BASIC nicht ausschließlich) sollte dem Fontselektor eine Prozedurvariable übergeben werden können, die für jeden einzelnen Schnitt aufgerufen zurückmeldet, ob und wie er angezeigt werden soll.

14.8.2 Fenster und Eventverwaltung

Schön wäre es, wenn das aufrufende Programm bestimmen kann, ob ein Fontselektor als Dialog oder im Fenster erscheint. Das läßt sich auch viel einfacher und flexibler als bei Magic bewerkstelligen: Der Fontselektor öffnet im Namen der Applikation ein Fenster und gibt das Fensterhandle an die Applikation zurück. Die Applikation verwaltet weiter die Events und wenn eines davon das Fenster des Fontselektors betrifft, wird die Information durch einen Prozeduraufruf an den Fontselektor weitergegeben. Durch diesen sehr einfachen Mechanismus können sogar mehrere (systemweite) Fontselektoren, Colorpicker etc. verschiedener Hersteller gleichzeitig in Fenstern auf dem Bildschirm sein.

Dieses Nebeneinander ist nur möglich, wenn die einzelnen Selektoren (optional) auf eine eigene evnt multi-Schleife verzichten.

Praktisch alle Autoren von Utilities wollen dies umgekehrt machen (und tun dies auch). Deshalb will ich detailliert ausmalen, was passiert, wenn Utilities den evnt multi-Aufruf selbst machen und nicht bearbeitete Events an die Applikation weitergeben:

In diesem Fall gibt es für eine Applikation mehrere Utilities, die alle darauf bestehen, den evnt multi-Aufruf selbst zu machen. Irgendeines dieser Utilities führt diesen Aufruf durch, kann ihn nicht bearbeiten und gibt den Event an die Applikation weiter. Und nun? Was soll die Applikation machen? Sie kann den Event nicht mehr an andere Utilities weitergeben, obwohl eines davon für den Event zuständig ist. Aber alle weigern sich, Events von der Applikation entgegenzunehmen.

Bei Zuwiderhandlung der Autoren der Utilities kann eine Applikation maximal ein (Fenster-)Utility verwenden. Wenn eine Applikation Hellis Magic verwendet, kann sie sogar gar kein Utility mehr verwenden.

14.8.3 Verschiedenes

Zuletzt sollte ein Programm auch sagen können, daß es irrelevant ist, ob ein Schnitt proportional ist oder nicht (dem Anwender kann das auf seinen expliziten Wunsch trotzdem angezeigt werden). Beim Verzicht auf diese Information kann das Laden der Fonts in einem Bruchteil der Zeit stattfinden.

Der Fontselektor, der mir derzeit am besten gefällt, ist der von papyrus. Leider gibt es ihn nur in papyrus eingebaut.

14.9 Über Dialoge

Was ich hier schreibe, hat eigentlich gar nichts mit dem Thema des FAQs zu tun. Aber es paßt hierher. Seht es als meine persönliche Anmerkung zu Tim Oren [Ore85].

Ich habe mich schwer darüber gewundert, warum mir der Fontselektor in papyrus soviel besser gefällt als XUFSL 1.03. Dabei enthält doch XUFSL allen Schnickschnack, den die neuen Libraries so bieten. Und vor allem verstößt XUFSL 1.03 gegen keine Designrichtlinie, die ich explizit gelesen habe. Das jetzt folgende gilt für Dialoge im Allgemeinen und nicht speziell für XUFSL 1.03.

Ich versuche also, bewußt zu machen, was mich unbewußt stört. Andere mögen zu anderen Ergebnissen kommen.

Mich stören an solchen Dialogen am meisten die Popups (insbesondere mit Slidern)!

Zeitgemäße Benutzeroberflächen zeichnen sich dadurch aus, daß man auswählt statt einzugeben (wie bei diesen unsäglichen MS-DOS-Programmen). Zu dieser Auswahl gehört es, nachsehen zu können, was es alles gibt.

Und genau das fehlt bei Popups. Vor allem, wenn mehrere in einem Dialog auftreten: man kann nicht bei der Eingabe mal kurz nachsehen (oder noch besser: sehen statt nachsehen), was es sonst noch gibt. Zu allem Überfluß verlangt ein Popup auch noch einem Mausklick, bevor man etwas anderes machen kann.

Für die Theoretiker: damit hat man einen modalen Teil in einem nichtmodalen Dialog oder schlimmer noch in einem sowieso schon modalen Dialog. Und modale Dialoge werden als störend empfunden.

Diese Verwendung von Popups verstößt also gegen die grundlegenden Ideen hinter einer intuitiven Benutzeroberfläche. Ich weiß, Ihr seid alle stolz, Popups - sogar solche mit Slidern - zu beherrschen. Laßt es möglichst trotzdem bleiben.

15 Vertrieb

15.1 Atari

Die mit Atari gekennzeichneten Druckertreiber waren bei Atari erhältlich.

Dieses Paket gibt es auch bei den Fachhändlern.

Es gibt keine Doku, aber für den Preis lohnt es sich allemal.

15.2 BELA

Die mit BELA gekennzeichneten Treiber gab es bei BELA.

Es gab zwei Disketten mit gepackten Druckertreibern und Fonts für die Treiber.

Die Fonts haben zwar den gleichen Filenamen und Font-IDs wie die entsprechenden Atari-Fonts, unterscheiden sich aber im internen Fontnamen. Daher werden diese Fonts korrekterweise von einigen Programmen zurückgewiesen, wenn sie zusammen mit den original Atari Fonts verwendet werden.

Dokumentation gibt es praktisch nicht. Nicht einmal einen Hinweis, wer das Copyright der einzelnen Treiber hat, oder wer die Autoren sind.

BELA gibt es nicht mehr.

15.3 Language

Der mit Language bezeichnete Treiber wird auf der Language-Disk des Mega STE mitgeliefert.

15.4 Internet

Die mit I gekennzeichneten Druckertreiber sind im Internet zu finden (z.B. ftp://ftp.cs.tu-berlin.de/pub/atari).

15.5 Working Title

Die mit WT und wt bezeichneten Treiber werden mit Calligrapher ausgeliefert. Die WT-Treiber sind \begin{matrix}c \\ ◯ \end{matrix}Working Title, die wt-Treiber sind von Working Title lizensiert.

Auf der Calligrapher-Demodisk werden keine Druckertreiber mitgeliefert. Die Druckertreiber, die mit Calligrapher-Lite (15 DM) ausgeliefert werden, sind in den Tabellen mit CL gekennzeichnet.

Auf beiden Disketten sind Bildschirmfonts enthalten.

15.6 X Window System

Für das X Window System gibt es PD-Speedo-Fonts von Bitstream. Diese können mit SpeedoGDOS 4.2 verwendet werden. Bei mir funktioniert das wunderprächtig und auch die Umlaute machen keine Probleme.

Im Internet Archie (Siehe 15.9) wie folgt suchen lassen: set search sub prog speedo-

Die Fonts: font0648.spd -bitstream-charter-medium-r-normal–0-0-0-0-p-0-iso8859-1 font0649.spd -bitstream-charter-medium-i-normal–0-0-0-0-p-0-iso8859-1 font0709.spd -bitstream-charter-bold-r-normal–0-0-0-0-p-0-iso8859-1 font0710.spd -bitstream-charter-bold-i-normal–0-0-0-0-p-0-iso8859-1 font0419.spd -bitstream-courier-medium-r-normal–0-0-0-0-m-0-iso8859-1 font0582.spd -bitstream-courier-medium-i-normal–0-0-0-0-m-0-iso8859-1 font0583.spd -bitstream-courier-bold-r-normal–0-0-0-0-m-0-iso8859-1 font0611.spd -bitstream-courier-bold-i-normal–0-0-0-0-m-0-iso8859-1

15.7 COMPO

Bei Compo gibt es zwei Pakete mit jeweils 100 Fontschnitten im Bitstream Speedo-Format für je 99.- DM (ohne Gewähr):

Inzwischen bietet COMPO ein CD-ROM mit TrueType und Type1 Schriften an, das wohl dieselben Schriften enthält, wie das StarType CD-ROM. Aber eben beide Arten auf einem CD-ROM. Preis: 99.- DM

15.8 IMG-0300

ftp://ftp.uni-muenster.de/pub/atari/Gdos

15.9 FTP

Viele Studenten haben das Glück, sich überall auf der Welt mit FTP Dateien holen zu können. Es ist allgemein bekannt, daß die Unis nur Pauschalen für die Standleitungen zahlen. Weitgehend unbekannt ist aber, daß Verbindungen zwischen Europa und Amerika von den Unis volumenabhängig bezahlt werden müssen.

Versuchen Sie also, Verbindungen über den großen Teich strikt zu vermeiden und auch sonst möglichst kurze Wege zu wählen. Außerdem sollte die Übertragung auf Zeiten außerhalb der Arbeitszeiten am Ort der Server gelegt werden.

Wo sich Files mit bekanntem Dateinamen befinden, kann mit Archie herausgefunden werden. In Deutschland: telnet archie.th-darmstadt.de login: archie help In den USA z.B.: archie.ans.net

Archie zeigt dann automatisch weitere Archie-Rechner an. Verwenden Sie den in Ihrer Nähe.

Die Archie-Datenbanken fragen etwa einmal im Monat nacheinander die bekannten FTP-Server nach den öffentlich zugänglichen Files ab.

Noch ein kleiner Tip: atari.archive.umich.edu ist immer dicht. Nicht einmal das Spiegeln auf andere Server funktioniert. Man sucht daher besser auf amiga.archive.umich.edu und tippt dort cd atari. Dieser Rechner hat die gleiche Platte gemountet. Aber: Bitte zuerst in der eigenen Umgebung suchen!

15.10 SciLab

Die GDOS-Treiber von SciLab sind nicht in den Treibertabellen aufgeführt, auch wenn insbesondere die Treiber für Farbdrucker sehr begehrt sind.

Diese Treiber können nicht (mehr) einzeln bei SciLab bezogen werden. Das liegt daran, daß viele Programme die Farbtreiber falsch ansprechen und SciLab dann den Ärger hat.

Man kann an diese Treiber nur herankommen, wenn man ein entsprechendes Programm bei SciLab kauft, oder wenn man den Softwarevertrieb der eigenen Programme bittet, diese Treiber zu lizensieren. SciLab hat dafür immer ein offenes Ohr. Insbesondere sind dies speedofähige Treiber für HP 600 dpi und HP 500C/550C. Diese sind aber inzwischen bei SpeedoGDOS 5.0 dabei.

15.11 Star Division

Von Star Division gibt es CD-ROMs (StarType) mit 500 TrueType bzw. Type1 Fonts. Dieses sind meist komplette Pakete der einzelnen Fonts. Zum Beispiel sind von der ’Zapf Humanist 601’ folgende Schnitte vorhanden: roman, italic, bold, bold italic, demi, demi italic, ultra, ultra italic.

Viele Schriften von Bitstream sind auf dieser CD enthalten (eben auch die Zapf Humanist 601) Außerdem sind zwei ITC-Schnitte enthalten. Zu bekommen sind diese CD-ROMs und ein Booklet mit einer Übersicht zumindest bei Vobis (Preis: 69.-DM)

15.12 Thierry Rodolfo

Die mit T.R. bezeichneten Treiber sind von Thierry Rodolfo. Sie finden sich in der BBS BRASIL und in ftp://hensa.micro.ac.uk/atari/tos/n/n196/ Ausnahme: MEMORY 2 befindet sich in ftp://ftp.cs.tu-berlin.de/pub/atari/GDOS/

15.13 Sonstige

Ich treffe keine Auswahl an Treibern. Das Kriterium ist Vollständigkeit.

Die Programmautoren (und Anwender) der Programme sind hiermit aufgefordert, mir zu schreiben, welche GDOS-Treiber bei den einzelnen Programmen mitgeliefert werden (mit den Angaben Codelänge, Datum und evtl. bekannte Fehler).

Ein Vergleich verschiedener TrueType-CDs findet sich in [Hil95].

Wer ansonsten diese billig-CDs verwendet (jeweils 500 TT-Schnitte für 15 DM), sollte nicht auf Umlaute, Kerning oder ein ausgewogenes Schriftbild bestehen. Dann macht es auch nichts mehr aus, 20 Fonts auf einem Plakat zu verwenden. (Seufz!)

16 GDOS-Versionen

16.1 Die Fossile

Atari-GDOS, AMCGDOS, ABC-GDOS, NVDI bis 2.51 und wahrscheinlich G+Plus verwenden die selben Treiber.

16.1.1 Atari-GDOS 1.X und AMCGDOS

Das Atari-GDOS ist der Urahn aller GDOSe. GDOS 1.0 wurde von Digital Research für Atari entwikkelt. Besondere Eigenschaften sind die vielen Fehler und die unerträgliche Langsamkeit. Aber das ist Geschichte.

AMCGDOS ist schneller und hat weniger Fehler. Es hat aber im Wesentlichen den gleichen Funktionsumfang und wurde zusammen mit dem AtariGDOS vertrieben.

16.1.2 ABC-GDOS

ABC-GDOS ist in ABCs GEMVDI.PRG enthalten. Wird dieses GDOS verwendet, so ist für ASSIGN.SYS eine erweiterte Syntax zu verwenden:

≪driver number^{≫} ^{≪}driver’s file name^{≫}; ^{≪}technical info^{≫}; ^{≪}icon text^{≫}

Durch das erste Semikolon wird die Zusatzinformation von anderen GDOSen als Kommentar interpretiert. ≪technical info^{≫} ist der Klarname des Treibers, wie er ab SpeedoGDOS 4.2 und NVDI 3.0 mit vqt devinfo in ptsout geliefert wird.

Es läuft nur auf 68000ern, weil wahrscheinlich der Interupt-Level manipuliert wird.

ABC-GDOS kommt aus Holland und hat praktisch keinerlei Verbreitung gefunden.

ABC hat einige Programme, die von Digital Research geschrieben wurden, auf Ataris portiert. Leider weigern sich diese Programme mit anderen Versionen als GEM 2.2 (ABC-GDOS) zusammenzuarbeiten. Deshalb sind die Programme nur hier aufgeführt:

WordChart, Graph, Paint und Draw

16.1.3 G+Plus

G+Plus wurde John Eidsvoog und Charles F. Johnson und ist (c) 1988, 1989 CodeHead Software. G+Plus kann ohne ASSIGN.SYS gebootet werden, daf”r können nachträglich beliebige verschiedene ASSIGN.SYS nachgeladen werden. Ebenso existieren Schnittstellen für Applikationen, so das̈ diese nachträglich und ohne Neustart Fonts und Treiber nachladen können.

16.1.4 G+Flair

G+Flair lag Wordflair 1 bei und war – bis auf die Tatsache, das̈ es nur ein ASSIGN.SYS laden konnte – identisch mit G+Plus.

16.2 Ein Schritt nach vorne

Auch wenn es mit NVDI schon ein sehr gutes GDOS gab, hat Atari die Klagen der Anwender und vor allem der Programmierer erhört und die Funktionalität des GDOS zu verbessern versucht.

16.2.1 FontGDOS 2.0

Hierbei handelt es sich um ein GDOS, das weiterhin nur Bitmap-Fonts verwendet.

Die Treiber aus diesem Paket sind wirklich drastisch schneller als die bisherigen (vergleichen kann man natürlich nur den Ausdruck von Bitmap-Fonts und Graphik).

Ich habe keine Probleme gehabt, diese Treiber mit anderen GDOS-Versionen zu kombinieren. Man muß sich aber auf die alten Fonts beschränken.

FontGDOS ist der Nachfolger des Atari GDOS. Es unterscheidet sich im Wesentlichen durch die Bézierfunktion und schnellere und farbfähige Treiber. Es hat nichts mit FSM-GDOS oder SpeedoGDOS zu tun.

FontGDOS ist bei einigen Firmen erhältlich, die es für eigene Programme nutzen.

16.2.2 FSMGDOS 3.0

Gleichzeitig mit FontGDOS hat Atari ein GDOS entwickelt, das mit Vektorfonts arbeiten kann (in diesem FAQ als OTL bezeichnet). FSMGDOS ist also kein Nachfolger von FontGDOS, sondern wurde parallel dazu entwickelt. FSMGDOS war praktisch schon zum Vertrieb freigegeben, als es im letzten Moment aufgrund massiver Proteste der Entwickler gestoppt wurde. FSMGDOS wurde (außer im Bundle) niemals offiziell vertrieben.

Es wurde das Imagen Outline-Font-Format der QMS/Imagen Corp verwendet.

16.3 Aktuelle Entwicklungen

16.3.1 SpeedoGDOS 4.0 und 4.1

Siehe auch [Res92].

Ob es sich bei einem Font um einen Speedo- oder Bitmap-Font handelt, steht im 33. Byte des Fontnamens (vqt name, INQUIRE FACE NAME AND INDEX, VDI 130). Ist es 0, handelt es sich um einen Bitmap-Font, bei 1 um einen FSM- oder Speedo-Font.

Auf einige Probleme ist dringend hinzuweisen:

Als Programmierer kann man nicht herausfinden, ob ein Treiber Speedo-Fonts verträgt oder nicht (vergleiche aber letzte Frage in Kapitel 13.3).

Einige Font-IDs werden leider sowohl von Bitmap- als auch von Speedo-Fonts verwendet, obwohl verschiedene Fonts mit gleicher ID niemals gleichzeitig installiert sein dürfen.

Zuwiderhandlung gegen die genannten Punkte werden mit Bomben bestraft.

Es liegt also am Anwender, daß die richtigen Treiber und Fonts installiert sind. Der Programmierer hat keine Chance, hier helfend einzugreifen und Fehler abzufangen.

Am besten installiert man nur Bitmapfonts mit den entprechenden Treibern oder verwendet ein reines Speedo-System.

Der mitgelieferte Monospace-Font der Version 4.0 enthält keine Umlaute.

Entgegen den Aussagen in [Pru93c] wird SpeedoGDOS zur Zeit weiterentwickelt.

Zur Installation und Programmierung empfehle ich dringend [Dic93a], [Dic93b] und [Dic93c]. Es ist darauf zu achten, daß NVDI vor SpeedoGDOS im Autoordner steht.

Wer SpeedoGDOS einzeln gekauft hat, hat Version 4.0 bekommen, den Falcons lag 4.1 bei.

16.3.2 SpeedoGDOS 4.2

Lassen wir Ulli Ramps zu Wort kommen:

Huhu!

Im Folgenden finden Sie eine Liste der Änderungen, die in die SpeedoGDOS Version 4.2 Eingang gefunden haben:

Line-A: Aufgrund häufiger Entwickler-Anfragen (:-)) wurde Speedo GDOS vom LINE-A-Betriebssystem-teil unabhängig gemacht. Sämtliche Ausgaben laufen nunmehr über VDI Aufrufe. Dies macht Speedo GDOS kompatibel zu vielen Graphik-Karten und bewirkt mehr Multi-Tasking-”Freundlichkeit“. Auch können jetzt verschiedene VDI-Ersatzprogramme wie bspw. NVDI besser mit Speedo GDOS eingesetzt werden. Ein weiterer Vorteil der Line-A-Unabhängigkeit ist, daß der sog. ”Scratch Puffer“ für algorithmisch errechnete Spezialeffekte keine Sorgen mehr bereitet. Spezialeffekte sind jetzt über die Treiber (wie MEMORY.SYS und die Druckertreiber) implementiert, sodaß der Benutzer bzw. das eingesetzte Programm sich nicht mehr um Speicher-Anforderungen kümmern muß, um beliebige Punktgrößen zur Verfügung zu stellen. Zu beachten ist hierbei, daß die Treiber auf dem neuesten Stand sein müssen; verwenden Sie also keinesfalls mit Speedo GDOS 4.2 ”ältere“ *.SYS-Treiber! Für Programme ohne Textfunktionen können Sie allerdings ältere Treiber benutzen (sprich: für reine Grafik).

Spezialeffekte wie ”fett“ oder ”kursiv“ sind jetzt auch in gedrehten Texten einsetzbar; ebenso ”hell“; ”fett“ und ”hell“ zusammen gehen nur in 90 Grad Schritten.

Für Programme, die die Font ID-Nummern lesen, ist wichtig, daß Speedo 4.2 den Wert 5000 zu den Font ID-Nummern addiert, um Konflikte mit den ID-Nummern von GDOS Pixelfonts zu vermeiden.

Aus Druckertreibern wird von SpeedoGDOS 4.2 die Info für den ’ FSM HDR’ cookie geprüft. Wenn dieser cookie nicht gefunden wird, wird das Laden von Fonts unterbunden und dieser (offensichtlich ältere) Treiber kann nur für nicht-Text-Ausgaben genutzt werden. Treiber-Header müssen für diese und zukünftige Versionen immer an einer Word Grenze beginnen.

Vst load fonts() ist in zwei Punkten optimiert worden: 1. wird beim load font call nachgesehen, ob das ”EXTEND.SYS“ modifiziert wurde und führt nur noch dann ein Neuladen der Fonts durch. Durch Wegfall des scratch Puffers besteht keine Notwendigkeit mehr für ein ständiges Neuladen. Weiter wird die globale Fontliste nicht jedesmal deallociert, was Programmstarts enorm beschleunigt. Als Nebeneffekt wird allerdings das miscellaneous cache bzgl. der Font Header Infos erst beim nächsten Booten gelöscht.

MEMORY.SYS öffnet nicht mehr irrtümlich einen Druckerhandle.

Der vst height() wird jetzt nicht mehr bis zu einer maximalen Punktgröße größer und dann irrtümlich wieder kleiner.

Die Postscript-Tabelle ist jetzt nutzbar.

vrt copyfm() in den Treibern ist repariert.

9) When in ’bicsmode’, character 0 was not passed through to the font engine. ??? [Anmerkung GC: Speedo kann pro Font mit zwei verschiedenen Charactersets arbeiten, einmal sortiert wie bei einem normalen Atari-Font und einmal wie ein Bitstream-Font. Im Bitstream-Modus ist character 0 ein Leerzeichen. Deshalb ist es auch unsinn, wenn in [San94] vorgeschlagen wird, auch 16-bit-Zeichen nullterminiert zu übergeben.]

Die Behandlung negativer Punktgrößen wurde konsistent zum originalen Handling im alten FSM gemacht.

Die Treiber behandeln jetzt auch gebrochene Zahlen für Schriftweiten korrekt.

Das v ftext() der Treiber kann nun die offsets benutzen, die an das ptsin array gegeben wurden.

Bildschirm-Treiber können nun korrekt als device 10 geladen werden.

Der memory Treiber kann nun auch resident geladen werden.

vqt devinfo() - vqt devinfo() geben nun eine Rückmeldung, je nachdem, ob die device geöffnet ist oder nicht. Weiterhin wird der Treibername der device, zu finden im driver header, in das ptsout array abgelegt, der Name ist 26 bytes lang. Achtung: Wenn der Treiber nicht SpeedoGDOS-kompatibel ist, wird ein Null String zurückgegeben; bei einem Fehler gibt es eine -1 in ptsout[1].

Neuer Aufruf vst width(): Dieser call ist identisch mit vst height(), nur daß er die Weite setzt. Die Einbindung ist identisch, nur der opcode ist 231. Achtung: Wie bei vst arbpt() und vst setsize() muß erst der generelle Aufruf vst arbpt() oder vst height() getätigt werden, bevor man die Weiten-Aufrufe vst setsize() und vst width() nutzen kann. Die generellen Aufrufe setzen immer die Weiten zurück!

Nun ich wieder: Das Installationsprogramm zu Speedo 4.2 hatte bisher einen kleinen Fehler. Wenn ein NEC P - Drucker ausgewählt wird, schreibt es NEC P.SYS in die ASSIGN.SYS, obwohl der mitgelieferte Druckertreiber NECP.SYS heißt. R.O.M. hat das inzwischen verbessert.

16.3.3 SpeedoGDOS 5.0

SpeedoGDOS 5.0 wird von no|Software unter Verwendung der Sourcen von Atari (weiter-)entwickelt und von COMPO vertrieben. Es beherrscht zusätzlich TrueType und Type 1 (Vergl. 10). Kosten: 129.- DM (ohne Gewähr).

Es werden nur 9 Druckertreiber mitgeliefert, und zwar die neuen. Da es sich um ein Upgrade handelt, ist man ja im Besitz der alten Treiber. Aber: welches sind die alten Treiber? Die Treiber vor 4.1 funktionieren laut Handbuch nicht (und 4.1 hat nur, wer sich des Besitzes eines Falcon 030 erfreut; wer Speedo in der Anfangszeit über COMPO gekauft hat, hat Speedo 4.0)

Also habe ich gleich mit Speedo 5.0, NECP.SYS (Speedo 4.2) und ProList einen Text ausgedruckt. Und siehe da: es funktioniert. Und das, obwohl ProList (und mein eigenes Programm) mit genau diesem Treiber und Speedo 4.2 Probleme hatte.

Der Ausdruck mit den Treibern von Speedo 4.0 dürfte schon deshalb nicht funktionieren, weil sich seit 4.2 die Aufgabenverteilung zwischen SpeedoGDOS selbst und den Treibern grundlegend verändert hat. (Könnte mal jemand die 4.1- Treiber mit SpeedoGDOS 5.0 testen? Ich kann es noch nicht so recht glauben, daß das tut.)

Ich stelle mir ein Upgrade jetzt so vor (Achtung, Satire):

Kunde: Sehr geehrter Herr Compo, [...] aber meine Treiber von Speedo 4.0 funktionieren nicht mehr.

Compo: ...gratulieren Ihnen zu Ihrer Entscheidung...

Aber: Speedo 4.2 ist keine offizielle Version. Sie ist speziell für Papyrus gemacht und mit anderen Programmen nicht sinnvoll. Andererseits...dennoch...so betrachtet...eigentlich...vielleicht eventuell...Jedenfalls brauchen Sie die Treiber von Speedo 4.2. Diese vertreiben wir aber prinzipiell nicht. Sie können sich aber an R.O.M. wenden.

Kunde: Sehr geehrter Herr R.O.M., ... möchte ich ein Downgrade, und zwar umsonst.

R.O.M.: ... geht nicht...Selbstkostenpreis...laber...sülz...nehmen Sie doch lieber auf NVDI 3.0.

Kunde: "]$&"]$/(!]&!^#

Jedenfalls bin ich gespannt, von COMPO zu erfahren, wie Kunden, die bisher SpeedoGDOS 4.0 hatten, in Zukunft drucken sollen.

Bisherige Versionen: Speedo 5.0a vom 3.8.94 Erste vertriebene Version.

Speedo 5.0b vom 8.8.94 Ab dieser Version funktioniert das Laden von T1- und TT-Fonts schneller.

Bekannter Bug: Nach dem Aufruf von vqt headerinfo() werden die Files nicht mehr geschlossen. Bei Programmen, die diese Funktion für alle Fonts aufrufen, kann das dazu führen, daß die Filehandles ausgehen, von denen je nach TOS-Version unterschiedlich viele zur Verfügung stehen.

Seit SpeedoGDOS 4.2 funktioniert das Attribut Outline nur unter gewissen Umständen. Ob es funktioniert hängt ab vom verwendeten Font, der SpeedoGDOS-Version, der Punktgröße und davon, welche Formeln man bei Vollmond murmelt.

Speedo 5.0c vom ??.8.94 Ab dieser Version funktioniert LOWMEM=0 wie im Handbuch beschrieben.

16.3.4 NVDI bis Version 2.51

NVDI bis 2.51 bestand aus sehr schnellen Bildschirmtreibern und einem sehr schnellen GDOS. Im Vergleich zum Atari-GDOS hatte es praktisch keine Fehler. Allerdings war der Funktionsumfang kaum größer.

Diese Version zu verwenden ist im Zusammenhang mit SpeedoGDOS 5.0 immer noch sehr sinnvoll.

16.3.5 NVDI 3.0

NVDI kann ab der Version 3.0 auch Vektorfonts im Speedo- und TrueType-Format verarbeiten. Im Gegensatz zu SpeedoGDOS fehlt hier das Type 1-Format. Die Behnes sagen (zu Recht!), daß dieses Format von den dreien am wenigsten kann und NVDI nur aufblähen würde. Dennoch werden viele Spezialfonts nur im Type 1-Format angeboten und auch ich könnte einige davon brauchen. Seit es aber Multiple Master fonts gibt (siehe 10.4.1), überzeugt mich diese Entscheidung nicht mehr so sehr.

Eine Konversion der Formate ist zwar (im Prinzip sogar in sehr guter Qualität) möglich. Aber das ist sehr schwierig (vergl. Kapitel 10.8) und auf Ataris gibt es überhaupt noch kein solches Programm. Diese Entscheidung der Behnes hat also Vor- und Nachteile.

Die Druckertreiber sind in 6.8.3 aufgeführt.

(Mir) bekannte Fehler und Probleme:

• NVDI-Versionen bis 3.01 berücksichtigen nicht das Pixelgrößenverhältnis (Aspect Ratio) bei der Ausgabe von Kreisen und Ellipsen. Ist mit 3.02 behoben.

• v clswrk nach vqt devinfo auf eine physikalische Workstation führt zu einer Privileg-Violation unter MultiTos. Dieser Fehler wird mit Version 3.02 behoben werden.

• Das Charakter-Mapping ist inkompatibel zu SpeedoGdos 5.0

• Wenn bei der Installation die Platte voll ist, gibt es keine Fehlermeldung. Dieser Fehler ist seit November ’94 behoben.

• Das Cache-CPX verursacht unter MTOS eine vemory violation. Dieser Fehler ist mit Version 3.02 behoben.

• Die gedrehte Textausgabe funktioniert bei manchen Zeichensätzen (z.B. MONACO08.FNT) nicht, die Zeichen werden immer im 0-Grad-Winkel ausgegeben und Bitmap-Fonts werden bei einer Größe von 8 und weniger Punkten nicht hell dargestellt, obwohl das Attribut eingeschaltet ist. Der Fehler trat im monochromen Treiber in der 8pt-Systemfontausgabe auf; mit anderen Bitmap-Fonts (und in anderen Bittiefen) nicht. Diese Fehler sind seit 10.11.94 behoben.

• Die Funktion vqt fontheader liefert bis 3.01 keinen korrekten TDF-Pfad zurück. Mit 3.02 behoben.

• Die Position von Vektorzeichen wird nicht korrekt ermittelt, wenn ein Skew-Winkel eingestellt ist. Sobald ein Skew-Winkel eingeschaltet ist, wird der Text je nach Vorzeichen des Winkels nach rechts oder links verschoben, was bei SpeedoGDOS nicht der Fall ist. Dieser Fehler ist mit Version 3.02 behoben.

• Unter MiNT ist der Speicherbereich, auf den das NVDI-Cookie von NVDI 3.0x zeigt, schreib- und vor allem lesegeschützt. (Behaupten einige wenige Programmierer, ist aber laut Wilfried Behne falsch. Ich selbst kann das mangels MMU nicht prüfen.)

• NVDI 3.02 füllt beim Aufruf von vqt info (VDI 229) die Variable ”style“ nur bei manchen Schnitten.

Doku für Programmierer: [Beh95]. Dort ist auch ein Patchprogramm enthalten für NVDI 3.x enthalten.

16.3.6 NVDI 4.0

Auf der ProTOS im Herbst ’95 wurde NVDI 4.0 verkauft.

Neu ist die Unterstützung von Type 1-Schriften als separates Modul, so daß es keinen Speicher benötigt, wenn es nicht gebraucht wird (vergl. 10.4).

Ebenfalls neu ist die Unterstützung von UNICODE (vergl. 21.3.4).

16.3.7 NVDI 4.11

Das Update bei 2B kostet 39 DM, das Crossgrade für MagicMac 79 DM. Letzteres läuft auch auf dem Atari. Wer sich sowieso einen Mac kaufen will, kann also gleich die Mac-Version nehmen und sich so 39 DM plus Versandkosten sparen. Alle Preise wie immer ohne Gewähr.

Zu dieser Version gibt es ein aktualisiertes nvdiguid [Beh95].

Für Programmierer: es gibt lediglich zwei neue Funktionen, die zunächst recht harmlos aussehen: VDI 190 vqt char index() und VDI 236 vst map mode(). Erst durch diese Funktionen aber lassen sich die kompletten 16-Bit-Zeichensätze sinnvoll nutzen, die im Prinzip schon ab SpeedoGDOS 4.0 zur Verfügung stehen. Erweitert wurden vro cpyfm() und vrt cpyfm().

Eine weitere neue Funktion, die der Programmierer gar nicht bemerkt (das sind die besten) ist die Gamma-Korrektur. Hier können für jeden Treiber getrennt Farbkorrekturen eingestellt werden.

Neu ist auch das Tool Fontname, mit dem Fonts verwaltet und Beispiele angezeigt werden können. Alle beiliegenden Programme nutzen WDIALOG um ihre Dialoge aufzupeppen. Dieses Programm muß in den AUTO-Ordner und stellt stellt die erweiterten Dialogfunktionen von MagiC auch unter einem normalen TOS zur Vefügung. Bei Installationsproblemen kann es sinnvoll sein, WDIALOG aus dem AUTO-Ordner zu entfernen oder seine Position zu verändern.

16.4 Kommentare

Mit der Geschwindigkeit der Entwicklung kann man als Anwender und Programmierer eigentlich zufrieden sein. Auch die Vielzahl von Fontformaten, die den Programmen gleichzeitig zur Verfügung stehen, sucht (als Teil des Betriebssystems) auf anderen Plattformen seinesgleichen.

Die Geschwindigkeit, mit der SpeedoGDOS 5.0a bis 5.0c offensichtlich ohne große Betatestphase herausgekommen sind, ist zwar ärgerlich. Es ist aber andererseits schön zu sehen, wie die Konkurrenz durch NVDI 3.0 den Programmierern Beine macht.

SpeedoGDOS 5.0 macht einigen Programmen, die mit SpeedoGDOS 4.x noch einwandfrei zusammengearbeitet haben, Probleme. Vieles liegt wohl daran, daß SpeedoGDOS 5.0 für die neuen Formate negative Handles liefert. Eigentlich sollte man mit Handles nicht rechnen, aber einige Programme machen es wohl trotzdem. Das Problem soll dadurch umgangen werden, das̈ die Handles in Zukunft als unsigned integer (SHORTCARD) interpretiert werden sollen.

Die mitgelieferten Handbücher zu SpeedoGDOS 5.0 und NVDI 3.0 sind für Programmierer nur ein schlechter Witz. Aber auch mit ganz normalen Anwenderfragen wird man sitzengelassen. Beispiel: Es werden TrueType- (und bei SpeedoGDOS auch Type 1-) Fonts verarbeitet. Nun sind die Fonts aber jeweils wieder in plattformspezifischen Darstellungen gespeichert. Welche werden denn nun verarbeitet und welche Files mit welchen Extentions werden benötigt? Ohne diese Information kann man mit beiden Programmen ziemlich wenig anfangen.

Die vorläufige Funktionsbeschreibung zu NVDI 3 [Beh95] ist Public Domain und in FTP-Servern und Mailboxen erhältlich. COMPO hat für SpeedoGDOS dasselbe versprochen.

Beim Update auf SpeedoGDOS 5.0 konnte jeder auf Anfrage eine provisorische Programmierdoku gratis bekommen. Man mußte nur wissen, daß man danach fragen kann. Sorry, daß das so spät im FAQ stand, ich wußte es auch nicht. Auch jetzt bekommt man sie noch (in Deutschland gegen einen mit 3DM frankierten A4-Umschlag). Sie ist in 90% englisch und 10% deutsch geschrieben. So wird sie auch in englischsprachigen Ländern verschickt.

Hier noch einige Unterschiede zwischen NVDI 3.0 und SpeedoGDOS. Der Leser mag selbst seine Schlüsse daraus ziehen.

• Das Treiberkonzept. Ein klares Plus für NVDI 3.0. Die Treiber sind klein, schnell und vom Anwender leicht an neue Drucker anzupassen. Allerdings lassen sich die Anpassungen nicht von Anwender zu Anwender kopieren (es steht alles in einem File).

• Drucken in Dateien. Die NVDI-Treiber können (im Gegensatz zu den SpeedoGDOS-Treibern) in eine Datei drucken, ohne daß das Programm es merkt.

• Der Speicherbedarf. NVDI 3.0 benötigt bei gleicher Cachegröße praktisch genausoviel Speicher wie SpeedoGDOS 5.0 und NVDI 2.5 zusammen.

• Installation. Für den Anfänger ist die Installation von NVDI 3.0 etwas einfacher als die von SpeedoGDOS 5.0. Das große Aber: NVDI 3.0 überschreibt gnadenlos und ohne zu fragen alles, was genauso heißt, wie die Files von NVDI 3.0: META.SYS und die Bildschirmtreiber des alten NVDI 2.5. Damit ist es extrem schwierig, zu Testzwecken verschiedene GDOS-Versionen auf Platte zu halten. Das betrifft vor allem Programmierer, und denen kann man folgende Abhilfe zumuten: Einfach vor der Installation den AUTO- und den GEMSYS-Ordner umbenennen. Danach kann man damit machen, was man will.

• bis November ’94 weist das NVDI-Installationsprogramm nicht darauf hin, wenn die Installation mangels Plattenplatz unvollständig war.

• Geschwindigkeit des VDI. NVDI 3.0 ist leicht schneller als SpeedoGDOS 5.0 + NVDI 2.5, und das ist wiederum deutlich schneller als SpeedoGDOS 5.0 alleine. Mit SpeedoGDOS 5.0 + NVDI 2.5 läßt es sich schon angenehm arbeiten. Wenn die verwendeten Fonts in die Caches passen, ist diese Kombination subjektiv etwa gleich schnell wie mit NVDI 3.0.

• Geschwindigkeit des Fontscalers: Entgegen der Aussage im (deutschen) FAQ 2.4 haben die Behnes die 4in1-Sourcen von Bitstream direkt übernommen (und das letzte Update von Bitstream in 2 Stunden eingebaut). Die Ursache für die Langsamkeit von SpeedoGDOS ist also nicht beim Scaler zu suchen.

• Bugs. Hier ändert sich der Status laufend. Ich weiß nicht, wer zur Zeit mehr Fehler ausliefert.

• Zahl der Formate. Beide beherrschen Speedo und TrueType. SpeedoGDOS 5.0 beherrscht zusätzlich Type 1. Einzelne Schnitte in diesem Format sind zwar oft sehr teuer, es handelt sich dann aber meist um Spezialfonts, die anders nicht zu bekommen sind.

• NVDI meldet sich (über cookie) an, als sei es SpeedoGDOS 5.0 - kompatibel, ist es aber nicht. Allerdings ist SpeedoGDOS 5.0 genausowenig SpeedoGDOS 5.0 - kompatibel, d.h. es gibt mehrere Versionen davon (mit unterschiedlichem Funktionsumfang bzw. Opcodes) und keine davon ist dokumentiert. Schlimmer noch: Einige SpeedoGDOS 5.0-Versionen haben einige Funktionen experimentell implementiert und man darf sie nicht verwenden. Und das obwohl bisher immer dokumentiert war, daß man VDI-Funktionen einfach aufrufen darf, um zu testen, ob sie da sind.

17 Source

Als Entwickler kann man einen fast fertigen Druckertreiber im Objectcode bekommen. Dieser muß dann nur noch an den speziellen Drucker angepaßt werden.

Dieses Paket gibt es sowohl für GDOS als auch für SpeedoGDOS.

18 Tips und Tricks für Anwender

18.1 Pixelmüll beim Drucken

Beim Ausdruck von Graphiken mit hohem Schwärzungsgrad in einer Zeile auf dem NEC P6+ (vielleicht auch auf anderen Druckern) ist es mir öfters passiert, daß eine Druckzeile übersprungen wurde (SpeedoGDOS-Treiber NB15, NECP) beziehungsweise, daß zweimal versetzt über die Druckzeile gedruckt wurde (SpeedoGDOS-Treiber FX80, NX1000).

Das passiert sowohl bei direkter Ausgabe als auch mittels CENSPEED. Durch Verwendung des Spoolers VARSPOOL tritt dieser Effekt nicht mehr auf.

VARSPOOL befindet sich auf der Treiberdiskette der NEC-Drucker.

18.2 NEC P6+

Irgendwann fängt ein NEC P6+ an zu rattern. Wenn man die vordere Klappe aufmacht, sieht man eine etwas über einen Zentimeter dicke runde Führungsstange. Auf diese ist etwa einmal im Jahr zwei Tropfen Nähmaschinenöl zu applizieren. Später wird dies auch für die U-Förmige Führungsstange notwendig.

Nähmaschinenöl gibt’s bei Muttern.

18.3 HP DeskJet 550C, 560C und DeskWriter 510, 520

Bei Geräten, die zwischen Juni 93 und März 94 produziert wurden, verweigern die Andruckrollen zeitweise den Dienst. Registrierte Nutzer erhalten die Ersatzteile zugeschickt.

18.4 Überschriebene Speedo-Schnitte

Es passiert manchmal, daß SpeedoGDOS in Schnittdateien schreibt, was die wunderlichsten Effekte zur Folge hat. Ich habe für diesen Fall außer GEMSYS noch einen zweiten Ordner mit den Speedoschnitten auf Platte. Wenn dann mal wieder unerklärliche Effekte auftreten, kopiere ich diese Schnitte in den GEMSYS-Ordner. Das hilft in fast allen Fällen.

Diesen Effekt habe ich seit SpeedoGDOS 5.0 nicht mehr reproduzieren können.

19 Tips und Tricks für Programmierer

19.1 Fontgröße und Pixelgröße

Hier geht es um meine Erfahrungen mit GDOS und WYSIWYG. Mein Dank gilt Ulrich Roßgoderer, der diese bestätigt hat.

Es geht im Folgenden um die Ausgabe von Vektorgraphik und Text auf Bildschirm und Drucker.

Die Größenangabe des Textes geschieht in der Einheit Punkt und ist unabhängig von der Auflösung des Ausgabegerätes immer gleich.

Die Vektorgraphik dagegen ist vor der Ausgabe in Pixel umzurechnen. Das ist an sich kein Problem, denn beim Öffnen der virtuellen/physikalischen Workstation erhält man die Pixelgröße in Mikrometern in devParm[3] und devParm[4] zurück.

Nehmen wir an, die Vektorgraphik sei intern in Mikrometern abgespeichert, dann sind bei der Ausgabe die Stützpunkte einfach durch devParm[3] bzw. devParm[4] zu teilen, um die Position in Pixeln zu erhalten. Bei der Ausgabe in Fenstern ist noch ein Offset hinzuzuaddieren, was hier aber nicht relevant ist.

Soweit die Theorie, die bisher ganz einfach ist (siehe auch [Gar93]). Nun zur Praxis.

Mit dieser Methode geben wir nun einen Text und einen Rahmen, der intern als Vektorgraphik gespeichert ist, aus. Es ist dabei irrelevant, ob der Text mit SpeedoGDOS oder als Bitmap-Font ausgegeben wird. Um besser vergleichen zu können, soll der Rahmen den Text exakt umschließen.

Ich habe nun folgende Erfahrungen gemacht. Der Text, der auf dem Bildschirm (ST-high) den Rahmen genau ausfüllt, ist beim Ausdruck im Vergleich zum Rahmen viel zu klein.

Ein Fehler bei der Umrechnung der Pixelgröße ist auszuschließen, denn ich habe den Ausdruck mit den Treibern NB15, NECP, FX80 und NX1000 gemacht, und die Ausdrucke decken sich.

Einzig mögliche Erklärung, die mir einfällt, ist, daß der Bildschirmtreiber für die Pixelgröße eine andere Auflösung annimmt, als für die Fontgröße.

Zwei Lösungen des Problems sind hier anwendbar:

Erstens kann man auf dem Bildschirm eine andere Pixelgröße annehmen, als vom Betriebssystem geliefert wird. Ich habe nach dem Öffnen der virtuellen (und nur dieser!) Workstation devParm[3] := 282; devParm[4] := 282; berechnet und mit diesem Wert die Umrechnung der Vektorgraphik von Mikrometer in Pixel vorgenommen. Jetzt stimmt das Verhältnis von Graphik zu Text auf dem Bildschirm exakt mit dem Ausdruck über die verschiedenen Druckertreiber überein. Problematisch ist nur, daß eine A4-Seite in der Breite nicht mehr auf den Bildschirm paßt. Die Zahlenwerte sind experimentell bestimmt und können eventuell noch verbessert werden.

Zweitens kann man für den Bildschirm (und nur dort) einfach eine kleinere Fontgröße verwenden. Mit Speedofonts ist das ganz einfach, da man ja die Göße in Punkten mit fast beliebig vielen Nachkommastellen angeben kann. Mit Bitmapfonts kann das aber nicht klappen, da man nicht für jeden Druckerzeichensatz einen in der 72/96 (72/91?) -fachen Größe für den Bildschirm hat.

Diese Methode ist sicher für ST-mid und evtl. noch bei anderen Auflösungen zu modifizieren.

Laut Wilfried Behne werden die Werte devParm[3] und devParm[4] der Bildschirmtreiber vom aktuellen SpeedoGDOS schlicht ignoriert. Die Werte von physikalischen Workstations werden aber übernommen.

Siehe auch Kapitel 10.7.4.

19.2 Treiberauswahl

Meine Tests verschiedener GDOS-Programme haben ergeben, daß doch einige Programmierer mit Folgendem Probleme haben:

Die Anwender können in der ASSIGN.SYS beliebige Treiber anmelden. Beispielsweise könnte dort 23 FX80.SYS 27 NECP.SYS 28 NB15.SYS 31 META.SYS 61 MEMORY.SYS stehen. Wie bekommt man als Programmierer sicher heraus, welche Treiber angemeldet (und auch bereit) sind? Und das, obwohl im Beispiel kein Drucker 21 angemeldet ist? Ganz einfach: Unterstützt das Programm Drucker, so sind alle Treiber mit Nummer 21 bis 30 zu öffnen und gleich wieder zu schließen. Ob ein Druckertreiber angemeldet ist, sieht man daran, daß beim Öffnen ein Devicehandle≫ 0 zurückgegeben wird. Nur bei geöffnetem Treiber liefert v f devinfo sinnvolle Werte zurück.

Werden MEMORY-Treiber unterstützt, ist mit den Treibernummern 61 bis 70 analog zu verfahren.

Die obige ASSIGN.SYS ist im übrigen sehr sinnvoll, da die NEC P irgendwas all diese Treiber unterstützen und dann in unterschiedlicher Auflösung drucken.

19.3 Das Metafile-Format

Ich wurde gebeten, einmal aufzuzählen, was ich über Metafiles so alles nicht weiß 8-))).

Das Metafile-Format ist von der Idee her ganz einfach. Es enthält die Aufzeichnung der VDI-Aufrufe samt Parameter, die ein Programm macht.

Ein Programm, das sowieso seine Ausgaben über GDOS macht, öffnet statt eines Druckertreibers einen Metafile-Treiber (siehe 6.8), und macht seine Ausgaben wie auf einen Drucker.

Das Programm, das das Metafile liest, vollzieht diese Aufzeichnungen dann nach.

Diese Einfachheit ist auch eines der Hauptprobleme dieses Formats. Es gibt nämlich verschiedene GDOS-Versionen und auch verschiedene Treiber mit unterschiedlichen Fähigkeiten. Ein Programm macht also Ausgaben, die das GDOS, unter dem es gerade läuft, versteht. Dieses File wird von einem Programm gelesen, das zufällig unter einem anderen GDOS mit geringeren oder anderen Fähigkeiten läuft. Wie soll die Aufzeichnung dann nachvollzogen werden?

Konkrete Beispiele für dieses Problem: Die Länge der ptsin- und intin- Felder ist normalerweise (für verschiedene Treiber unterschiedlich) begrenzt. Dies kann der Metafile-Treiber anders handhaben. Betroffen sind unter anderem Textausgabe, Polyline, Polymarker, Filled area etc.

Nächstes Problem: es wird ein bestimmter Schnitt verwendet, der dann auf einem anderen System nicht vorhanden ist. Wie soll das Ausgabeprogramm sagen: wenn der Schnitt schon nicht vorhanden ist, nimm wenigstens einen anderen halbfetten mit Serifen.

Der Programmierer sollte wenigstens (wenn möglich) den Schnitt durch den Namen und nicht durch die ID auswählen, weil NVDI 3.0x und SpeedoGDOS für Vektorfonts unterschiedliche IDs verwenden. Wird mit SpeedoGDOS 5.0 oder neuer ein Schnitt durch die ID ausgewählt, so schreibt der META-Treiber den Namen automatisch mit ins File.

Bei den bisherigen Problemen kann man sich auf den Standpunkt stellen, daß das ein Problem der Graphikprogramm-Programmierer ist, und die werden schon wissen, was sie tun.

Beim Schreiben des Metafile-Headers muß man allerdings wissen, was man tut. Ich weiß es nicht. Aber ich versuch’s trotzdem mal. Eine Applikation kann selbst entscheiden, mit welcher Auflösung (also mit wieviel dpi) sie in ein Metafile schreibt. Tut sie das nicht, werden 300 dpi angenommen, was einer Pixelbreite von 85 mikrometern entspricht. Die Bildschirmtreiber beherrschen nur Rasterkoordinaten. Da zur Ausgabe über Metafile üblicherweise dieselben Routinen verwendet werden, beschränken wir uns im Folgenden auf Rasterkoordinaten (Auch wenn Metafiles auch NDCs beherrschen). Rasterkoordinaten gehen von links oben nach rechts unten.

Um ein Koordinatensystem zu definieren, wird bei Metafiles wie folgt vorgegangen:

• mit vm pagesize werden Breite (W) ind Höhe (H) der Seite in zehntel Millimeter angegeben. Dies ist die (positive) Differenz zwischen dem Punkt rechts unten und dem Punkt links oben (der nicht im Ursprung liegen muß).

• mit vm coords das Rechteck (xmin, ymin, xmax und ymax) in Pixeln angegeben. Wie man dieses Rechteck berechnet, steht weiter unten.

• in dem so definierten Koordinatensystem wird mit v meta extents ein Rechteck in Pixeln angegeben. Dieses Rechteck hat mit der Definition des Koordinatensystems nichts zut tun. Vielmehr ist es eine Angabe, wie die Applikation, die das Metafile liest, clippen kann, aber nicht muß. Anmerkung: papyrus clipt nicht. KandinskYclipt, verschiebt aber vorher die Graphik etwas nach rechts unten, so daß auf dem Bildschirm ein Teil der Graphik fehlt. Es könnte deshalb sinnvoll sein, das Rechteck für v meta extents etwas größer zu wählen, als das Rechteck für vm coords.

Damit ist das Koordinatensystem und die Auflösung (Breite und Höhe eines Pixels) eindeutig bestimmt.

Aber die angegebenen Variablen sind nicht die, mit denen eine Applikation üblicherweise rechnet. Es folgt ein Beispiel, wie zu verfahren ist, wenn die Applikation die gewünschte Auflösung in dpi kennt, die Position des linken oberen Punktes (X1,Y1) in zehntel Millimetern (oder einem Vielfachen davon) und die Position des rechten unteren Punktes (X2,Y2) in zehntel Millimetern (oder einem Vielfachen davon).

So berechnet man aus der Auflösung die Höhe und Breite eines Pixels: (Pixelhöhe in zehntel Millimeter) = 25400 / (vertikale Auflösung in dpi) (Pixelbreite in zehntel Millimeter) = 25400 / (horizontale Auflösung in dpi)

Für vm pagesize werden Breite und Höhe in zehntel Millimetern benötigt: W = (X2 - X1 + 1) * (Pixelbreite in zehntel Millimeter) H = (Y2 - Y1 + 1) * (Pixelhöhe in zehntel Millimeter)

Für vm coords werden xmin, ymin, xmax und ymax in Pixeln gebracht: xmin = X1 / (Pixelbreite in zehntel Millimeter) ymin = Y1 / (Pixelhöhe in zehntel Millimeter) xmax = X2 / (Pixelbreite in zehntel Millimeter) ymax = Y2 / (Pixelhöhe in zehntel Millimeter)

Für v meta extents wird vorgegangen, wie bei vm coords. Zusätzlich können xmin und ymin etwas verkleinert und xmax und ymax etwas vergrößert werden, damit KandinskYalles anzeigt.

Selbstverständlich muß das Koordinatensystem definiert werden, bevor weitere Ausgaben in das Metafile gemacht werden.

(Mir ist in letzter Zeit mehrfach aufgefallen, daß ich etwas so gut erklärt habe, daß ich es danach sogar selbst verstanden habe 8-)

Weitere Informationen (die aber bei den oben genannten Problemen nicht helfen) stehen im Profibuch [Jan92], im Atari Compendium [San94] und im Standardwerk über Fileformate [Bor94]. Ansonsten hilft noch jede Literatur, in der die VDI-Befehle beschrieben sind.

20 Erweiterte Sub-Opcodes für Metafiles

Eine wichtige Eigenschaft von Metafiles besteht darin, daß das lesende Programm unbekannte Anweisungen zu ignorieren hat. Gleichzeitig darf ein Programm beliebige Sub-Opcodes verwenden, die mit v write meta ins Metafile geschrieben werden können.

Das jetzt folgende war einmal als Standard gedacht, ist aber eingeschlafen. Vielleicht war damals die Zeit nur noch nicht reif dafür (es gab noch kein SpeedoGDOS) und es fehlte das entsprechende Medium, um ihn publik zu machen.

Die nun folgende Definition sollte zumindest dahingehend unterstützt werden, als die Sub-Opcodes nicht für andere Zwecke gebraucht werden sollten. Wenn Programme diese Definition unterstützen, bitte ich um eine Meldung.

Ab hier folgt ein Auszug aus dem KandinskY-Handbuch:

Wie schon öfters erwähnt, lädt und speichert KandinskY Zeichnungen im *.GEM-Standardformat (ist gleichbedeutend mit Metafile-Format).

Dieses Format kann durch benutzer-definierte Sub-Opcodes nahezu beliebig erweitert werden, ohne daß Inkompatibilitäten entstehen.

KandinskY verwendet einige spezielle Sub-Opcodes, um z.B. die fein abgestuften Grautöne, Fensterpositionen etc. abzuspeichern und wieder zu laden. Daneben werden die mir bekannten standardisierten Sub-Opcodes unterstützt.

Die Speicherroutinen von KandinskY sind dabei so programmiert, daß ein Programm, das eine Zeichnung aus KandinskY importieren will, diese Sub- Opcodes nicht unbedingt verstehen muß. In der Darstellung selber sollte daher kein Unterschied zu erkennen sein. Probleme kann es dann geben, wenn ein Programm einen Sub-Opcode falsch interpretiert, weil es zu Wert”=Überschneidungen kommt.

Sollten daher Sie, verehrter Leser, auch eigene Sub-Opcodes benutzen, wäre es doch nicht schlecht, wenn Sie mir diese mit einer kurzen Beschreibung mitteilen würden. Denn die Verwendung dieser Erweiterung ist nur sinnvoll, wenn Sub-Opcodes mit gleichem Wert von allen Programmen, die Metafiles verarbeiten, gleich interpretiert werden. Mir schwebt dabei eine Liste vor, in der alle verwendeten Sub-Opcodes mit ihrer Bedeutung beschrieben sind (ähnlich der XBRA-Liste).

Zur Verwendung der Sub-Opcodes siehe auch im ST-Profibuch im Kapitel über die VDI-Betriebssystem-routinen. Besonders zu beachten ist hier der Befehl v write meta, mit dem die Sub-Opcodes in ein Metafile geschrieben werden können.

20.1 Die unterstützten Sub-Opcodes

Hier zunächst eine Kurzübersicht über die unterstützten Sub-Opcodes. In der Tabelle 1 sind dabei die vorgeschlagenen Namen, ihre verbindlichen Werte und die Wirkung in Kürze beschrieben.

Name  Wert Kurzbeschreibung
GEM START GROUP  10 Beginn einer Gruppe
GEM END GROUP  11 Ende einer Gruppe
GEM NO LINE STYLE  49 Jeglichen Linienstil ausschalten
GEM START SHADOW  50 Beginn eines Objektschattens
GEM END SHADOW  51 Ende des Schattens
GEM START FILL  80 Beginn einer Füllfläche
GEM END FILL  81 Ende derselbigen
GEM START BGIF  170 Beginn von BGI-Vektortext
GEM END BGIF  171 Ende des Vektortextes
GEM WIND  190 Fensterposition, Zoomstufe usw.
GEM GRID  191 Rastereinstellungen
GEM ALIGN  192 Informationen über Bezugsobjekt
GEM START GREY  193 Beginn eines Grautons
GEM END GREY  194 Ende desselbigen
GEM START BEZIER  195 Beginn eines Bźier-Zuges
GEM END BEZIER  196 Ende des Zuges
GEM START JOIN  197 Die folgenden Blöcke gehören zusammen
GEM END JOIN  198 ...ab hier nicht mehr

Tabelle 1: Sub-Opcode Übersicht

20.2 Die Gruppeninformation

Mit GEM START GROUP wird der Beginn einer Gruppe markiert. Eine Gruppe ist dabei eine Menge zusammengehörender Objekte. Das Ende dieser Gruppe wird durch GEM END GROUP markiert.

20.3 Der Objektschatten

Mit GEM START SHADOW wird mitgeteilt, daß die bis GEM END SHADOW folgenden VDI-Befehle dazu benutzt werden, um für das erste Objekt nach GEM END SHADOW einen Schatten zu zeichnen.

20.4 Die Füllfläche

Da die Umrandung bei den VDI-Flächen nicht immer korrekt gezeichnet wird, gibt es die Codes GEM START FILL und GEM END FILL. Alle zwischen ihnen liegende VDI-Befehle werden dazu benutzt, um eine ausgefüllte Fläche mit oder ohne Umrandung zu zeichnen.

Beispielhaft soll hier das schrittweise Zeichnen einer Polygonfläche mit Schatten und Umrandung gezeigt werden.

• GEM START FILL

• GEM START SHADOW • Setzen der Füllattribute für den Schatten

• v fillarea(...) versetzt um dx und dy

• GEM END SHADOW

• Setzen der Füllattribute der eigentlichen Fläche

• v fillarea(...)

• Setzen der Linienattribute für die Umrandung

• v pline(...)

• GEM END FILL

20.5 Der Vektortext

Mit GEM START BGIF wird eine Textausgabe mit BGI- Vektorzeichensatz eingeläutet. Die VDI-Arrays sind dabei wie folgt belegt:

intin[0]  GEM START BGIF
intin[1]  0: nicht proportional
intin[2..10] Name, z.B. EURO: intin[2] = 69 ...
intin[11..] Der Text mit abschließender Null
ptsin[0]  x-Koordinate des Textes (in \frac{1}{10}mm)
ptsin[1]  y-Koordinate des Textes (in \frac{1}{10}mm)
ptsin[2]  Buchstabenbreite in \frac{1}{10}mm
ptsin[3]  Buchstabenhöhe in \frac{1}{10}mm
ptsin[4]  Rotation in \frac{1}{10}^{∘}

Bis GEM END BGIF folgen die v pline(...)-Befehle, die zur Darstellung des Textes notwendig sind, falls ein Programm diese Sub-Opcodes nicht interpretieren kann.

20.6 Die Fenstereinstellungen

20.6.1 Fensterposition Mit GEM WIND werden Position, Zoomstufe und Format des Fensters festgelegt.

intin[0] GEM WIND
intin[1] x-Position des Fensters in Pixel
intin[2] y-Position des Fensters in Pixel
intin[3] Fensterbreite in Pixel
intin[4] Fensterhöhe in Pixel
intin[5] x-Position des Sliders in Pixel
intin[6] y-Position des Sliders in Pixel
intin[7] Zoomstufe in Prozent
intin[8] 0: Hochformat, 1: Querformat
ptsin[...] keine Einträge

20.6.2 Rastereinstellungen

Die Rastereinstellungen eines Fensters werden mit GEM GRID dauerhaft gesichert.

intin[0] GEM GRID
intin[1] 0: Raster inaktiv
intin[2] 0: Raster nicht zeichnen
intin[3] Rasterbreite in \frac{1}{10}mm
intin[4] Rasterhöhe in \frac{1}{10}mm
intin[5] Hilfslinienabstand horizontal in \frac{1}{10}mm
intin[6] Hilfslinienabstand vertikal in \frac{1}{10}mm
intin[7] 0: Hilfslinien, ansonsten: Hilfspunkte
ptsin[...] keine Einträge

20.6.3 Bezugsobjekt

Durch den Sub-Opcode GEM ALIGN wird das Bezugsobjekt beschrieben.

intin[0] GEM ALIGN
intin[1] 0: Bezugsobjekt nicht zeichnen
intin[2] x-Koordinate des Bezugsobjekts in \frac{1}{10}mm
intin[3] y-Koordinate des Bezugsobjekts in \frac{1}{10}mm
intin[4] Breite des Bezugsobjekts in \frac{1}{10}mm
intin[5] Höhe des Bezugsobjekts in \frac{1}{10}mm
ptsin[...] keine Einträge

20.7 Die Grautöne

Mit GEM START GREY legt man einen Grauton als Füllfläche fest. Abstufungen im Bereich von 0—255 (weiß—schwarz) sind möglich.

intin[0] GEM START GREY
intin[1] Graustufe, 0—255
ptsin[...] keine Einträge

Die bis GEM END GREY folgenden Befehle setzen ein benutzerdefiniertes Muster mit dem entsprechenden Grauton. Sie dienen wiederum nur für Programme, die mit diesen Sub-Opcodes nichts anfangen können.

20.8 Bézier-Züge

Mit GEM START BEZIER definiert man einen Bézier-Zug. Sämtliche Information über denselbigen ist in den intin- und ptsin- Feldern zu finden.

intin[0]  GEM START BEZIER
intin[1]  Rekursionstiefe, kleiner als fünf!!
intin[2..2n + 2 − 1] Attribute der Ankerpunkte

Ecke: Bit 0 gesetzt

Verschiebt: Bit 1 gesetzt Sichtbar: Bit 2 gesetzt Linie statt Bézier: Bit 3 gesetzt

ptsin[0..4n − 1]  Koordinaten der n Béziersegmente, jedes besteht

aus vier Punkten Bis GEM END BEZIER folgen dann v pline-Aufrufe, die einen äquivalenten Polygonzug zeichnen, für Programme, die den Sub-Opcode nicht unterstützen.

20.9 Zusammenfassen mehrerer VDI-Blöcke

Mit GEM START JOIN ist es möglich, mehr Koordinaten abzuspeichern, als der Metafile-Treiber erlaubt. Findet KandinskY nämlich diesen Sub-Opcode, so werden die ptsin-Felder der bis GEM END JOIN folgenden VDI-Blöcke zu einem großen Feld zusammengefaßt.

intin[0] GEM START JOIN
intin[1] Anzahl der gesamten Koordinatenpaare
ptsin[...] keine Einträge

Diese Definition ist bisher neben v pline, v fillarea und v pmarker auch für v gtext, v justified, und v ftext gültig. Auch mehrzeiliger Text ist über diese Umgebung speicherbar. Dann gilt folgende Definition:

intin[0] GEM START JOIN
intin[1] Anzahl der folgenden v gtext-Aufrufe

(pro Zeile einer)

ptsin[...] keine Einträge

Erkannt wird die unterschiedliche Definition von intin[1] durch den ersten VDI-Ausgabebefehl, der auf GEM START JOIN folgt.

Hier endet der Auszug aus dem KandinskY-Handbuch.

21 Standards

Hier werden einige Standards aufgelistet, die etwas mit Fonts, Druckern etc. zu tun haben. Dabei soll berücksichtigt werden, was etwas mit GDOS zu tun hat, zu tun haben wird oder zu tun haben sollte.

Auch Fontformate sind Standards, wurden aber in den vohergehenden Abschnitten eingehend besprochen.

21.1 International Color Consortium Profile Format

Am 15. Februar 1995 haben sich die Firmen Adobe Systems Inc., Agfa-Gevaert N.V., Apple Computer, Inc., Eastman Kodak Company, FOGRA (Honorary), Microsoft Corporation, Silicon Graphics, Inc., Sun Microsystems Inc. Taligent, Inc auf das International Color Consortium Profile Format version 3.0a geeinigt. Es handelt sich um ein plattformunabhängiges Format, das die farbtreue Konvertierung zwischen verschiedenen Farbräumen ermöglicht. Die Idee ist, das̈ ein Druckerhersteller (oder Monitorhersteller) für alle Plattformen nur noch ein solches Profile erstellt und damit gewährleistet ist, daß trotz unterschiedlicher Drucktechnologien und Farbräumen bei gleichem Ausgangsfile auch dieselbe Farbe herauskommt. Die oben genannten Hersteller haben sich verpflichtet, diesen Standard bei allen ihren Plattformen und ihren Applikationen zu unterstützen.

Ich behaupte nicht, daß dies auch bei NVDI, SpeedoGDOS oder anderen GDOSen berücksichtigt wird.

Siehe http://www.sgi.com/Technology/icc top.html.

21.2 TIFF

Das International Color Consortium Profile Format ist so gestaltet, das̈ es in PICT, TIFF und EPS-Files eingebaut werden kann. Dabei ist TIFF das einzige nicht proprietäre Format.

Die Spezifikation von TIFF 6.0, früheren TIFF-Versionen und anderen Graphikformaten findet sich in ftp://ftp.funet.fi/pub/csc/graphics/format/tiff*.

21.3 Character Sets

Einer meiner Leser hat mich so lange motiviert, etwas über UNICODE zu schreiben, das̈ ich es auch tatsächlich mache. Es ist allerdings sinnfrei, isoliert über UNICODE oder sonst etwas hier in diesem Kapitel zu schreiben. Wesentlich sind auch die Auswirkungen auf GDOS, ihre Verwendung in den verschiedenen Fontformaten und wie sie in der Praxis in den verschiedenen Formaten und bei Verwendung verschiedener GDOSe aufeinander abgebildet werden. Viele Informationen können daher nicht nur einer Überschrift zugeordnet werden und über die Strukturierung der Information kann gestritten werden. Als Literatur empfehle ich [Mic]. Über Hinweise zu weiterer Literatur wäre ich dankbar.

21.3.1 Glyphen und Ligaturen

Glyphen enthalten die Beschreibung von Objekten innerhalb eines Fonts, die dargestellt werden können. Das sind beispielsweise Buchstaben und Sonderzeichen, aber auch Ligaturen wie ”fi“, die in einem Zeichensatz wie ascii eigentlich nichts zu suchen haben. Wird ein String ausgegeben, das die Zeichen ”fi“ enthält, gibt es Betriebssysteme, die dann automatisch den Glyphen ”fi“ ausgeben und nicht nacheinander ”f“ und ”i“. Das beherrscht aber meines Wissens kein GDOS.

21.3.2 ascii, ISO 646

Es mag sein, daß einmal definiert war, was ascii ist (American Standard Code for Information Interchange), in der Praxis kann man sich aber bis auf A-Z. a-z und einige ganz wenige Sonderzeichen auf nichts verlassen.

ISO 646 definiert einen Zeichensatz, der nur 7 Bits verwendet und daher in der Praxis kaum Bedeutung hat.

21.3.3 ISO 8859

ISO 8859 definiert einige 8-Bit-Zeichensätze, beispielsweise ISO 8859-1 (=Latin 1) für mitteleuropäische Sprachen.

Weitere Beispiele:

8859-1 Europe, Latin America 8859-2 Eastern Europe 8859-3 SE Europe 8859-4 Scandinavia (mostly covered by 8859-1 also) 8859-5 Cyrillic 8859-6 Arabic 8859-7 Greek 8859-8 Hebrew 8859-9 Latin5, same as 8859-1 except for Turkish instead of Icelandic 8859-10 Latin6, for Eskimo/Scandinavian languages

Die ersten 256 Zeichen von UNICODE entsprechen ISO 8859-1.

21.3.4 UNICODE / ISO 10646

UNICODE ist die Beschreibung eines Zeichensatzes und nicht von Glyphen, was zur Folge hat, das̈ es beispielsweise keine Ligaturen enthält (vergl. 21.3.1).

LaTEX macht aus den beiden Zeichen fl ein einziges Zeichen im Zeichensatz. Wenn ein GDOS UNICODE unterstützt, kann das Anwendungsprogramm keine Ligaturen mehr als ein einzelnes Zeichen ausgeben. Es ist also Aufgabe eines GDOS, aus bestimmten Zeichenfolgen wieder einzelne Ligaturen zu machen.

Auf der anderen Seite muß die Ligaturbildung explizit verhindert werden können; hier im FAQ beispielsweise beim Wort Auflösung. Ich tippe explizit ”Auf\/l"osung“, damit es nicht wie Auflösung aussieht.

In UNICODE besteht ein Zeichen aus zwei Bytes. (Stimmt es noch, daß ISO 10646 aus 4 Bytes besteht und UNICODE derjenige Teil davon ist, bei dem die ersten beiden Bytes null sind?)

UNICODE 1.0 gibt es bei Addison-Wesley. Ich habe einen Draft 1.1 vom Juni 1994 gesehen. ist der inzwischen durch?

Eine nicht vollständige Liste von UNICODE-Zeichen (dafür mit Postscript-Name) ist in [Mic]. Dort steht auch, welche Zeichen in einem TrueType-Schnitt vorhanden sein müssen, der sich Windows 3.1-Konform nennt.

21.4 GEM-LIST-Standard

Der sogenannte GEM-LIST-Standard existiert nicht.

From ogal@cix.compulink.co.uk (Ofir Gal) Fri, 18 Nov 1994: The GEM list has approved the following proposal, however, there are a couple of ammendments which I wi post for a vote next week. If anyone has any of their own, please mail them to me.

Fast alle in der GEM-LIST waren sich einig, das̈ der so ”verabschiedete“ Standard ohne Nachbesserungen (amendments) nichts taugt. Die Nachbesserungen wurden in der GEM-LIST aber weder diskutiert noch verabschiedet.

22 Copyrights und Fonts

Dieses Thema ist zu schwierig, um kurze Antworten zu liefern. Aber einige interessante Hinweise habe ich parat. Neben dem Kapitel 10 liefert das Buch [Kar92a] und das Schriftzeichengesetz [D81] reichlich Informationen.

22.1 Bitstream-Fonts in Dokumenten

Karen Dupre (support@bitstream.com) schrieb am 07 Jun 95 17:02:17 est folgendes in comp.fonts (englisches Original, damit mir keiner einen Strick dreht):

We do allow people to include our fonts in Acrobat .PDF files.

The crucial thing here is that the fonts can be used to view the file, print, and do minor editing in the portable document. BUT the fonts must not be extracted from the file then kept or installed by the receiving user.

Acrobat’s embedded fonts are shrouded and cannot be easily extracted for installation at the receiving end, so the use of Bitstream fonts in Adobe Acrobat portable documents (.PDF files) is OK.

We will support any technology or utility that allows people to provide document portability as long as the fonts are not extractable (if that is a word) from the host document or file.

We do not support font embedding if there is a way for users to extract the font from the portable file and install it on their system for their own future use outside of the portable document.

Also kurz auf deutsch: Bitstream-Fonts (egal in welchem Format) dürfen in Text/Graphikdateien gespeichert werden und weitergegeben werden, solange die Fonts vom Endanwender daraus nicht rekonstruiert werden können. Die in diesen Dateien gespeicherten Fonts dürfen aber dazu verwendet werden, die Datei anzusehen und zu drucken.

Es lohnt sich also für Autoren GDOS-fähiger Programme, solche Dateiformate zu entwickeln oder zu unterstützen.

22.2 Urheberrecht

Ich bin kein Jurist, will aber trotzdem Hinweise liefern, welche Konsequenzen das Urheberrecht für Computerprogramme hat.

Historisch haben sich zwei Arten von Schutzrechten entwickelt: das Patentrecht und das Urheberrecht (engl: copyright). Das Patentrecht ist für technische Entwicklungen zuständig, das Urheberrecht für geistige/künstlerische Schöpfungen.

Per Definition sind Computerprogramme dem Urheberrecht unterstellt, was weitreichende Konsequenzen hat. Ausnahmen sind selten, beispielsweise die Steuerung des ABS. US-Amerikanische Softwarehersteller müssen in den USA ein Belegexemplar hinterlegen und einen Copyright-Vermerk anbringen, um ihre Rechte nicht zu verwirken. Nichtamerikaner müssen diese Bedingung nicht einhalten.

Wer Patentschutz in Anspruch nimmt, muß eine intensive und teure inhaltliche Prüfung durchlaufen. Der Patentantrag kann abgewiesen werden. Wenn das Patent erteilt wird, ist der Schutz sehr sicher. Das Urheberrecht gilt mit der Schöpfung des Werkes selbst. Bei Programmen gilt dies auch für die Entwurfsunterlagen, den Sourcecode und das Pflichtenheft. Das Urteil des Bundesverfassungsgerichts, welches eine Schöpfungsh”he verlangt, das über den Fähigkeiten eines durchschnittsprogrammierers liegt, hat sich als nicht praktikabel erwiesen und wird nicht mehr angewandt.

In Deutschland sind im UrheberrechtsG folgende Paragraphen speziell für Computerprogramme zuständig: §69a … g; §137d. Ergänzenden Schutz bietet auch das Gesetz gegen den unlauteren Wettbewerb.

Den Vorteil des Urheberrechts gegenüber dem Patentrecht erkauft man sich damit, daß man sich dieses Rechts erst sicher sein kann, wenn man es vor Gericht erstritten hat.

22.3 Markenrecht

Seit 1.1.1995 gilt in der EG das Markenrecht. Die Marke (darunter fallen beispielsweise Logos und Namen) ersetzt unter anderem das deutsche Warenzeichen.

Marken lassen sich nur für eng umgrenzte Warengruppen schützen.

Die konkreten Auswirkungen will ich an einem Beipiel erläutern. Ich habe mit keiner der beteiligten Parteien rücksprache gehalten.

Da gibt es ein marktbeherrschendes Programm namens EXCEL von Microsoft. Dieser Hersteller könnte sich gegen die Verwendung des Namens TEXEL für ein Tabellenkalkulationsprogramm wehren, weil der Name ähnlich klingt.

Der name TEXEL könnte von ASH ebenfalls geschützt werden um sich seinerseits gegen Nachahmungen zu wehren. Solche Schutzanträge werden nur formal geprüft.

Erst, wenn man sich das Recht vor Gericht erstritten hat, kann man sich dessen sicher sein. Vor Gericht könnte beispielsweise herauskommen, daß sich Microsoft nicht gegen ASH und ASH gegen niemanden wehren kann, weil sich Ortsnamen nicht schützen lassen (Texel liegt in Holland). Wird TEXEL ASH-TEXEL genannt, sieht die Lage völlig anders aus.

Um die Verwirrung komplett zu machen, heißt das Programm offiziell ASH-TEXEL, zeigt selbt aber nur TEXEL an.

23 Adressen

(Vieles gibt es auch beim freundlichen Atari-Händler um die Ecke :-) )

Application Systems Heidelberg (ASH) Postfach 102646 * 69016 Heidelberg Tel.: +49 6221 300002

ATARI (Europa) Postbus 70 * NL-4130 EB Vianen * Holland Deutsche Weiterschaltungsnummer (Auslandsgebühren zahlt ATARI): 06196-801180

Behne & Behne Systemsoftware GbR Lindenkamp 2 * 31515 Wunstorf Tel./Fax.: +49 5031 8629

BELA Computer GmbH: R.I.P.

ByTech GbR Detlef Kuhl, Frank Hieronymi Bismarckstraße 88 * 10627 Berlin Tel.: +49 30 3134258

CCD Dirk Beyelstein Postfach 1164 65331 Eltville Tel: 06123/1094 Fax: 06123/4389

Gerd Castan Höhbergstr. 16 * 70327 Stuttgart G.Castan@physik.uni-stuttgart.de

COMPO Software GmbH Vaalster Str. 540 * 52074 Aachen Tel.: +49 0241 830 98

Delta Labs Media Brillerstraße 40 * 42105 Wuppertal Tel./Fax: +49 202 308307

DigiLab GmbH Posener Str. 18 * 24161 Dänischhagen

Digital DeskTop (DDT) ist eine Händlergemeinschaft Adressen finden sich in Anzeigen der Atari-Zeitschriften.

Digital Systems & Consulting Soester Str. 306 * 59071 Hamm Tel.: +49 2381 889413; Fax.: +49 2381 889812

Elan Software 550 Charest Est P.O. Box 30232 Quebec, G1K 8Y2 Canada Voice: (418) 692-0565; Fax: (418) 683-9189

Dieter Fiebelkorn Grüner Weg 29a * 45768 Marl

Stephan Gerle Ruthstraße 8 * 44149 Dortmund

H3 Systems Häusserstraße 44 * 69115 Heidelberg Tel.: +49 6221 164031; Fax.: +49 6221 184541

Harald und Martin Hansen Weserstraße 82 * 12059 Berlin

Hard & Soft Obere Münsterstr. 33-35 * 44575 Castrop-Rauxel Tel.: +49 2305 18014; Fax.: +49 2305 32463

ICP GmbH & Co.KG Leserservice TOS * Innere-Cramer-Klett-Straße 6 * 90403 Nürnberg 1

Konfect Corp. Vertriebsbüro A-D-CH Postfach 1113 * D-63797 Kleinostheim Tel. +49 6027 99941; Fax +49 6027 99942

MAXON Computer GmbH Schwalbacher Straße 52 * 65734 Eschborn Tel.: +49 6196 481811

Migraph Inc. 32700 Pacific Highway S. Suite 12, Federal Way WA 98003, USA Tel.: 0012068384677

Michael Nolte Computersysteme Vasters Str. 10, 50825 Köln Tel.: +49 221 558269, Fax: +49 221 5504629

no Software GmbH Postfach 1051 54591 Prüm

OMIKRON Soft+Hardware GmbH Sponheimerstr. 12a * 75117 Pforzheim Tel.: +49 7231 356033

Pergamon Software * Lehmann & Herzog Wegscheidestr. 29 * 60435 Frankfurt/Main Tel.: +49 69 5488279 Am Roten Hang 14 * 61476 Kronberg/Ts. Tel.: +49 6173 940063

rhotron GmbH Entenmühlstraße 57 * 66424 Homburg/Saar Tel.: +49 6841 64067; Fax.: +49 6841 2467

Richstein & Dick GbR (Kaktus) Konrad-Adenauer Straße 19 * 67663 Kaiserslautern Tel.: +49 631 22253

Richter Distributor Hagener Str. 65 * 58285 Gevelsberg Te.: +49 2332 2706

Thierry Rodolfo 47 rue Pierre Brossolette 92300 LEVALLOIS France

R.O.M. Software (Neue Adresse !) Christian Nieber & Ullrich Ramps Raschdorffstr. 99 * 13409 Berlin Tel.: +49 30 4924127

RoSoft Stefan Rogel Köhlerweg 1 * 67661 Kaiserslautern Stefan Rogel@LU.maus.de und Stefan Rogel@WI2.maus.de

SciLab GmbH Isestraße 57 * 20149 Hamburg Tel.: +49 40 4603702 SHIFT Computer + Werbung GmbH ist aufgelöst

Michael Siek Bohlweg 6a * 38678 Clausthal-Zellerfeld Tel.: +49 5323 4413

SILICON Technology & Promotion Wilhelmshöher Allee 124 * 34119 Kassel Tel.: +49 561 711924

Softbär GbR Richardstr. 60 * 12055 Bärlin Tel.: +49 30 6226884

SPIRIT WARE Bible Church 15211 15th Avenue NE Seattle, WA 98155 (USA)

TKR Stadtparkweg 2 * 24106 Kiel Tel.: +49 431 337881; Fax.: +49 431 35984

Toad Computer 570-F Ritchie Highway Severna Park, MD 21146-2925 * USA Tel.: +1 410 544 6943

Trade iT existiert seit April 1994 nicht mehr.

Holger Weets Tangastr. 45 * 26121 Oldenburg E-Mail: Holger Weets@OL.maus.de

Dipl.-Phys.-Ing. Ralf Wirtz Kasterstr. 30 * 52428 Jülich Tel.: +49 2461 1255

Wilhelm Mikroelektronik Luenen

Working Title GbR Lilienweg 12 * 53123 Bonn Tel.: +49 228 647020

3K Computerbild Wevelinghoven 26 * 41334 Nettetal Tel.: +49 2153 91860

24 Sonstiges

24.1 Kritik

Kritik ist herzlich willkommen. Wer Zusatzinformationen will, der schicke eine E-Mail an

G.Castan@physik.uni-stuttgart.de

Wahrscheinlich hat der, der mir schreibt, schon einen oder zwei Treiber getestet. Schreibt mir bitte, ob die oben angeführten Fehler auftreten, oder nicht.

Wer sonstige Treiber-Quellen kennt, soll sich auch aufgefordert fühlen, mir zu schreiben.

24.2 Lob

Wem dieses FAQ schon aus einer mißlichen Lage geholfen hat, der schreibe mir aus dem nächsten Urlaub eine Postkarte.

Bisheriger Stand an Postkarten: 3.

24.3 In eigener Sache

Aus gegebenen Anlässen bitte ich die Vertriebe, beim Kopieren der Update-Disketten das Verify anzuschalten.

Es gibt nur 2 Firmen, mit denen ich in dieser Hinsicht keine schlechten Erfahrungen gemacht habe.

Könnte sich vielleicht einer der geneigten Leser aufraffen, einen Speedo-Fonteditor zu schreiben? Ich biete mich auch ganz uneigennützig als Betatester an ;-)

24.4 Warenzeichen

Dieses Dokument ist gespickt von eingetragenen Warenzeichen, die nicht frei verwendbar sind.

24.5 Garantie

Ich garantiere für gar nix.

Literatur

[Whe88] Douglas N. Wheeler, EVERYTHING YOU EVER WANTED TO KNOW ABOUT GDOS (AND MORE), (Internet, Filename: GDOS.ARC oder GDOS.TXT) Hier steht alles, was es an Allgemeinwissen über GDOS-Treiber gibt. (AND MORE)

[Jan92] Jankowski, Rabich, Reschke, Atari Profibuch, 10. Auflage, SYBEX, Düsseldorf (1992) Das Standardwerk. Für Programmierer: im VDI-Teil steht, wie man Bildschirm und Druckertreiber korrekt anspricht.

[San94] Scott Sanders, The ATARI Compendium, First Revision, SDS Publishing, Long Beach (1994) Noch ein Standardwerk. Es ist aktueller als das Profibuch (VDI-Aufrufe bis SpeedoGDOS 4.2) und sehr vollständig. Insbesondere enthält es die offiziellen GEM User Interface Guidelines. Trotzdem kann es das Profibuch nicht ersetzen. Sollte dieses FAQ einst ein Kapitel über Layout enthalten, wird dieses Buch als abschreckendes Beispiel dienen. Sehr lobend muß erwähnt werden, daß für jede Betriebssystemfunktion beschrieben ist, ab welcher Version sie vorhanden ist bzw. wie man herausbekommt, ob sie vorhanden ist.

[Gar93] Marc René Gardeya, VDI für jedermann, ST-Computer 10/93 Einführung in die saubere Programmierung von Bildschirm- und Druckerausgaben.

[Res92] Julian Reschke, Herbstgedanken, ST-Magazin 11/92 Herbstgedanken über FontGDOS und Speedo-GDOS.

[Dic93a] Erik Dick, Schön und schnell?, ST-Computer 7/93 Allgemeines über GDOS und Installation von Speedo. Im Prinzip das, was im Installationshandbuch steht, allerdings wird auf spezielle Probleme gesondert eingegangen.

[Dic93b] Erik Dick, SPEEDO-Gonzales, ST-Computer 8/93 Pflichtlektüre zur Speedo-Programmierung. Beschrieben werden die neuen Bindings und Programmierhinweise für Standardanwendungen.

[Dic93c] Erik Dick, SPEEDO-Gonzales, ST-Computer 9/93 Bedeutung der Speedo-Fehlermeldungen und Bindings der Bézier- und Cacheroutinen

[Dic94a] Erik Dick, Mit Speedo in die Zukunft?, ST-Computer 6/94 Was bringt Speedo 4.2 neues? Beschrieben werden auch die neu hinzugekommenen Bindings.

[Dic94b] Erik Dick, Thronfolge Teil 1, ST-Computer 11/94 Vergleich zwischen NVDI 3.0 und SpeedoGDOS 5.0: Lieferumfang, Installation und Bedienung.

[Schr92] Raymond Schröder, Atari-Hotline, ST-Magazin 7/92 Wozu gibt es GDOS? Welche Programme unterstützen es? Wie installiert man es?

[Beh92] Sven Behne, Wilfried Behne, NVDI-Dokumentation, BELA / 2B Beschreibung des VDI. Leider ist nicht aufgeführt, worin sich Bildschirmtreiber und Druckertreiber unterscheiden. Eine Dokumentation für Programmierer ist nur bis Version 2.51 dabei. Ab version 3.0 ist [Beh95] zu Rate zu ziehen.

[Beh95] Wilfried Behne, vorläufige Funktionsbeschreibung zu NVDI 3, ftp://ftp.cs.tu-berlin/pub/atari/Gdos/nvdiguid.zip Eine Public Domain - Dokumentation, die fast alles enthält, was man als Programmierer so braucht. zu nvdiguid gehört auch ein Patchprogramm, das kleinere Fehler in NVDI 3.x und 4.x behebt.

[Beh91] Wilfried Behne, Andreas Kromke, Fallen im VDI des Atari ST und wie man sie umgeht, c’t 1991, Heft 3 Es werden vor allem Fehler in den Bildschirmtreibern beschrieben.

[Pru92] Laurenz Prüßner, … es ist alles so schön Bunt hier, ST-Magazin 5/92, 7/92, 9/92 Umgang mit mehr als 256 Farben und mit geräteabhängigen Formaten.

[Pru93a] Laurenz Prüßner, Auf ein Neues!, ST-Magazin 1/93 .OFF TOPIC. Sollte jeder, der mit Fly Dials oder ähnlichen Libraries arbeitet, gelesen haben. Problemstellung: Die neuen AES benutzen für 3D-Objekte ob state-Bits, die bisher frei verwendbar waren und von den Libraries auch für eigene Zwecke verwendet werden. Das Problem betrifft ausschließlich AES 3.31 (TOS 4.01) und ist inzwischen gelöst.

[Pru93b] Laurenz Prüßner, Sekt oder Selters, ST-Magazin 4/93 MEMORY.SYS: Binding, Vorgehensweise bei Farbauflösungen, Fontausgabe mit und ohne SpeedoGDOS.

[Pru93c] Laurenz Prüßner, Summertime Blues, ST-Magazin 6/93 Listing zum Öffnen des MEMORY-Treibers.

[Pru94] Laurenz Prüßner, Mehr Schub!, ST-Computer 2/94 Drucken über GDOS, speziell wird das Drucken von Bitmap-Rastern - auch in Farbe - besprochen.

[Sche93] Oliver Scheel, Erste Hilfe für MultiTOS, ST-Magazin 6/93 Allgemeines zu Installation von MultiTOS.

[Bor94] Günter Born, Referenzhandbuch Dateiformate, 3. Auflage, Addison-Wesley, Bonn (1994) Mit den entsprechenden Treibern ist es relativ einfach, im .IMG- und im .GEM- Format auszugeben. In diesem Buch steht, wie man diese Formate wieder einliest (und mehr).

[Bor93] Günter Born, Dateiformate Programmierhandbuch, Addison-Wesley, Bonn (1993) Sourcen (TurboC, TurboPascal) zum Laden und Speichern der Formate. Zum Auswerten der Daten benötigt man weiter das Referenzhandbuch.

[Ore85] Tim Oren, Professional GEM, (Internet, Filename: PROGEM) Tim Oren geht zwar vor allem auf die Programmierung der AES ein, aber die Literaturliste wäre ohne ihn unvollständig.

[Walsh] Norman Walsh et al, comp.fonts FAQ TeX DVI, PostScript, and Info versions of this FAQ are available from ftp.shsu.edu in /texarchive/help/comp-fonts-FAQ. A Gopher server is also maintained at shsu.edu which can provide interactive access to the FAQ. Finally, an online, hypertext version of the FAQ is maintained (experimentally) on jasper.ora.com where an HTTP server runs. For example, point XMosaic (or a similar WWW browser) to http://jasper.ora.com/.

[D81] Bundestag, Lobby et al, Schriftzeichengesetz, Gesetz zum Wiener Abkommen vom 12. Juni 1973 über den Schutz typographischer Schriftzeichen und ihre internationale Hinterlegung (Schriftzeichengesetz) Vom 6. Juli 1981 (BGBl.II S. 382) zuletzt geändert durch G vom 18.12.1986 (BGBl.I S. 2501) ftp://ftp.uni-stuttgart.de/pub/doc/law/german/SchriftzeichenG

[Kar92a] Peter Karow, Schrifttechnologie, Springer (1992) Font technology, Springer (1994) Dieses Buch hat mich richtig begeistert (auch wenn ausgerechnet das Speedo-Format fehlt). Intelligentes Scaling: Welche Tricks (Hints etc) beherrschen die einzelnen Fontformate (T1, TT, F3, IF, II)? Viel über Fontqualität, Lesbarkeit und Copyright von Fonts.

[Kar92b] Peter Karow, Digitale Schriften, Springer (1992)

Digital typefaces, Springer (1994) Darstellung und Formate von Vektorschriftformaten wie Type 1, TrueType, F3, Intellifont etc. (Speedo wird nur am Rande erwähnt). Dabei werden auch viele Konzepte erklärt. Anhang F ist ein kleines Wörterbuch der Schriftbegriffe (deutsch - englisch - französisch)

[Mer94] Thomas Merz, Name der Wahrheit, c’t 12/1994 Fontnamen und andere Informationen aus der TrueType-Datei auslesen.

[Mic] Microsoft, Verschiedene Dokumentationen und Programme zu TrueType-Fonts, ftp://ftp.microsoft.com/developr/drg/TrueType-Info/ Enthält eine ausführliche TrueType-Dokumentation als Windows-Helpfile, das alleine mit Windows ohne Zusatzprogramm ausgedruckt werden kann und als MS-Word-Dokument (MS-Draw wird zum Anzeigen auch benötigt)

[Hil95] Ulrich Hilgefort, Fonts mit Mengenrabatt, c’t 1/1995 Qualitätsvergleich einiger CD’s mit TrueType-Fonts:

• Accurate Research: Dr. Fonts (2275 Shareware+PD-Schnitte; TT)

• ARI Heidelberg (1268 Shareware+PD-Schnitte; TT)

• Bitstream TypeShop (502 Schnitte; TT)

• PrimaFont TrueType CD (1812 Schnitte, davon 1203 Berthold-Schnitte nachdigitalisiert; TT)

• SoftMaker Profi-CD Vers. 2 (750 Schnitte; TT+T1)

• URW PrintWorks (503 Schnitte in 10 Fonts; TT+T1)

• Wayzata Technology Font Pro 2 (213 Schnitte; TT+T1)

[Kaw95] Kenji Kawakami, 101 Unuseless Japanese Inventions: The Art of Chindogu, W. W. Norton & Co (1995), ISBN 0-393-31369-7 Unbeschreiblich. Siehe Buchbesprechung in Whole Earth Review, Nr. 88, Winter 95