Einleitung

Gerd Castan

Motivation

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 Konkurrenzprogramm 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. Praktisch alle aktuell gepflegten Atari-Programme, die drucken, unterstützen GDOS.

Änderungen zu Version 3.3

• * Statistikprogramm BStat
• * noch ein paar LaTeX-Relikte entfernt
• + NVDI 5.0

2.4: 09.01.1995
2.5: 21.02.1995
2.6: 29.05.1995
2.7: 17.08.1995
2.8: 09.01.1996
2.9: 06.05.1996
3.0: 09.02.1997
3.1: 01.05.1998
3.2: 10.05.1998

Briefe an die Leser

Programme

CE im Fontnamen

VDI-Treiber

Tintenstrahldrucker mit 150, 300 ... dpi

Tintenstrahldrucker mit 180, 360 ... dpi

9-Nadeldrucker

24-Nadeldrucker

Laserdrucker

Atari-Laserdrucker

Bildschirmtreiber

LineA

Setscreen und Getscreen

NVDI und WARP 9

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. WARP 9 hat inzwischen keine Bedeutung mehr.

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. Dafür gibt es jetzt den frei kopierbaren ascii-Text nvdiguid.

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.

Sonstige Treiber

Memory-Treiber

Plottertreiber

Druckertreiber für NVDI 3.0

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. PINPRN2.SYS) in den 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.

Mac Quickdraw

Fehler

• [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.

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.

Fonts

Die Begriffe Font und Schnitt

Die Begriffe Format und Darstellung

Um diese Verwirrung aufzulösen, definiere ich für 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.

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-Darstellung brauchen, unabhängig davon, ob es das Windows- oder Macintosh-Format ist. Wenn man die Fonts auf einem Mac (in Mac-Darstellung) installiert, dann stehen sie unter MagiCMac mit NVDI für MagiCMac auch zur Verfügung.

Bitmap-Fonts

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.

Vektorfonts

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.

FSM-GDOS-Fonts

Bitstream Fontware-Fonts

Bitstream Speedo-Fonts

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 weiß, daß der Schnitt von dem Drucker mit dem druckereigenen Zeichensatz gedruckt wird. Das ist unter GDOS aber nie der Fall.

Type 1-Fonts

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.

Multiple Master (MM) Fonts

Genau.

Unter Windows kann ich jetzt MM Fonts verwenden, aber was mache ich mit meinem alten Postscript-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 Schluß, 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.

Type 1-GX-Fonts

TrueType-Fonts

TrueType für Windows 3.0

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].

TrueType GX-Fonts bzw. TrueType 2.0

• 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)

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.

TrueType für Windows NT

Vergleich der Vektorformate

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

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.

Hints, instructions, switches

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 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.

Interne Auflösung

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.

Bei Speedo geht das Geviert von 0 bis 4000 (nur ganze Zahlen?). (Welche interne Auflösung hat OTL? Ist das Bitstream-Format, das in [Kar92a] erwähnt wird, identisch mit dem Speedo-Format?)

Lineare und optische Skalierung

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 METAFONT 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 (d.h. andere Pixel gesetzt sein) 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.

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. Diese Offscreen-Bitmap-Treiber gibt es auch separat als PD-Software. 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.

Sollen dagegen verschiedene 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 Pixelfonts. Hat das irgend jemand verstanden?

Konversion zwischen den Vektorfontformaten

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.

Drucker

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).

Canon-Drucker im BJ-Modus

CAN CR ESC "@"

CAN CR ESC "[K" $02 $00 $00 "$"

Programme

• 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 Bitmap-Breite.
• Programme, die nur auf Gerätenummer 21 drucken, sind out. (Opus und CLA) Siehe auch Treiberauswahl.
• 7Up benötigt nichtproportionale Fonts.
• 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 auch TrueType und Type 1 Fonts ohne installiertes SpeedoGDOS 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 ABC-GDOS aufgeführt.
• Signum!4 scheint nur mit NVDI 3.0x zu laufen, nicht aber mit SpeedoGDOS 5.x.
• Concordance gibt es inzwischen kostenfrei unter http//:www.halcyon.com/fabc.

ftp://ftp.cs.tu-berlin.de/pub/atari/Graphic/kand251

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)

Hilfsprogramme

fontfix

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

Outline Fonts

Dateiname: OUTLINE.PRG alias OUTLINE.ACC, 67644 Bytes

SpeedoGDOS 5.0: 49254 Bytes Wird bei SpeedoGDOS mitgeliefert. Warum hat es Atari eigentlich nicht geschafft, die Programme mit einer Versionsnummer auszustatten?

