Hat das einen Grund, weshalb die Glyphen für langes s, ij, fi, ff, ffi, ffl, fl nicht an den durch Unicode definierten Codes vorhanden sind?
Ebenso kann man A, O, U, a, o, u mit kleinem e darüber nicht mit dem jeweiligen Buchstaben A +
U+0364 COMBINING LATIN SMALL LETTER E erzeugen. Analog die Abbreviaturen für mm un nn nicht mit z. B. m +
U+0304 COMBINING MACRON.
Das betrifft zumindest die LOV.BreitkopfFraktur und die LOV.UnicodeFraktur und bei flüchtigem Durchschauen auch allen anderen Schriften von Ligafraktur.
Das schränkt die Einsatzmöglichkeit dieser Schriften stark ein, wenn der Unicode-Standard und Best Practice der Font-Erstellung nicht eingehalten werden.
langes s, ij, fi, ff, ffi, ffl, fl
Wo soll da ein Lang-ſ hin, man kann doch nicht einfach ein f durch ein ſ ersetzen?
Nehme an sie sind UNZ 1 Codiert, bin mir aber bei den vollfunktionalen nicht sicher.
Wo soll da ein Lang-ſ hin, man kann doch nicht einfach ein f durch ein ſ ersetzen?
Nehme an sie sind UNZ 1 Codiert, bin mir aber bei den vollfunktionalen nicht sicher.
Nein, sie sind LOV kodiert, d. h. angeblich OpenType aktiviert.
Das lange s soll ganz einfach dort hin, wo es in Unicode vorgesehen ist, nämlich auf U+017F. Das runde r steht ja auch richtig auf U+A75B in der LOV.AlteSchwabacher. Dort steht dafür das lange s gleich zweimal in der PUA an der falschen (nicht MUFI konformen) Stelle U+F1AA und U+F1AD. Das m mit Querstrich drüber steht auf U+E5D2 (MUFI wäre U+E5B8), dafür steht das n mit Querstrich drüber auf der richtigen MUFI-Stelle U+E5DC. Für die Umlaute mit kleinem e darüber werden in Unicode bereits belegte Stellen missbraucht.
Das heisst in einfachen Worten: Wenn ich einen Text habe, der mit langem s kodiert ist, ebenso die in Unicode vorhandenen Ligaturen
ij, fi, ff, ffi, ffl, fl; # funktioniert hier
A, O, U, a, o, u mit U+0364 COMBINING LATIN SMALL LETTER E:
Aͤ Oͤ Uͤ aͤ oͤ uͤ # funktioniert hier
m, n mit U+0304 COMBINING MACRON:
m̄ n̄ # funktioniert hier (aber schaut nicht gut aus)
dann bekomme ich Zeichen aus einer anderen Schrift, welche diese Zeichen hat. Oder gar keine, d. h. einen Fehler.
Hier kommen ein paar Anmerkungen zu den LOV-Schriften vom Hersteller:
Vollfunktionale OpenType(OT)-Schriften wie die LOV-Schriften enthalten in der Regel weder ein codiertes Lang-ſ noch codierte Ligaturen und sollten sie auch nicht enthalten. Alle diese Frakturzeichen liegen auf uncodierten Zeichenplätzen und werden durch die OT-Programmierung angesteuert. Unicode-codiertes Lang-ſ und Ligaturen wären hier kontraproduktiv. Ein OT-Text ist eigentlich ein ganz normaler Antiquatext nur mit Rund-s ohne Ligaturen. Das sieht man, wenn man den Text in einer Datei speichert. Nur die für die Textanzeige gewählte OT-Schrift sorgt dafür, daß z.B. s den Regeln entsprechend als Lang-ſ oder Rund-s oder f t als ft-Ligatur oder als f t auf dem Bildschirm angezeigt wird; im Text bleibt es aber immer beim s bzw. f t.
Zu Unicode und OT kann man sagen: Für den OT-Teil OpenType-programmierter Schriften ist der Unicode-Standard nicht zuständig und wird durch ihn nicht geregelt. Einen Standard oder eine »Best Practice«, wie die OT-Programmierung von Schriften, insbesondere Frakturschriften auszusehen hat, gibt es nicht.
Noch eine Anmerkung zu den nur in den LOV-Schriften enthaltenen Unicode-Privat-codierten Lang-ſ-Zeichen, die bei einer ersten Durchsicht der Schrifttabelle vielleicht irritierend wirken: Sie haben mit dem normalen Lang-ſ nichts zu tun und sind lediglich Hilfszeichen zur Textsperrung im Ligafaktur-Programm. Textsperrung in OT-Texten ist schwierig, weil OT-generierte Ligaturen wie ſi beim normalen Sperren immer als ein einziges Zeichen auftreten, egal wie groß die Sperrweite ist. Da muß man ein paar Tricks anwenden, um auch das ſi trennen und sperren und in diesem Fall die OT-Programmierung überlisten zu können.
Zu einem ganz anderen System gehören die LUC-Schriften mit auschließlich codierten Frakturzeichen. Lang-ſ und Ligaturen bilden sich nicht von selbst wie bei den LOV-Schriften, sondern müssen z.B. mit Hilfe von Ligafaktur in den Text eingefügt werden. Anders als Frakturtexte mit LOV-Schriften werden Texte mit codierten Zeichen aber schriftunabhängig als Frakturtexte gespeichert und können als solche auch ohne Schrift erkannt werden; bei Texten, dargestellt mit vollfunktionalen OT-Schriften, sind es dagegen wie erwähnt reine Antiquatexte, die keinen Hinweis auf einen Frakturtext enthalten.
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.
Danke für den Hinweis auf die LUC-Schriften. Der Unterschied war mir nicht bewusst, weil ich angenommen habe, dass sich eine "vollfunktionale OT-Schrift" so verhält, wie das üblicherweise OT-Schriften für historische (und auch moderne) Texte machen.
Unicode und OT ergänzen sich gegenseitig. Das eine ist ohne das andere nicht denkbar. Unicode legt nur die Kodierung, Bedeutung und die Eigenschaften der Zeichen fest, aber nicht deren genaues Aussehen. Fonts realisieren die Eigenschaften von Unicode-Zeichen in optisch abgestimmter Art und Weise. So legt Unicode z. B. nur fest, wo ein Akzent (COMBINING CHARACTER) bei einem Zeichen hinkommt (links oben, oben mittig, rechts oben etc.). Dafür gibt es in Unicode potentiell 255 Möglichkeiten. Ebenso ist die Reihenfolge der Akzente in Unicode normiert, wenn z. B. mehrere Akzente über ein einzelnes Zeichen angeordnet werden. Im Font legt man nur fest, wie das fein abgestimmt auszusehen hat.
Wenn ein Hilfszeichen zwecks Vereinfachung nötig ist, dann spricht ja nichts dagegen, das in der PUA zu definieren. Aber warum wird das lange s nicht auch dort definiert, wo es seinen Platz in Unicode hat? Das stört überhaupt nicht die Logik der automatischen s zu lang-s Darstellung. So habe ich das auch als Selbsthilfe gemacht - einfach den Glyph an die richtige Stelle kopieren. Wäre doch viel praktischer, wenn ein Font mehreren Verwendungen zugänglich ist, also den originalgetreuen Kodierern genauso wie den modernen Tippern (rundes s). Dass das geht, beweisen Fraktur-Fonts wie z. B. UniFraktur-Maguntia und -Cook.
Andere Schriftsysteme wie Arabisch, Indisch, Hangul haben wesentlich komplexere Regeln. Und weder langes s noch gebrochene Schriften sind eine deutsche Besonderheit. Langes s wurde bis ins 19. Jahrhundert auch in Antiqua und Kursiven verwendet. Gebrochene Schriften gab es praktisch in ganz Nordeuropa, sogar in Frankreich.
Lesen Sie dazu bitte meinen Beitrag
Langes ſ und Ligaturen in vollfunktionalen OpenType-Frakturschriften im Themenblock Fraktur Digital,
der sich an meinen Beitrag vor Ihrem anschließt und Ihre Frage zum langen ſ beantwortet.
Guten Abend,
Mit [alt] + [0150] setze ich den dt. Gedankenstrich [–] (im Gegensatz zum Minus [-]) in Textverarbeitungsprogrammen.
Meine Frage: Wie setzte ich das Lang-s als Kombination von [alt] und einer Zahl ?
Verbindlichen Dank!
Die ANSI-Zeichen können mit Alt+[bis 0255] weitgehend unabhängig vom Textprogramm gesetzt werden. Dagegen hängt das Einfügen der meisten höheren Unicode-Zeichen, zu denen auch das lange ſ gehört, vom Angebot des aktuellen Textprogramms ab (Sonderzeichentabellen, spezielle Tastenkombinationen).
Wer einen dauerhaften und einfachen Zugang zum langen ſ möchte, kann das kleine kosten-, registrierungs- und werbefreie Programm LSB von http://www.ligafaktur.de/dienst/LSB.zip herunterladen (Voraussetzung für die LSB-Nutzung: PC mit Windows 10, deutsche DIN-Tastatur). LSB erweitert die Tastatur um das Lang-ſ (Unicode 017F) und den Bindehemmer (Unicode 200C), indem es diese Zeichen auf die Tastenkombinationen AltGr+s und AltGr+# legt. Das ist alles. Das Lang-ſ kann dann unabhängig vom Textprogramm mit AltGr+s so schnell wie andere Buchstaben und wesentlich einfacher als mit Alt+#### geschrieben werden.
Werter Utz,
besten DANK!
LSB war in fünf Minuten mit Libre einsatzfähig:
Aſien.
Viele Grüße,
Andreas
Mit der heute neu erschienenen Ausgabe 2.0 des kleinen LSB-Programms (erhältlich bei http://www.ligafaktur.de unter »Weitere Programme«) können jetzt außer Lang-ſ und Bindehemmer wahlweise weitere fraktureigene und andere Zeichen zugeschaltet und mit AltGr als Vorschalttaste gesetzt werden wie rundes r, überstrichenes m und n, Umlaute mit übergesetztem e sowie allgemeine Anführungs-, Auslassungs- und Leerzeichen.
Dieser kleine „Setzkasten“ ist für Anwender gedacht, die Frakturzeichen selbst auswählen, setzen und ihre Texte selbst kontrollieren möchten. LSB sollte daher nicht gleichzeitig mit anderen Tastaturprogrammen (Ligafaktur u.a.) verwendet werden, die diese Zeichen selbsttätig oder auf andere Art setzen.
Einzelheiten zur neuen LSB-Ausgabe können Sie in der Anleitung http://www.dienst.ligafaktur.de/LSB.pdf nachlesen.
