Sandra Cuningham, Fotolia.com

Bitmaps, Postscript, Type-42-Container, Truetype, Opentype, Freetyp … – wohl niemandem muss es peinlich sein, wenn er bei der Fülle der Schriften-Formate den Überblick verloren hat. Wer trotzdem verstehen will, was und warum unter Linux alles zum Diktat bittet, kommt um ein kleines Historiendrama nicht herum.

Die ersten Computerterminals sowie die frühen Spielekonsolen färbten einzelne Bereiche des Pixelrasters am Bildschirm nach einem festgelegten Zeichensatz ein (Abbildung 1). Diese Technik kommt heute noch im Teletext zum Einsatz. Die “Klötzchendarstellung” erfordert jedoch großen Abstand des Betrachters zum Wiedergabegerät, um einigermaßen lesbar zu sein. Daher eignet sie sich nicht besonders, um Text einzugeben.

Pixelschriften

Die Bildschirm- und Druckerpioniere führten daher so genannte Bitmap-Fonts ein. Das sind kleine Rastergrafiken, wie sie zum Beispiel Bildbearbeitungsprogramme produzieren. Angesichts der vergleichsweise geringen Rechenleistung der Computer in den 70er und 80er Jahren war dies die einzige Möglichkeit für Bildschirmtexte, die über die Teletext-Variante hinausging.

E Abbildung 1: Die Bildschirme der ersten Heimrechner – wie im Bild der Startbildschirm eines Commodore VC20 vom Anfang der 1980er Jahre – stellten Zeichen als eingefärbte Punkte in Feldern aus acht mal acht Pixeln dar.

Unter Linux sind Bitmap-Schriften bis heute in Gebrauch, etwa in Terminals oder in Latex. Allerdings nimmt ihre Bedeutung im Desktop-Bereich ab. Die beiden häufigsten Formate sind das Portable Compiled Format (PCF, [1]) sowie das von Adobe entwickelte Glyph Bitmap Distribution Format (BDF, [2]).

Der Vorteil von Bitmap-Fonts liegt neben den geringen Anforderungen an die CPU-Leistung darin, dass die Übereinstimmung von Bildschirmanzeige und einem Ausdruck hoch ist. Das gilt allerdings nur, wenn die Schrift in Originalgröße aus dem Drucker kommt. Sobald das Ausgabegerät eine Bitmap-Schrift hochskaliert, besteht dieselbe Gefahr wie bei allen niedrig auflösenden Rasterdateien, nämlich die pixelige Darstellung.

Die einzig verlässliche Lösung dieses Problems besteht darin, für jede Schriftart und jeden Schriftschnitt Pixeldaten in verschiedener Größe zu verwenden. Ein Blick in das Verzeichnis »/usr/share/fonts/« – oder das von der jeweiligen Distribution verwendete Standardverzeichnis zur Schrifteninstallation – zeigt, dass genau dies der Fall ist: Schriften sind dort in mehreren Größen und Schnitten abgelegt (Abbildung 2).

Der Anwender handelt sich so jedoch ein anderes Problem ein. Denn während die Anzahl möglicher Schriftgrößen theoretisch so gut wie unbegrenzt ist, wenn man über die Bildschirmdarstellung hinausgeht, ist doch der Speicherplatz begrenzt. Die meisten Bitmap-Schriften liegen daher nur in häufig verwendeten Größen und Schnitten vor.

Die Postscript-Revolution

Die Einschränkungen der Pixelschriften waren der Industrie und der Forschung bewusst und es galt, sie zu überwinden. Das Zauberwort hieß Vektorschriften. Die Grafikverarbeitung eines Systems beschreibt und speichert eine Vektorschrift dabei nicht länger Pixel für Pixel. Stattdessen verwendet sie, genau wie bei anderen Vektorgrafiken, nur Koordinaten und Werte, etwa für Farbe und Füllung. Das bedeutet, dass eine solche Schrift sich vergrößern lässt, ohne dass die Qualität leidet (Abbildung 3).

Abbildung 2: Die Bitmap-Schrift „Bitstream Charter“ bringt eigene Versionen für verschiedene Schnitte und Größen mit, zum Beispiel für Fett und Kursiv in Punktgröße 25.

