Das zuletzt unter »Ligafaktur 10« diskutierte Thema der OpenType-Schriften paßt dort nicht ganz hinein. Ich möchte es hier als eigenständiges Thema fortsetzen.
Zu diesem Thema, besonders zur Frage der Codierung scheint noch manches unklar zu sein. Deshalb möchte ich das Prinzip am Beispiel des Lang-ſ hier noch einmal ausführlicher für alle Interessierten diskutieren.
Vollfunktionale OpenType-Frakturschriften (nur um diese geht es) enthalten möglichst alle Fraktursatzregeln und erzeugen selbsttätig einen regelgerechten Frakturtext beim normalen Schreiben. Normales Schreiben bedeutet aber, daß im Text kein codiertes Lang-ſ verwendet werden kann, denn als höheres Unicode-Zeichen kann es nicht einfach mit einer Tastaturtaste gesetzt werden, sondern müßte durch ein Hilfsprogramm, aus einer Zeichentabelle des Textprogramms oder mit einem Tastenkürzel für höhere Unicode-Zeichen eingefügt werden, also meist aufwendig und nicht beim normalen Schreiben mit einer DIN-Tastatur möglich. Das widerspräche auch dem Anspruch vollfunktionaler OT-Schriften.
Daher bleibt nur die virtuelle OpenType-Lang-ſ-Darstellung aus dem Rund-s, das einfach mit der s-Taste beim normalen Schreiben gesetzt wird. Die Lang-ſ-Darstellung aus dem Rund-s erfolgt ausschließlich über die Namen der Zeichenplätze, nicht über deren Codes, also beispielsweise mit der OT-Befehlszeile »sub s by longs« (= ersetze auf dem Bildschirm das Zeichen auf dem Zeichenplatz namens s durch das Zeichen auf dem Zeichenplatz namens longs). Der Unicode-Standard, der nur die Codes der Zeichenplätze festlegt, hat mit den Namen der Zeichenplätze, die OpenType verwendet, nichts zu tun. Umgekehrt ist es für die OpenType-Befehle egal, ob der Zeichenplatz namens longs codiert ist oder nicht, weil sie nichts mit den Unicode-Codes anfangen können. Trotzdem ist es besser, den longs-Zeichenplatz nicht zu codieren, weil es sonst möglich wäre, das Unicode-codierte Lang-ſ über Zeichentabellen usw. (s.o.) in den Text einzufügen. Dann gäbe es zwei Lang-ſ-Arten mit identischem Aussehen. Das codierte Lang-ſ aber reagiert bei Textänderungen nicht auf die Befehle einer üblichen vollfunktionalen OT-Programmierung* und kann zu Fehlern führen oder verhindert evtl. die regelgerechte Schreibung des Wortes, in dem es vorkommt.
Auch wenn die OT-Schrift kein codiertes Lang-ſ enthält, fügen doch manche Textprogramme, wenn das Lang-ſ codiert gesetzt wird, dieses mit einer anderen Schrift in den Text ein. Das wäre dann aber leichter zu erkennen und ggf. zu entfernen.
Was am Beispiel des Lang-ſ diskutiert wurde, gilt gleichermaßen für die Ligaturen, die ebenfalls nicht codiert sein sollten. Damit sind Texte, die mit diesen Schriften dargestellt werden, reine ASCII/ANSI-Antiquatexte ohne codierte höhere Unicode-Frakturzeichen wie Lang-ſ und Ligaturen. Entsprechend sind vollfunktionale OpenType-Frakturschriften normale ASCII/ANSI-Schriften mit zusätzlichen uncodierten Lang-ſ-/Ligatur-Zeichen und einer (aufwendigen) OpenType-Programmierung, die diese Zeichen abhängig vom zugrundeliegenden ASCII/ANSI-Text den Frakturregeln entsprechend auf dem Bildschirm (und beim Druck) anzeigt.
* Theoretisch wäre es möglich, neben dem codierten Rund-s auch das codierte Lang-ſ als Basis in eine OT-Programmierung einzubeziehen. Das aber wäre überflüssig, extrem kompliziert und viel zu aufwendig, um evtl. Fehler durch ein versehentlich codiert gesetztes Lang-ſ zu beheben.