Druckertreiber

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?

ASSIGN

• 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?

FONTCHK

FONTCNV

GEMFont

FontMonger

Font-ID

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

X4U

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 veranlaßte. 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)

Charmap

Charmap heißt aber auch Peter Hellingers Weiterentwicklung von X4U, die in der Version 0.9 als Freeware frei kopiert werden darf. Läuft nur mit der mitgelieferten MagicLib.

GDOS-Font

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.

REFONT

Arkus

GDOS-Check

Von Christoph Bartholme @ KA2

Benchmarks

Der beste Benchmark

Dieser Hinweis ist aber von beschränktem Wert, da die meisten Anwender (beim Kauf) gar nicht wissen, wozu sie ihren Rechner eigentlich nutzen wollen. Aber dann ist es eh egal, welchen Fehler sie machen.

GEMBench

• Verwende niemals dieses Programm zum Vergleich zweier Rechner. Dieses Programm liegt normalerweise um ein vielfaches daneben, mal in die eine, mal in die andere Richtung. Dieses Programm ist zu nichts zu gebrauchen.
• Kaufe niemals einen Rechner, dessen Hersteller mit GEMBench-Werten wirbt.

Dhrystones und MIPS

Dhrystones gibt vor, die Integerleistung eines Prozessors zu messen. Richtig daran ist, daß die Fließkommaleistung, die Graphikgeschwindigkeit und der Plattendurchsatz nicht gemessen wird.

Der Haken an diesem Programm ist, daß sowohl der Code als auch die bearbeiteten Daten in 64 kB passen, was heutzutage fern jeglicher Realität ist. Heute ist nur interessant, wie schnell ein System ist, wenn sowohl Code, als auch Daten deutlich über dieser Grenze liegen.

Insbesondere bei einer Reihe von Intel-Prozessoren zeigt dieser Benchmark (im (un)geeigneten Modus) einen deutlich besseren Wert an, als in der Praxis bei marktüblichen Applikationen beim Anwender ankommt.

Die Einheit MIPS, mit der oft geworben wird, ist schon länger als Faktor mal Dhrystones definiert, und damit ebenso Praxisfern, wie Dhrystones.

Fontselektoren

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. Der Abschnitt über WDIALOG ist allerdings aktuell.

The quick brown fox...

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 weiß 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

Zwei Boxkämpfer jagen Eva quer durch Sylt
Sylvia wagt quick den Jux bei Pforzheim
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;
...

UFSL

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.

XUFSL, HuGo

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.

Magic von Helli

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.

FontSel

Weitere Fontselektoren

WDIALOG

Alles in allem sehr gelungen. Der Fontselektor hat ziemlich genau die Funktionalität (und das Aussehen) wie der von papyrus.

Besonders zu beachten ist die Implementierung der ..._evnt-Funktionen. Hier ist verwirklicht, was ich schon lange predige: Systemerweiterungen, die fertige Dialoge zur Verfügung stellen, dürfen selbst keinen evnt_multi-Aufruf machen, sondern müssen die Events vom Hauptprogramm bekommen. Nachmachen!

Ein Wermutstropfen: WDIALOG verfälscht den appl_getinfo-Aufruf unter alternativen Betriebssystemen. Dadurch werden allen Programmen falsche bzw fehlende Eigenschaften des Betriebssystems vorgespiegelt. (Dank an Peter Hellinger für diesen Hinweis.) Dies ist mit Version 1.96 behoben.

FONTSelector

Minimalanforderungen

Wünschenswerte Eigenschaften

Attribute und Auswahl

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.

Fenster und Eventverwaltung

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.

Verschiedenes

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

Über Dialoge

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.

Vertrieb

Atari

BELA

Language

Internet

(z.B. ftp://ftp.cs.tu-berlin.de/pub/atari/.

Working Title

X Window System

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

COMPO

IMG-0300

FTP

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!

SciLab

Star Division

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)

Thierry Rodolfo

ftp://hensa.micro.ac.uk/atari/tos/n/n196/
Ausnahme: MEMORY_2 befindet sich in
ftp://ftp.cs.tu-berlin.de/pub/atari/GDOS/

Sonstige

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!)

GDOS-Versionen

Die Fossile

Atari-GDOS 1.X und AMCGDOS

ABC-GDOS

G+Plus

G+Flair

Ein Schritt nach vorne

FontGDOS 2.0

FSMGDOS 3.0

Erste brauchbare Vektorfonts im GDOS

SpeedoGDOS 4.0 und 4.1

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 Druckertreiber).

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.