Während diese Darstellungsmethode den Speicherplatz reduzierte, wuchs die Anforderung an die Rechenleistung. Die unzureichende Leistung der verfügbaren Computer verhinderte zunächst die Verbreitung von Vektorschriften. Was erfahrene Anwender als die “Desktop-Publishing-Revolution” von Mitte der 80er Jahre kennen, erscheint im Rückblick als Zusammentreffen verschiedener technischer Entwicklungen, zum Beispiel auch der Wysiwyg-Layoutprogramme Pagemaker und Ventura Publisher.

Entscheidend für das Fortkommen der Schriften waren die von Adobe entwickelte Seitenbeschreibungssprache Postscript sowie ein Drucker, der damit umgehen konnte: der Apple Laserwriter. Für Postscript definierte Adobe ein Schriftformat, das bis heute im Einsatz ist. Sein Vorteil war, dass es den relativ bescheidenen Hardware-Gegebenheiten seiner Entstehungszeit gerecht wurde. So entstand die Postscript-Schrift Type 1 von 1985 [3]. Während die ersten Postscript-Drucker schon lange verschrottet sind, ist Postscript selbst ein unverzichtbarer Bestandteil der meisten modernen Druckvorgänge geworden, auch unter Linux. Auch das allgegenwärtige PDF-Format ist ein Postscript-Abkömmling.

Abbildung 3: Dank der Vektorisierung von Schriftzeichen erfährt die 12-Punkt-Schrift (links) beim Hochskalieren zur Punktgröße 48 keinerlei Qualitätseinbußen. Die Kanten bleiben im Gegensatz zu hochskalierten Bitmap-Schriften glatt (rechts).

Eine Postscript-Schrift erhält ihr Aussehen durch kubische Bézierkurven, also durch vier Punkte, von denen zwei den Anfangs- und Endpunkt bezeichnen und zwei als Kontrollpunkte den Verlauf der Kurve beschreiben (Abbildung 4). So stellt eine kubische Bézierkurve auch Wellenlinien dar, da jeder der Kontrollpunkte einen Scheitelpunkt ausrichten kann. Auf diese Weise muss das System Schriften nicht mehr Pixel für Pixel speichern, auch die Notwendigkeit einer Datei pro Schriftgröße entfällt.

Die erste Schrift

Type 1 war das erste kommerziell erfolgreiche Schriftformat, obwohl der Umgang damit eher umständlich war, denn es besteht aus mehreren Dateien. Die Firma Adobe weigerte sich zunächst die Type-1-Spezifikation offenzulegen. Stattdessen verlangte sie hohe Lizenzgebühren von Unternehmen, die solche Schriften herstellen wollten. Auch bestand der Schriftenpionier darauf, dass Anwender seinen Adobe-Type-Manager installieren, um Postscript-Schriften am Bildschirm darzustellen.

Abbildung 4: Die Postscript-Schriften erhalten ihre Gestalt mittels kubischen Bézierkurven, die auch Bézierkurven dritten Grades heißen.

Aufbauend auf Type 1 entstand dennoch eine Reihe weiterer Postscript-basierter Fonts für besondere Zwecke [4]. Die Einführung so genannter Core Fonts, die zusammen mit dem Laserwriter auf den Markt kamen, entlasteten schließlich auch die CPU. Core Fonts sind Sätze ausgewählter Schriften in verschiedenen Schnitten, die in Postscript-Druckern liegen. So wandert die Konvertierungsarbeit in den Drucker ab.

Abbildung 5: Linux legt Type-1-Schriften jeweils als AFM- und als PFB-Datei ab, wie ein Blick mit dem Dateibrowser in ein beliebiges Schriftenverzeichnis zeigt.

Obwohl Postscript-Schriften einen Fortschritt brachten, zeigen sie auch Nachteile. So fallen dieselben Schriftdaten wegen unterschiedlicher Berechnung der Einheit “Punkt” (Dot) auf Macs anders aus als etwa unter Unix. Der Austausch von Layout-Daten zwischen den Systemen ist also schwierig.

Hinzu kommt die Aufteilung der Fontdaten auf verschiedene Dateien (Abbildung 5). Die Glyphen, also die grafische Einheit des Schriftzeichens, stecken in einer Datei mit der Endung PFB (binär) oder PFA (Ascii). Die zugehörigen Metrikdaten, etwa die Breite des Schriftzeichens, stehen dagegen in AFM-Dateien. Während Letztere meist nur für Unix-artige Systeme interessant sind, verlangen DOS-, Windows- und Apple-Betriebssysteme bis heute weitere Datensätze, um die Schrift anzeigen zu können.

