Grafische Oberflächen stellen selbstverständlich wie Drucker Zeichensätze dar. Doch der Weg von der Datei bis zur Darstellung ist lang und führt unweigerlich über die Firma Adobe, die erstmalig die standardisierte Zeichendefinition PostScript öffentlich machte. Genauer gesagt, definiert PostScript noch etwas mehr, doch das soll uns hier nicht interessieren. Die erste kommerzielle Zeichensatzrevolution begann 1985, als der Drucker LaserWriter von Apple das Adobe-Format PostScript rastern konnte. Die Definition eines Zeichensatzes lag bis zu dieser Zeit nur in Bitmaps vor, doch die PostScript-Zeichensätze wie auch die TrueType-Zeichensätze, um die es später gehen soll, lagen als Punktbeschreibung vor. Die Rasterung übersetzte diese Punkte in eine Bitmap, die dann entweder auf dem Bildschirm oder auf dem Drucker ausgegeben wurde. Durch die Punktbeschreibung waren also nicht mehr größenabhängige Beschreibungen vorhanden, sondern die Zeichen (auch Glyphs genannt) wurden durch Linien und Kurven in kubischen Bézier-Kurven beschrieben.
Die Visualisierung der Zeichensätze machte Microsoft und Apple Sorgen, weil Adobe mehrere Definitionen der PostScript-Zeichensätze pflegte, darunter Type 1 (PS-1) und Type 3 (PS-3). Type 1 nutzt so genannte Hints (Hinweise), um auch bei unterschiedlichen Größen und grafischen Oberflächen optimale Darstellungen zuzulassen. Diese Definition war jedoch geheim. Zeichensätze des Type 3 sehen zwar auf dem Papier gut aus, nicht aber auf dem Bildschirm mit niedriger Auflösung – hier fehlen die Informationen aus den Hints. Microsoft und Apple wollten nun ihre Zeichensatzausgabe nicht der Firma Adobe überlassen (die natürlich einen Type-1-Rasterer im Programm hatte), sondern definierten ihre eigene Font-Technologie, die nicht mehr auf Bézier-Kurven, sondern auf quadratischen B-Splines basierte. Apple machte dabei den Anfang mit Royal, welches später in TrueType (TT) umgetauft wurde. Dies war sechs Jahre nach den PostScript Fonts. Der einzige Hersteller, der dennoch bei PostScript-Type 1-Zeichensätzen geblieben ist, ist IBM mit dem Betriebssystem OS/2. Daneben nutzte auch NeXtStep diese Zeichensatzdefinitionen, doch das System hallte nicht lange nach.
Nachdem Apple den Anfang mit TT gemacht hatte und es 1991 in MacOS integrierte, übernahm auch Microsoft, wo ein bis dahin wenig lauffähiger PostScript-Clone (»TrueImage«) zum Einsatz gekommen war, die Technologie für Windows 3.1. Adobe erkannte früh die Konsequenz dieser Allianz und öffnete die Spezifikation für PostScript-Type-1-Zeichensätze im März 1990. Mitte des Jahres lieferte Adobe zusätzlich den Adobe Type Manager (ATM) aus, der Type-1-(aber keine Type-3-)PostScript-Zeichensätze für den Bildschirm und für nicht PostScript-fähige Drucker darstellte. Heutzutage existieren beide Definitionen immer noch parallel, und für Drucker ist die Frage, welche nun besser ist, nicht zu beantworten. Moderne Drucker haben auch ein eigenes TrueType-Raster im ROM eingebaut. In Zukunft wird die Unterscheidung wohl auch unwichtiger werden, da Microsoft die »offene« OpenType-Spezifikation (auch »TrueType Open Version 2« genannt) nach vorne bringt. Der Zeichensatz PS-1 oder TrueType wird hier in einer OpenType-Datei gekapselt und dem Rasterer übergeben und berechnet. Dabei übernimmt Adobe, wo eine Zusammenarbeit mit Microsoft unterstützt wird, die PS-1-Rasterung, und Microsoft die TT-Rasterung. In Zukunft möchten Microsoft und Adobe Zeichensätze im OpenType unterstützen und deren Verbreitung fördern.
TTF in Java nutzen
Eine Einschränkung mit den gegeben vordefinierten Standard-Zeichensätzen (Dialog, DialogInput, Monospaced, Serif, SansSerif, Symbol) ist, dass dies zu wenig sind. Doch die Font Kasse bietet die statisch Methode createFont() an, die zu einen Eingabestrom auf ein TrueType Zeichensatz das entsprechende Font-Objekt zurückgibt.
Font f = Font.createFont( Font.TRUETYPE_FONT,
new FileInputStream("f.ttf") );
Der erste Parameter ist die fest vorgeschriebene Konstante Font.TRUETYPE_FONT, andere Parameter sind nicht definiert und führen zu einer IllegalArgumentException("font format not recognized"). Der zweite Parameter ist ein Eingabestrom zu der Binärdatei mit den Zeichensatzinformationen. Die Daten werden ausgelesen und zu einem Font Objekt verarbeitet. Da die Daten intern über einen gepufferten Datenstrom in eine temporäre Datei geschrieben wird, ist eine eigene Pufferung über einen BufferedInputStream nur doppelter Overhead. Waren die Beschreibungsinformationen in der Datei ungültig, so erzeugt die Fontklasse eine FontFormatException("Unable to create font – bad font data"). Dateifehler fallen hier nicht drunter und werden extra über eine IOException angezeigt. Der Datenstrom wird anschließend nicht wieder geschlossen.
Wir wundern uns vielleicht an dieser Stelle, dass die Methode createFont() von der Arbeitsweise mit dem Konstruktor ähnlich sein müsste, aber der Parameterliste die Attribute fehlen. Das liegt daran, dass die Methode automatisch einen Zeichensatz der Größe 1 im Stil PLAIN erzeugt. Um daher einen größeren Zeichensatz zu erzeugen, müssen wie ein zweites Font Objekt anlegen. Dies geschieht am einfachsten mit der Methode deriveFont().
font = f.deriveFont( 20f );
Der Parameter ist ein float und kein double.