SpeedoGDOS 4.2

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.

SpeedoGDOS 5.0

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:] Grmpffff...

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. Bekannte Fehler:

• Trennt man den Namen, den vqt_name liefert, nach der 16. Stelle, um wie dokumentiert Name und Style zu erhalten, dann liefert ausgerechnet der Font mit der ID 1 (System) Schrott. An der Trennstelle wurde die 0 vergessen.
• Für Type 1-Schnitte steht in Style Schrott, egal ob man diesen mit vqt_fontheader oder mit mit vqt_s_info erfragt.
• vqt_fontheader würfelt die Copyright-Information verschiedener Schnitte durcheinander; manchmal ist diese Info auch gelöscht - was etwas besser ist.
• Für Type 1-Schnitte werden die Klassifikationsangaben nicht gesetzt (Classification Flags, Family Classification, Font Form Classification).
• Daß viele Werte von vqt_fontheader auf 0 gesetzt werden (außer natürlich bei Speedo-Fonts) ließe sich verkraften. Aber NVDI kann's doch auch.

SpeedoGDOS 5.5

Die verbesserte Konfigurationsmöglichkeiten haben zur Folge, daß die Konfiguration der EXTENT.SYS nicht mehr mit OUTLINE.PRG geschehen darf, sondern mit einem Editor (ist aber ziemlich einfach).

Leider ist es das erste GDOS, das abstürzt, wenn ein Programm ein nicht vorhandenes Zeichen anspricht (was eigentlich ziemlich normal ist). Workaround: wer die mitgelieferten oder andere sehr vollständige Zeichensätze verwendet, sollte nichts davon merken.

Bei LOWMEM=1 in der EXTENT.SYS zeigt SpeedoGDOS 5.5 bei mir keine Vektorzeichensätze mehr an. Diese Option braucht man normalerweise nicht. Sie wäre nur notwendig, um den Bitstream Cyberbit-Font anzuzeigen.

NVDI bis Version 2.51

NVDI 3.0

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

Die Druckertreiber sind in NVDI-Treiber aufgeführt. (Mir) bekannte Fehler und Probleme: Diese Liste ist nur für Programmierer, die NVDI 4.0 nicht unbedingt brauchen und den Anwendern auch die Verwendung von NVDI 3.0 ermöglichen wollen. Anwender mit Problemen sollten sich einfach die aktuelle Version besorgen.

• 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.

NVDI 4.0

NVDI 4.11

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.

(Mir) bekannte Fehler und Probleme:

• NVDI kommt mit dem Bitstream Cyberbit zurecht, wenn man WIDTH_CACHE = 192512 setzt.

NVDI 5.0

Für Programmierer steht diese Version unter dem Motto Graphikausgabe und Farbmanagement. Insbesondere Programmierer von Programmen, die Bilder ausgeben, haben es jetzt sehr einfach, diese von NVDI skalieren zu lassen und an verschiedene Farbräume anzupassen. Das funktioniert so gut und schnell, daß sich Anwender nicht wundern dürfen, daß derartige Programme NVDI 5.0 voraussetzen.

Der große Rückschritt dieser Version besteht darin, daß kein MAKEPRN mehr mitgeliefert wird, um sich eigene Druckertreiber zu konfigurieren.

Der Grund liegt darin, daß die Behnes für einige wenige Drucker ein NDA unterschreiben mußten, das ihnen untersagt, die Steuercodes weiterzugeben. Für mich ist allerdings nicht einzusehen, warum Anweendern anderer Drucker deshalb die Möglichkeit der Konfiguration genommen wird. Hier besteht dringender Nachbesserungsbedarf. Deshalb sollten Programmierer die Anwender auch nicht ohne Grund zu NVDI 5 zwingen. Im zweifel kaufen diese dann nämlich weder das Programm noch NVDI 5.

Aus gegebenem Anlaß noch die Anleitung, wie man Druckersteuercodes herausbekomt: man erstellt ein Dokument, das die interessanten Features enthält und druckt es. Als Drucker nimmt man einen alten Nadeldrucker, den man auf Hexdump gestellt hat.

Kommentare

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, daß die Handles in Zukunft als unsigned integer (SHORTCARD) interpretiert werden sollen.

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.
• Zahl der Formate. Beide beherrschen Speedo und TrueType. SpeedoGDOS 5.0 beherrscht zusätzlich Type 1, was bei NVDI extra kostet. 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.
• Nur SpeedoGDOS bietet Treppchenfreihe(TM) Fontreinheit.
• NVDI 4.0 bietet Farbdruck und UNICODE-Unterstützung.

Source