Abbildung 6: Das Truetype-Schriftformat verwendet zur vektorialen Darstellung der Zeichen die weniger rechenintensiven quadratischen Bézierkurven (Bézierkurven zweiten Grades).

Die wahre Schrift

Die rigiden Lizenzbedingungen Adobes sowie die Mehrfach-Dateien der Type-1-Schrift veranlassten Apple zu einem alternativen Schriftformat. 1991 erblickte es unter der Bezeichnung Truetype [5] das Licht der Welt. Im Gegensatz zu Postscript-Schriften bestehen Truetype-Schriften nur aus einer einzigen Datei. Darüber hinaus verwenden sie quadratische Bézierkurven, die beim Rendern weniger rechenintensiv sind. Bei dieser Bézierkurve gibt es nur einen Kontrollpunkt, der den Ausschlag der Kurve bestimmt (Abbildung 6).

Obwohl das Truetype-Format nach der Lizenzierung durch Microsoft gleichsam zum Standardformat für die meisten Computeranwendungen wurde, lehnten Grafiker und Layouter, die auch Schriften entwarfen, es ab. Das waren jedoch gerade jene, denen es die Arbeit erleichtern sollte. Ihre Begründung lautete: Eine qualitativ hochwertige Truetype-Schrift sei zu arbeitsaufwändig. Zwei Jahre waren immerhin keine Seltenheit. Das dauerte deswegen so lange, weil pro Zeichen einer Truetype-Schrift sehr viele Punkte zu definieren sind.

Abbildung 7: Das Opentype-Format unterstützt auch Ligaturen und Sonderzeichen, wie sie zum Beispiel in der Schrift Linux Libertine enthalten sind, hier angezeigt vom freien Fontmanager Fontmatrix.

Die offene Spezifikation sowie das Aufkommen preiswerter Font-Editoren führten jedoch dazu, dass sich massenweise minderwertige Truetype-Schriften verbreiteten. Das hatte Probleme beim Drucken zur Folge, zum Beispiel fehlten Punkte in einzelnen Zeichen. Diese Schriften geistern heute immer noch durchs Web, etwa auf Seiten mit kostenlosen Schriften. Im professionellen Druck sollte man daher darauf achten, woher eine Truetype-Schrift kommt. Für den Tintenstrahldrucker im Alltagsgebrauch ist das Problem hingegen nicht ganz so groß.

Gleichwohl etablierte sich das Truetype-Format. Adobe reagierte, indem es einerseits 1991 die Type-1-Spezifikation freigab und andererseits mit dem Type-42-Format einen Postscript-Container für Truetype-Schriften schuf. Damit erkannte der Konzern die Gleichwertigkeit beider Formate unausgesprochen an.

Die offene Schrift

Das Opentype-Format [6] entstand Mitte der 1990er Jahre aus einer Kooperation zwischen Microsoft und Adobe heraus. Ziel war es, die Vorteile von Type 1 – etwa die einfachere Herstellung – und die von Truetype – dass es zum Beispiel nur eine Datei gibt – zu verbinden. Außerdem bestand Bedarf an einem Schriftformat, das erweiterte typographische Funktionen wie automatische Ligaturen bietet – also die Verbindung zweier Buchstaben – und das außerdem komplexe Schriften unterstützt, wie sie vor allem in Asien anzutreffen sind (Abbildung 7). Bei komplexen Schriften besteht ein Zeichen nicht aus einer ungeteilten Glyphe, sondern setzt sich aus mehreren Teilen zusammen.

Abbildung 8: Viele Truetype-Schriften – Endung ».ttf« – stehen zum freien Download bereit. Sie eignen sich aber oft nicht für den professionellen Druck.

Das Opentype-Format ist vereinfacht gesagt ein Truetype-Container, der sowohl Truetype- als auch Postscript-Daten enthalten kann. Die Spezifikation schreibt die Datei-Endung nicht vor. In der Regel enden Opentype-Dateien mit Postscript-Daten auf OTF, während solche mit Truetype-Inhalt, etwa die Windows-Systemschriften, weiterhin TTF verwenden (Abbildung 8). Beiden Dateitypen ist gemeinsam, dass sie immerhin über 65000 Zeichen enthalten können, während Type-1-Schriften auf 256 Zeichenelemente beschränkt sind.

Zu den Erweiterungen in Opentype zählt schließlich die Möglichkeit, nicht nur Schrift-, sondern auch Sprachspezifika festzulegen. Ein Programm, das diese Informationen auszuwerten und umzusetzen vermag, automatisiert dann beispielsweise die Anwendung typographischer Regeln [7].