Tips und Tricks für Anwender

Pixelmüll beim Drucken

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.

NEC P6+

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

Überschriebene Speedo-Schnitte

HCPY_ALL

Wenn es installiert ist, sorgt es beim Druck mit einem GDOS oder vom Desktop aus für das Phänomen, daß der Ausdruck reproduzierbar und immer an der gleichen Stelle so aussieht, als sei ein TAB eingefügt. Dieses Programm ist daher Mega-Out.

Plattformübergreifendes Drucken mit Files

Das Drucken ist - zumindest mit NVDI - einfach: Man wählt den passenden Drucker aus und als Schnittstelle eine Datei auf der Festplatte oder Diskette.

Diese Datei transportiert man zu dem anderen Rechner und druckt dort - oft Müll. Der Grund liegt darin, daß viele Betriebssysteme hier "hilfreich" unter die Arme greifen und die Daten verändern, die man doch Byte für Byte an den Drucker schicken will. Beispielsweise verändert der DOS-Befehl COPY die Daten, wenn das Zielgerät ein Drucker ist.

Folgendes verhindert bei verschiedenen Betriebsystemen das Ändern der Druckdaten:

• DOS: COPY A:

  MYFILE.PRN LPT1: /b

• DOS: COPY -b A:

  MYFILE.PRN LPT1:

• VMS: PRINT /NOFILTER MYFILE.PRN DRUCKER
• TOS: Keine besonderen Maßnahmen notwendig
• UNIX: Das Drucken ohne Filter ist nur dann möglich, wenn der Sysop diese Option für den gewünschten Drucker explizit eingerichtet hat (/etc/printcap). Sonst hat der Normalanwender keine Chance.
• MacOS: DropPS verwenden

Bitstream Cyberbit

FILE_CACHE muß mindestens 157328 Bytes groß sein, wobei die Skalierung dann aber sehr langsam ist. Ab 400 kB wird es schneller.

Da Bitsream weitere Zeichen integriert, kann es sein, daß diese Werte sich bei zukünftigen Versionen verändert werden müssen. Dank an Rainer Seitel für diesen Tip.

Tips und Tricks für Programmierer

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 Lineare und optische Skalierung.

Treiberauswahl

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.

Das Metafile-Format

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, 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. KandinskY clipt, 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.

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 KandinskY alles 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.

Logische Seiten im Metafile-Format

Deshalb wird hier im GDOS-FAQ definiert, daß v_form_adv zu verwenden ist, wenn in einem Metafile mehrere logische Seiten zu trennen sind.

Erweiterte Sub-Opcodes für Metafiles

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-Betriebssystemroutinen. Besonders zu beachten ist hier der Befehl v_write_meta, mit dem die Sub-Opcodes in ein Metafile geschrieben werden können.

Die unterstützten Sub-Opcodes

Die Gruppeninformation

Der Objektschatten

Die Füllfläche

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

Der Vektortext

Die Fenstereinstellungen

Fensterposition

Rastereinstellungen

Bezugsobjekt

Die Grautöne

Bézier-Züge

Zusammenfassen mehrerer VDI-Blöcke

Standards

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

International Color Consortium Profile Format

Ich behaupte nicht, daß dies auch bei NVDI, SpeedoGDOS oder anderen GDOSen berücksichtigt wird. Siehe http://www.sgi.com/Technology/icc_top.html.

TIFF

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*.

Character Sets

Glyphen und Ligaturen

ascii, ISO 646

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

Ascii ist inzwischen als die unteren 7 Bit von ISO 8859-1 bzw. von UNICODE definiert (was auf das selbe hinausläuft). Siehe auch http://www.asc-inc.com/ascii.html. Da der Begriff ascii aber viel zu lange undefiniert war, muß man damit immer noch sehr aufpassen.

ISO 8859

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.

UNICODE / ISO 10646

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 "Auflösung", 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.

GEM-LIST-Standard

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, daß der so "verabschiedete" Standard ohne Nachbesserungen (amendments) nichts taugt. Die Nachbesserungen wurden in der GEM-LIST aber weder diskutiert noch verabschiedet.

Copyrights und Fonts

Bitstream-Fonts in Dokumenten

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

Urheberrecht

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än-dig: ð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.

Markenrecht

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.

Adressen

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

Overscan
Kurze Str. 15
12167 Berlin (Berlin-Steglitz)
Tel.: +49 30 790100 0, Fax: +49 30 790100 15

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

Sonstiges

Kritik

Lob

In eigener Sache

Warenzeichen

Garantie

Literaturverzeichnis

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 /tex-archive/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