Die Schrift fürs WWW

Der jüngste Spross der digitalen Schriftformatfamilie entstand kurz nach der Jahrtausendwende beim W3C, nämlich die SVG-Schriften (Scalable Vector Graphics, [8]). Obwohl das Konsortium auch an einem Druckstandard namens SVG::Print arbeitet [9], sind SVG-Fonts bisher ausschließlich für die Wiedergabe am Bildschirm gedacht.

Die Stärken und Schwächen eines bestimmten digitalen Fontformats sind nur ein Teil der Gleichung. Mindestens ebenso wichtig ist die Implementierung auf der System- und Anwendungsebene. Obwohl das Konzept eines XML-basierten Schriftformats gerade aus der Sicht von Open-Source-Entwicklern höchst interessant ist, muss man doch eingestehen, dass die Beschränkung auf Bildschirmwiedergabe der weiten Verbreitung nicht förderlich ist. Bisher unterstützen nur das SVG-Toolkit Batik für Javaprogramme [10], die Vektorgrafikbearbeitung Inkscape [11] und der Webbrowser Opera [12] dieses Format. Die Firefox-Entwickler haben die SVG-Verarbeitung für die nächste Version zumindest angekündigt. Gleiches gilt für die Webkit-Programmierer.

Die befreite Schrift

Es ist noch nicht allzu lange her, dass der Umgang mit Fonts Linux-Anwendern erhebliche Geduld abforderte. Das begann mit der Installation im X-Server und fand sein häufig genug unbefriedigendes Ende beim Ausdruck auf Papier. Anwender der ersten Staroffice-Versionen für Linux erinnern sich beispielsweise daran, wie sie die Schriften für das Programm separat konfigurierten und die Bildschirmdarstellung dennoch unbefriedigend war.

Abbildung 9: Unter Linux sorgt die Bibliothek des Freetype-Projekts dafür, dass das System mit den Truetype-Schriften etwas anfangen kann.

Lange Zeit war die Darstellung der Fonts unter Linux auf die Fähigkeiten des X-Window-Systems begrenzt. Die Bitmap-Fonts konnte es gut, die Postscript-Fonts jedoch nur schlecht und andere Formate gar nicht rendern, also anzeigen. Während die Bildschirmdarstellung von Bitmap-Fonts relativ einfach ist, stellen Vektorschriften Entwickler vor große Probleme. Jeder Monitor zeigt Objekte auf einem feinen Raster von Punkten an. Die Kunst ist, Vektordaten in Punkte umzurechnen, ohne die Darstellungsqualität zu beeinträchtigen. Besonders betroffen davon sind kleine Schriftgrößen.

Die plattformübergreifende, in C geschriebene Font-Bibliothek Freetype [13] beantwortete im Linux-Umfeld Anfang der 1990er Jahre den Erfolg des Truetype-Formats. Ab da fand der Umgang mit Vektorschriften seine verdiente Aufmerksamkeit. Es galt, Truetype-Daten auszulesen und zu rendern (Abbildung 9). 2005 löste die Nachfolgeversion 2 die Freetype-Bibliothek ab. Die alte Freetype-Version ist jedoch bisweilen noch auf Systemen mit älteren Anwendungen vorhanden, weil deren API nicht zu der neuen Version kompatibel ist.

Die Technik, Vektor- in Pixelschrift umzurechnen, heißt Hinting [14]. Sie setzt voraus, dass ein Font entsprechende Anweisungen enthält. Erst nachdem Apple 1991 die Truetype-Spezifikation freigegeben hatte, stellte sich heraus, dass der Konzern mehrere Patente auf die Hinting-Technologie besitzt. Das Freetype-Projekt sah sich daher genötigt, ein entsprechendes Feature lediglich als Option zu implementieren und auf die Notwendigkeit einer Lizenz von Apple hinzuweisen.

Im Gegensatz zu Freetype 1, das nur Truetype verarbeitet, kann die Nachfolgeversion mit allen oben beschriebenen Schriften außer SVG umgehen. Darüber hinaus unterstützt sie einige weitere Formate, beispielsweise das SFN-Format, in dem der Font-Editor und -Konvertierer Fontforge [15] einige seiner Schriften speichert. In Freetype 2 haben die Entwickler auch das Problem der Vektor-Raster-Umrechnung beseitigt, indem sie einen so genannten Autohinter eingeführt haben. Er funktioniert unabhängig von den im Font enthaltenen Hinting-Daten: Beim ersten Laden analysiert er die vorgefundenen Fontdateien und erstellt anhand der vorhandenen Metrikdaten seine eigene Konfigurationsdatei.

Abbildung 10: Die Schriftenverwaltung Fontconfig ermöglicht es, in einer XML-Datei systemweit Direktiven für die Anzeige von Schriften festzulegen.

Schriften aufs System

Die systemweite Installation und Verwendung von Schriften gehörte lange zu den größten Ärgernissen für Linux-Anwender, denn eine solche Funktion war praktisch unbekannt. Für viele Anwendungen waren die Fonts eigens einzurichten. Manche Entwickler sahen sich genötigt, irrwitzige Skripte zu schreiben, um die im System verstreuten Schriften überhaupt zu finden.

Die Ehre, dieses Problem beseitigt zu haben, gebührt dem X.org-Entwickler Keith Packard. Seine 2004 vorgestellte Lösung trägt den Namen Fontconfig [16]. Diese Programmbibliothek ermöglicht die systemweite Installation, Verwaltung und auch den Zugang zu Schriften durch Anwendungsprogramme. Sie speichert ihre Daten im XML-Format (Abbildung 10). Fontconfig erlaubt neben der Fontverwaltung auch eine Qualitätskontrolle digitaler Schriften, wovon etwa Scribus [17] immer dann Gebrauch macht, wenn es fehlerhafte Schriften verwirft.

Darüber hinaus enthält die Bibliothek das Kommandozeilenwerkzeug »fc-match«, mit dessen Hilfe sich typographisch ähnliche Alternativen zu einer gewünschten Schrift finden lassen.

Baustellen

Trotzdem hakt es bei Linux noch an etlichen Ecken. Gleiches gilt allerdings auch für andere Betriebssysteme. Ein gravierendes Problem ist die Zwischenablage. Es gibt bisher keine überzeugende Lösung zum Kopieren und Einfügen formatierten Textes. Zuweilen greifen Anwendungen auf Microsofts kompliziertes RTF-Format zurück, manchmal auch auf HTML. Oft beschränken sie sich auf unformatierten Text als kleinsten gemeinsamen Nenner. Asiatischen Schriften kommen sie damit nicht bei. Ein 2008 von Liam Quin (W3C) präsentierter Vorschlag [18], der sich mit komplexen Schriften befasst, hat kaum Resonanz gefunden, denn seine Forderungen laufen auf ein komplett neues Schriftformat hinaus.

Komplexe Schriften, also asiatische, sind auch für sich genommen ein besonderes Sorgenkind. Das Problem ist alt, wurde jedoch mit dem wirtschaftlichen Aufstieg Chinas, Indiens und der Tiger-Staaten dringlicher. Wenn man bedenkt, dass die Standardanforderung an Programme jahrelang lediglich das lateinische Minimalalphabet war, wie es im Englischen verwendet wird, so fällt es nicht schwer, sich die Probleme vorzustellen, die mit Hindi oder Khmer verbunden sind. Dies gilt erst recht, wenn die Ausrede unzureichender Rechenleistung nicht mehr zählt.

Nase vorn

Bisher präsentierten weder Closed-Source-Anbieter eine überzeugende Lösung, noch fand die Open-Source-Szene eine. Allerdings arbeiten einige daran. Pango [19] ist zum Beispiel eine Bibliothek zum Rendern möglichst vieler Schriftsysteme. Obwohl weit fortgeschritten, leidet sie unter ihrer Abhängigkeit von GTK+. Viele Eigenschaften von Pango sind in das wohl wichtigste Projekt zur Internationalisierung auf der Schriftebene eingeflossen: Harfbuzz [20]. Sowohl Qt als auch GTK+ machen von Harfbuzz Gebrauch.

Auf dem Entwicklungsfeld der digitalen Schrifttechnologie mussten sich die auf Server und Datenbanken konzentrierten Systeme Unix und Linux ursprünglich kaum schlagen. Die treibenden Kräfte waren Adobe, Apple und Microsoft. Heute stellen fortgeschrittene Schriften für offene Betriebssysteme kein Problem mehr dar. Im Ringen um Internationalisierungen dürfte Open Source sogar führend sein, weil hier die Lokalisierungsarbeit nicht nach betriebswirtschaftlichen Gesichtpunkten erfolgt. Schriftsysteme kleinerer Staaten wie Vietnam finden so endlich eine Chance. (ake)