Altes Layout replizieren.

[Laptop]

Hallo. Ich suche Ratschläge, wie man Schriftsatz aus Texten der Renaissance am besten nachsetzt (nennt man das so? ich meine replizieren). Und zwar vor allen Dingen die lateinische Schrift mit den damals üblichen Ligaturen -us, -is, ct, ?i, tz, oder auch q in Verbindung mit dem z mit Unterschlinge. Bisher scheitere ich an der mangelnden Unicode-Unterstützung dieser Ligaturen. Möchte das ganze aber dennoch möglichst ohne Kompromisse setzen und dann maschinenlesbar und barrierefrei veröffentlichen. Das letzte Kriterium schließt daher Indesign oder so etwas aus, da das nicht barrierefrei ist. Dank Unicode, die sich weigern Lösungen für Ligaturen zu implementieren bin ich wohl zu einem Workaround gezwungen. Meine bisherigen Erwägungen:

1. Ich setze es in HTML mit einem Spezialfont (welchen kann man dazu nehmen) und lade den Font via @font-face.

2. Ich setze es in Word, exportiere nach PDF und integriere einen Spezialfont in die PDF.

Meine Fragen: Welche Schriftart könnte man nehmen? (siehe im Anhang den Original-Druck)? Oder könnt ihr mir vielleicht zu einem anderen Lösungsweg raten?

[Joshua K.]

Schau Dich mal auf der Seite der Medieval Unicode Font Initiative um: http://www.mufi.info/. Die MUFI erarbeitet Empfehlungen, die allgemein anerkannt sind, für die PUA-Codierung von Zeichen, die im Unicode (noch) nicht enthalten sind. Einige Zeichen wurden auch schon aus der MUFI-Empfehlung in den Unicode übernommen. Auf der Seite sind einige Schriften aufgeführt, die MUFI-Zeichen enthalten, darunter zum Beispiel eine kostenlose Fassung der Andron.

Damit könntest Du also die nötigen Zeichen Unicode-codiert in Deinen Text einfügen, und am Ende eine PDF-Datei draus erzeugen, um sicherzugehen, daß der Text mit einer Schrift dargestellt wird, die die benützten Zeichen enthält. Es wäre gleich ob Du dafür InDesign, Word oder ein anderes Programm benützt.

[Laptop]

Hallo. Ja, kenne MUFI und benutze auch einen MUFI-Font (LeedsUni). Ich habe mich mal durch die 245-seitige Empfehlung der MUFI gewühlt, da gibt es ja die merkwürdigsten Zeichen, doch eine is- oder us-Ligatur habe ich vergebens gesucht, dabei ist sie doch gängig in allen Druckerzeugnissen auf dieser Zeit?

[Phoibos]

wo siehst du denn -us und -is ligaturen?

[Sebastian Nagel]

meinst du damit sowas?

(Das ist aus der Rialto DF italic – hat allerdings keine lateinischen Abkürzungszeichen etc.)

[Sebastian Nagel]

Meine demnächst (wirklich!) erscheinende Tierra Nueva hat lateinische Abkürzungsligaturen für "per" (p mit Querbalken) und "qe" (q3), ziemlich viele langs-Ligaturen, etc., aber auch keine us- oder is-Ligaturen.

Außerdem ist die Anmutung weniger "sanft", da Kupferstecher-Werkzeugen nachempfunden, nicht mit Stempeln gedruckt.

[Laptop]

Hallo Herr Nagel, ich habe noch einmal nachgeschaut, soweit ich das sehe erscheinen die us- und is-Ligaturen im mir vorliegenden Druck ausschließlich in der Kursive! Sie weichen in der Form auch von dem von Ihnen geposteten Abbild ab. Hier ein Beispiel MUFI kennt diese Ligaturen also nicht?

[Joshua K.]

Ich kann mich auch nicht erinnern, so einen Verbund schon mal in einer Starrschrift (aufrechten Antiqua) gesehen zu haben. Hast Du die auf der MUFI-Seite angebotenen Schriften alle durchgesehen? Falls keine der Schriften die Verbünde enthält, dann vielleicht eine der Andron-Fassungen. Die umfangreichste Fassung (Andron Mega) kostet allerdings 390 € …

[Laptop]

Ich kann mich auch nicht erinnern, so einen Verbund schon mal in einer Starrschrift (aufrechten Antiqua) gesehen zu haben. Hast Du die auf der MUFI-Seite angebotenen Schriften alle durchgesehen? Falls keine der Schriften die Verbünde enthält, dann vielleicht eine der Andron-Fassungen. Die umfangreichste Fassung (Andron Mega) kostet allerdings 390 € …

Hallo, deine nette Idee war ja “prä-offizielle Code-Stellen” zu finden, die womöglich künftig offizieller Unicode-Standard werden. Leider finde ich mich auf der MUFI-Seite nicht so gut zurecht, gibt es da eine Art Übersicht oder Such-Funktion für Glyphen? Wie suche ich auf der MUFI-Seite nach einer us- oder is-Ligatur?

[Phoibos]

da die -us- und -is-ligaturen kein standard sind, benötigst du wohl eine schrift, die von jemandem inspiriert worden ist, der jene ligaturen verwendete. wenn du dir stephanus-ausgaben anschaust, wirst du unendliche ligaturen (ca. 300 meinte mein prof) finden, die zum teil recht willkürlich eingesetzt werden (und, der alptraum eines jeden studenten, in früheren handschriften sogar wortgrenzen überbrücken).

[Laptop]

Mag sein, aber us- und is-Ligatur (in der Kursive) ist gang und gäbe in den Drucken aus dieser Zeit. Hier handelt es sich weder um Willkür, noch um irgendein Kuriosum. Von daher bin ich von MUFI enttäuscht!

[Phoibos]

Von daher bin ich von MUFI enttäuscht!

was ziemlich albern ist, da die Medieval Unicode Font Initiative kaum renaissance-zeichen berücksichtigen muss, gelle? ;)

[Laptop]

was ziemlich albern ist, da die Medieval Unicode Font Initiative kaum renaissance-zeichen berücksichtigen muss, gelle? ;)

“Albern” nicht, aber vielleicht hatte ich eine falsche Erwartung.

[Sebastian Nagel]

Die Frage ist, ob sowas überhaupt in den Unicode kommen könnte bzw. muss.

Tragen diese Ligaturen eine eigene Bedeutung, oder sind sie "bloß" eine spezielle Darstellungsform von u+s bzw. i+s?

Wikipedia: Unicode ist ein internationaler Standard, in dem langfristig für jedes sinntragende Schriftzeichen oder Textelement aller bekannten Schriftkulturen und Zeichensysteme ein digitaler Code festgelegt wird.

Der Unicode ist also keine Typografie-Setzkastensammlung, sondern eine Auflistung von Zeichenbedeutungen. Das Schlüsselwort ist hier sinntragend: Ligaturen, Zeichenvarianten wie Kapitälchen, Endvarianten, etc. tragen keinen eigenen Sinn, und werden somit nicht in den Unicode aufgenommen (mit Ausnahme derer, die zuvor in Codepages vertreten waren und aus Kompatibilitätsgründen mitgeschleift werden).

Die "richtige" Lösung ist hier, Glyphen (also grafische Repräsentationen des/der Bedeutungszeichens) mit bestimmten Methoden (derzeit Opentype) auszutauschen, die Bedeutung aber nicht zu verändern. Statt der Glyphenfolge us mit Bedeutung u+s wird die Ligatur u_s angezeigt, immer noch mit der selben Bedeutung u+s. Hätte u_s einen eigenen Unicode-Wert, wäre die Bedeutung eine andere, da würde nicht mehr u+s stehen.

Daraus schließend codiert man Glyphenvarianten nicht mehr irgendwo in der PUA, ob nach einem inoffiziellen Standard oder nach Belieben, sondern legt sie als Glyphen ohne Codepoint an, und erledigt den Austausch über die Software. Software die das nicht schafft, ist halt nicht auf dem Stand der Technik/Forschung/Standardisierung.

Das heißt nicht, dass sowas wie MUFI völlig sinnlos ist: wenn die dort mittelalterliche Zeichen sammeln, die Bedeutung besitzen, kann man das durchaus vorläufig als Pseudostandard in der PUA einheitlich machen, besser als Wildwuchs ist es. Letztlich kommen diese Zeichen dann aber irgendwann in den Unicode, weil das ja gerade dessen Sinn ist.

[Joshua K.]

OpenType-Verbünde sind allerdings ziemlich sinnlos, wenn es darum geht, einen alten Text einschließlich der Verbünde genau wiederzugeben. Damit genau die gewünschten Verbünde auch erscheinen, ist da doch sinnvoller, codierte Verbünde einzufügen. Die MUFI-Empfehlungen sind also nicht nur eine Vor-Norm für Unicode, sondern auch eine Alternative zu Unicode, wenn man codierte Verbünde benötigt.

Die MUFI kümmert sich übrigens schon länger nicht mehr nur um mittelalterliche Zeichen! Hier ist die Zeichenliste in der neuesten Fassung (3.0): http://www.mufi.info/specs/MUFI-Alphabetic-3-0.pdf

Die Verbünde us und is sind wirklich nicht enthalten. Du kannst aber an die MUFI schreiben, und vorschlagen, sie in die nächste Fassung aufzunehmen.

Es könnte auch sein, daß eine Schrift die beiden Verbünde enthält, obwohl sie nicht von der MUFI vorgesehen sind. Ich würde deshalb mal die Schriften auf der MUFI-Seite durchsehen.

[Laptop]

Ich bedanke mich für die ausführlichen Beiträge Herr Nagel und Joshua! Ich glaube nachvollziehen zu können, warum Unicode keine Ligaturen standardisieren will, denn ich vermute der Hintergrund dafür ist, daß sie nicht vom “Hundertsten in’s Tausendste” kommen wollen: wenn ein Kulturkreis die Aufnahme “ihrer“ Ligaturen fordert, fordern es auch andere Kulturkreise, und da mag es in irgendwelchen exotischen Sprachen tausende geben, die alle aufgenommen werden wollen, was eine Schwemme wäre! Andererseits finde ich das auch etwas arg strikt, denn man könnte mit Augenmaß durchaus die Ligaturen bevorzugt “hereinlassen”, die in der Weltkulturgeschichte eine größere Rolle spielten und spielen. Zudem gibt es, denke ich, Bedarf nach standardisierten Ligaturen, ganz einfach aus demselben Grund, warum Standards geschaffen werden: um den Umgang zu erleichtern, bzw. konkret in diesem Falle, Inkompatibilitäten zu vermeiden. Ein “automatic replacement” durch Software (wenn ich das richtig verstanden habe, Herr Nagel?) wäre problematisch. Denn wie Joshua schon bemerkt hat, muß ich bei genauer Transkription darauf achten, was im Original steht, und dort steht manchmal (aus Versehen oder auch nicht) -as, -is, -us als Ligatur, manchmal als getrennte Glyphen. Ein “automatic replacement” würde mir da sozusagen “in die Suppe spucken”. Dies nur als Beispiel. Ja, ich habe auch den Eindruck MUFI ist mehr als nur “medieval” … Den Vorschlag dort mal eine Anfrage zu stellen, werde ich gerne umsetzen.

Am Rande: Ich erwäge gerade die Lösung mit @font-face, wobei ich derzeit das Problem habe, daß Safari 5.1 auf dem Mac die Schriftart partout nicht laden will.

[Minimalist]

[...]Die Frage ist, ob sowas überhaupt in den Unicode kommen könnte bzw. muss.

Tragen diese Ligaturen eine eigene Bedeutung, oder sind sie "bloß" eine spezielle Darstellungsform von u+s bzw. i+s?

[...]

Ligaturen, Zeichenvarianten wie Kapitälchen, Endvarianten, etc. tragen keinen eigenen Sinn, und werden somit nicht in den Unicode aufgenommen[...]

OpenType-Verbünde sind allerdings ziemlich sinnlos, wenn es darum geht, einen alten Text einschließlich der Verbünde genau wiederzugeben. Damit genau die gewünschten Verbünde auch erscheinen, ist da doch sinnvoller, codierte Verbünde einzufügen.[...]

[...] Zudem gibt es, denke ich, Bedarf nach standardisierten Ligaturen, ganz einfach aus demselben Grund, warum Standards geschaffen werden: um den Umgang zu erleichtern, bzw. konkret in diesem Falle, Inkompatibilitäten zu vermeiden. Ein “automatic replacement” durch Software (wenn ich das richtig verstanden habe, Herr Nagel?) wäre problematisch.Umgang zu erleichtern, bzw. konkret in diesem Falle, Inkompatibilitäten zu vermeiden.

Um dem Thread eine weitere Diskussionslinie zu eröffnen: Es stellt sich ja dann die Frage inwiefern der Unicode-Standard überhaupt ausreichend ist, beziehungsweise ob es nicht sinnvoll ist, ihn über seine bisherigen Ziele hinaus zu erweitern. Die Gestaltung des Geschriebenen ist, da sind wir uns zumindest hier im Forum hoffentlich alle einig, im Idealfall durchaus auch sinntragend, über das Aufzeigen von Grammatik und Syntax (Großschreibung, keine Ligaturen an Wortfugen) hinaus. Wenn ich in einem Text eine s_t-Ligatur verwende, dann tue ich das bewusst. Sehr wahrscheinlich möchte ich diese Bedeutung dann auch erhalten sehen, wenn ich den Text beispielsweise Unicodekompatibel notiere, beispielsweise für die Anzeige in einem Webbrowser. Softwareroutinen die einfach jedes st durch ein s_t ersetzen sind, wie wir alle wissen, unzulänglich. Es wäre also durchaus sinnvoll, wenn ich in irgendeinem beliebigen Programm Ligaturen setzen könnte, die dann beispielsweise als s_t kodiert werden, und die Darstellungssoftware dann meinetwegen entscheiden kann, ob sie eine Zeichenkombination oder eine Ligatur darstellt, aber letzteres eben nur dann, wenn ich als Verfasser das an der Stelle auch so vorgesehen habe.

[...]denn man könnte mit Augenmaß durchaus die Ligaturen bevorzugt “hereinlassen”, die in der Weltkulturgeschichte eine größere Rolle spielten und spielen.

Vorsicht, Zündstoff! :wink:

[Phoibos]

ich halte ligaturen im übrigen für das genaue gegenteil von barrierefreiheit (auch das lang-s gehört nicht zu einer barrierefreien publikation).

[Laptop]

Ich denke der Fehler liegt im Ansatz. Ich habe gelernt, daß es bei der Codierung von Sonderzeichen in HTML diakritische Zeichen auch als sogenannte “combining diacritical marks” gibt, und dies vieles erleichtert. Z.B. daß man pro diakr. Zeichen nur noch einen Code braucht, und der Browser sich dann um die entsprechende Darstellung kümmert, sprich das diakr. Zeichen mit dem zugrundeliegenden Buchstaben kombiniert. Das ist schlank und elegant. Nun frage ich, warum wird dieses Baukasten-Prinzip von Unicode nicht ebenso bei Ligaturen praktiziert? Nur ein einziger Code wäre nötig: &liga; und mehr nicht. Bspw. i&liga;s wäre ein i mit s-Ligatur. Wenn die Glyphe nicht vorhanden ist könnte der Browser auch recht unkompliziert das “&liga;” ignorieren, und man hätte die Barrierefreiheit. Wenn man aber für jede mögliche Kombination einen eigenen Codestelle reservieren muß, dann hat das einen Rattenschwanz an Nachteilen, nicht nur die unnötig massenhaft belegten Codestellen …

[U+05E9]

Dank Unicode, die sich weigern Lösungen für Ligaturen zu implementieren

Aus gutem Grund – das ist eben ein Grundprinzip von Unicode. Lies doch z.B. mal die Erläuterungen auf der Unicodeseite zu Ligatures, Digraphs and Presentation Forms.

Nun frage ich, warum wird dieses Baukasten-Prinzip von Unicode nicht ebenso bei Ligaturen praktiziert?

Wird es doch. Die einzelnen Bestandteile einer Ligatur sind in Unicode codiert, alles andere wäre Aufgabe des Browsers (Programms, Opentypefonts, usw.).

Ich glaube für deine (maschinenlesbaren) Zwecke würde sich das TEI-xml-Schema gut eignen. In TEI kannst du nach Herzenslust hunderte von unterschiedlichen Ligaturen, Glyphformen usw. definieren. Die Darstellung (s.o.) ist dann allerdings wieder ein anderes Problem. (Vgl. Kapitel 5 der TEI P5 Guidelines).

[Sebastian Nagel]

Ich bedanke mich für die ausführlichen Beiträge Herr Nagel und Joshua! Ich glaube nachvollziehen zu können, warum Unicode keine Ligaturen standardisieren will, denn ich vermute der Hintergrund dafür ist, daß sie nicht vom “Hundertsten in’s Tausendste” kommen wollen ...

So ist es. Dabei geht es eigentlich nicht um die Frage, was sinnvoll ist und was nicht, sondern darum, was der Unicode sein will/soll, und was nicht – er versteht sich eben als Sammlung sinntragender Zeichen (was ein sinntragendes Zeichen ist, darüber kann man natürlich diskutieren), nicht als Sammlung verschiedener grafischer Repräsentationen von sinntragenden Zeichen.

Deshalb sind z.B. Kapitälchen nicht im Unicode enthalten, auch wenn sie auf grafischer Ebene sinntragende Funktion haben können. Würden sie aufgenommen, müsste man auch drüber nachdenken, ob nicht auch Kursivformen aufgenommen werden (auch die haben, wenn als Auszeichnung in einem Text verwendet, sinntragende Funktion).

Sinntragende Ligaturen wie æ sind übrigens enthalten. Deshalb auch meine Ursprungsfrage: hat die u_s-Ligatur in Reintext (nicht in grafischer Repräsentation eine andere Bedeutung als die Zeichenfolge us? Wenn ja, hätte sie gute Chancen, in den Unicode reinzukommen, sonst vermutlich nicht.

Es gibt Ausnahmen, die speziell aus Kompatibilitätsgründen aufgenommen wurden: Ligaturen wie f_i, s_t, ... sind in alten Zeichencodierungen enthalten, und damit Unicode deren Nachfolger werden kann, sind sie noch mit dabei, aber ausdrücklich als solche Zeichen gekennzeichnet. Prinzipiell gilt das sogar für die Großbuchstaben, die ja auch "nur" grafische Varianten der Kleinbuchstaben sind (oder umgekehrt).

Und auch die ganzen fest kombinierten diakritischen Zeichen (åáàâ...) sind in dieser Form nur enthalten, weil Unicode der Nachfolger älterer Codierungen ist, und das alles auch *heute* funktionieren sollte, und nicht übermorgen, und nich jede Software das schon beherrscht. Im Unicode ist aber auch der Umgang mit der (fortschrittlicheren) Methode kombinierter Diakritika eindeutig definiert, d.h. wenn im Reintext die Kombination a´ steht, und die Schrift und Darstellungssoftware sich an Unicode halten, erscheint in der Anzeige ein á (dabei werden tatsächlich a und ´ nach Schriftart-Anleitung übereinander positioniert. Und für einem Reintext, der nach Unicode geschrieben ist, ist festgelegt, wie die Kombination a´ "zu lesen ist".

Zudem gibt es, denke ich, Bedarf nach standardisierten Ligaturen, ganz einfach aus demselben Grund, warum Standards geschaffen werden: um den Umgang zu erleichtern, bzw. konkret in diesem Falle, Inkompatibilitäten zu vermeiden.

Das sehe ich schon auch so, allerdings eben als Unicode-Zusatz für grafische Repräsentationsformen von sinntragenden Zeichen. Sozusagen eine "Spezialanwendung" für Historiker, etc.

Ich frage mich aber auch gerade, ob nicht auch eine Zusatzanleitung wie bei den diakritschen Zeichen reichen würde, die definiert, wie eine Ligatur in Reintext beschrieben und interpretiert wird (die Darstellung der Form ist dann Sache der Schriftart). s_t wäre demnach eine Ligatur aus s und t. So eine Pseudo-Konvention gibt es übrigens schon, eben um z.B. aus "ligaturverseuchten" PDFs wieder Reintext erhalten zu können.

(Kompliziert wird es natürlich, wenn man beschreiben will, wie diese Ligatur geformt ist – falls es verschiedene s_t-Ligaturen geben sollte, und das wichtig ist.)

Ein “automatic replacement” durch Software (wenn ich das richtig verstanden habe, Herr Nagel?) wäre problematisch. Denn wie Joshua schon bemerkt hat, muß ich bei genauer Transkription darauf achten, was im Original steht, und dort steht manchmal (aus Versehen oder auch nicht) -as, -is, -us als Ligatur, manchmal als getrennte Glyphen. Ein “automatic replacement” würde mir da sozusagen “in die Suppe spucken”. Dies nur als Beispiel.

Die Opentype-Ersetzungen funktionieren praktisch auf Befehl des Anwenders. So, wie ich in meinem Schriftsatzprogramm auswählen kann, dass ein Wort kursiv gesetzt werden soll, kann ich auch eine Teststelle markieren, und dann die Option wählen, dass hier z.B. Schmuckligaturen aktiviert werden sollen. In der Opentype-Schrift ist dann vom Gestalter der Schrift hinterlegt, was mit diesem Befehl anzufangen ist. So kann z.B. die Kombination st mit aktiviertem Schmuckligatur-Befehl durch die Ligaturglyphe s_t ersetzt werden (so die Schrift eine solche enthält, und die Regel vom Schrifthersteller so definiert wurde).

Codiert bleibt im Reintext aber nur "st", das ist richtig, und je nach Anwendungsfall nicht ganz eindeutig.

In Schriftsatzprogrammen mit Schriftsatzdokumenten (und auch PDF) funktioniert das recht gut – man ist dort halt auf Dokumentformate angewiesen, die vielleicht nicht jedem zugänglich sind. In Browsern ist diese Funktionalität momentan aber noch nicht wirklich verbreitet, und wenn schon (Firefox, Safari mit Zusatzoptionen), lässt sie sich vom Gestalter nicht wirklich steuern (hier findet dann momentan wirklich ein schnödes Auto-Ersetzen statt, was weder typografisch noch inhaltlich sinnvoll ist).

[Sebastian Nagel]

Um dem Thread eine weitere Diskussionslinie zu eröffnen: Es stellt sich ja dann die Frage inwiefern der Unicode-Standard überhaupt ausreichend ist, beziehungsweise ob es nicht sinnvoll ist, ihn über seine bisherigen Ziele hinaus zu erweitern. Die Gestaltung des Geschriebenen ist, da sind wir uns zumindest hier im Forum hoffentlich alle einig, im Idealfall durchaus auch sinntragend, über das Aufzeigen von Grammatik und Syntax (Großschreibung, keine Ligaturen an Wortfugen) hinaus. Wenn ich in einem Text eine s_t-Ligatur verwende, dann tue ich das bewusst. Sehr wahrscheinlich möchte ich diese Bedeutung dann auch erhalten sehen, wenn ich den Text beispielsweise Unicodekompatibel notiere, beispielsweise für die Anzeige in einem Webbrowser. Softwareroutinen die einfach jedes st durch ein s_t ersetzen sind, wie wir alle wissen, unzulänglich. Es wäre also durchaus sinnvoll, wenn ich in irgendeinem beliebigen Programm Ligaturen setzen könnte, die dann beispielsweise als s_t kodiert werden, und die Darstellungssoftware dann meinetwegen entscheiden kann, ob sie eine Zeichenkombination oder eine Ligatur darstellt, aber letzteres eben nur dann, wenn ich als Verfasser das an der Stelle auch so vorgesehen habe.

Wie in meinem vorherigen Beitrag schon angedeutet: eine Alternative dazu, dann für jede grafische Form einen Code festzulegen, wäre ein ausgedehnter Formatierungsstandard. Kursiv, Fett (wie fett?), Kapitälchen, Groß/klein, Ligaturen, Endvarianten, Titelsatz, ...

Solche Dinge sind ja in geschlossenen Formaten schon umgesetzt (ein Indesign-Dokument sieht - mit etwas Glück - in Indesign immer gleich aus). Das nützt natürlich wenig im offenen Austausch.

In geringerem Umfang gibt es ja Sachen wie BB-Code

[b]asdf[/b]

oder auch HTML, die sind halt einfach nicht differenziert genug.

[Sebastian Nagel]

Ich habe gelernt, daß es bei der Codierung von Sonderzeichen in HTML diakritische Zeichen auch als sogenannte “combining diacritical marks” gibt, und dies vieles erleichtert. ... Das ist schlank und elegant.

Nun frage ich, warum wird dieses Baukasten-Prinzip von Unicode nicht ebenso bei Ligaturen praktiziert? Nur ein einziger Code wäre nötig: &liga; und mehr nicht. Bspw. i&liga;s wäre ein i mit s-Ligatur. Wenn die Glyphe nicht vorhanden ist könnte der Browser auch recht unkompliziert das “&liga;” ignorieren, und man hätte die Barrierefreiheit. Wenn man aber für jede mögliche Kombination einen eigenen Codestelle reservieren muß, dann hat das einen Rattenschwanz an Nachteilen, nicht nur die unnötig massenhaft belegten Codestellen …

Genau. Es gibt ein Regelwerk, wie diese Diakritika angelegt und interpetiert (positioniert) werden müssen – somit klappt das (in der Praxis wird es noch selten angewendet).

Auf die selbe Art könnte das für Ligaturen funktionieren, wobei man berücksichtigen muss, dass diese vermutlich weniger modular und flexibel sind wie Diakritika, bei denen man meistens irgendwelche Striche und Punkte positioniert – bei Anhängseln wie dem Ogonek oder Cedilla wird es schon wieder schwierig, wenn das Ergebnis auch noch ästhetisch und schreibtechnisch korrekt sein soll.

Aber der Ansatz ist in etwa das, was mehr oder weniger konsequent praktiziert wird, um die Codes aus einem Satzprogramm, das per Opentype Glyphen austauscht, für die Ausgabe im PDF zu erhalten.

Der Weg ist dort folgender:

Der Setzer möchte eine s_t-Ligatur, statt st. Er aktiviert die entsprechende Opentype-Funktion für diese Textstelle. Der Opentypecode des Fonts ersetzt st durch die Glyphe s_t, die im Font mit diesem Namen hinterlegt ist, aber keinen Codewert hat.

Wird das ganze dann als PDF exportiert, so wird an der ensprechenden Stelle im PDF diese s_t-Glyphe angezeigt (und ihr Name hinterlegt – einen Codewert hat sie ja nicht). Für die Anzeige ist das hinreichend, wenn man diesen Text aber kopieren will, steht man vor dem Problem, dass hier keine Codewerte mehr hinterlegt sind, die Bedeutung ist also verloren gegangen. Allerdings intepretiert Acrobat eine Glyphe mit dem Namen s_t als Ligatur aus s und t, und erzeugt beim Kopieren dementsprechende Codes. Wenn sich alle daran halten (Schrifthersteller, Satzprogramm und Interpreter), funktioniert das.

Die Alternative dazu wäre eben entweder, die Bedeutung zu verlieren (=kaputter Inhalt, grafisch aber korrekt), oder die Ligatur irgendwie zu codieren – womit sich aber alle Anwendungsprogramme, Schriften, ..., die mit so einem Text was zu tun haben, an diese Codierung halten müssen. Ob das in der Praxis umsetzbar ist?

[Joshua K.]

In PDF-Dateien ist meines Wissens die CMAP-Tabelle dafür verantwortlich, die benützten Zeichen (z.B. Verbünde) Unicode-Zeichen zuzuordnen, und nicht der Zeichenname. (Vielleicht verwenden ja manche Programme [inDesign?] die Zeichennamen, um eine CMAP-Tabelle zu erzeugen.)

Für gewöhnliche Anwendungen sind ja OpenType-Verbünde völlig ausreichend: Wenn ein Text in einer anderen Schrift angezeigt wird, werden eben die Verbünde, die die neue Schrift nicht hat, auch nicht angezeigt, sondern stattdessen wieder die Einzelbuchstaben. Das ist ja normalerweise auch nicht schlimm.

Möchte man programmunabhängig anzeigen, daß ein Zierverbund nur an bestimmten Stellen stehen soll, könnte man ja den Zero-Width Joiner verwenden (das wäre also so etwas wie der erwähnte HTML-Befehl &liga;). Die Frage ist, ob die Schriften das auch „verstehen“, also dafür auch eine Ersetzung eingebaut haben.

Für die genaue Transkription reicht das aber nicht aus (es sei denn, man erzeugt eine PDF-Datei oder ähnliches, worin der Text in seiner gegenwärtigen Erscheinung „eingefroren“ ist). Wenn in einem Text immer genau die gewünschten Verbünde angezeigt werden sollen, nicht mehr und nicht weniger, sehe ich als einzige Möglichkeit codierte Verbünde. Vielleicht wäre ja möglich, irgendwie eine CMAP-Tabelle zu erzeugen, die den PUA-codierten Verbünden ihre Einzelbuchstaben zuordnet? Dann wären die codierten Verbünde wenigstens in PDF-Dateien such- und kopierbar.

Da das aber ein Faß ohne Boden ist, und für normale Anwendungen ja auch sinnvoller ist, keine codierten Verbünde zu haben (sondern durch OpenType erzeugte), ist meiner Meinung nach eine Alternativnorm (MUFI) sinnvoller, als Verbünde in Unicode aufzunehmen.

Übrigens enthält Unicode mittlerweile sehr wohl Kursivbuchstaben, Kapitälchen, fette Buchstaben, sogar Frakturbuchstaben und einiges mehr: Nämlich für den Mathematiksatz, wo die verschiedenen Schriftarten ja eine bestimmte Bedeutung haben. Ich halte trotzdem nicht für gut, diese ganzen Zeichen in den Unicode aufzunehmen: Je nach verwendeter Mathematiknorm, nach Fachgebiet und persönlichem Geschmack können auch beim Formelsatz die Schriftarten verschiedene Bedeutungen haben; und ist das beim gewöhnlichen Textsatz groß anders? Da werden die Schriftarten doch auch meistens benutzt, um eine inhaltliche Bedeutung auszudrücken, die sich eben auch von Fall zu Fall unterscheidet. Solche Bedeutungen sollten meiner Meinung nach nicht auf der Ebene der Codierung, sondern auf der Ebene des Satzprogramms bezeichnet werden (z.B. durch XML).

[Laptop]

Ich freue mich über die guten Beiträge. Um auf ihre Frage einzugehen, Herr Nagel: meine Auffassung von “sinntragend” ist schon eher wenig tolerant, und ich sehe bspw. die von mir gewünschte us-Ligatur durchaus als reine Darstellungsform ohne sinntragende Funktion. Aber ich denke wir (als Schriftsetzer und Ästheten) sind uns alle einig, daß offene Standards auch für “sinnfreie” (semantisch unerhebliche) Darstellungsformen durchaus nötig sind und fehlen, Unicode hin, Unicode her. Und um nochmal kurz zusammenzufassen: Unicode erklärt sich nicht bereit, solche Standards zu setzen, da sie sich auf die funktionale (semantische) Ebene beschränken möchten. Wäre da nun nicht das W3C gefordert, sich um solche Standards im Bereich der Formatierung und Darstellungform zu kümmern? Doch seit Jahren passiert in dieser Hinsicht nicht viel und HTML ist für Gestaltung nach wie vor ein Graus, es wirkt auf mich nicht durchdacht, nicht benutzerfreundlich, und hinderlich für jedes Layout, was über die primitivste Erscheinung hinausgeht. Doch wie löse ich jetzt konkret mein Problem? Der Zero Width Joiner wird soweit ich weiß von keinem Browser so interpretiert, daß er zu Ligaturen führt. Mir bleibt wohl vorerst nichts anderes übrig, als einen Font zu suchen, der über alle von mir benötigten Ligaturen und sonstigen Sonderzeichen verfügt, und dann vorbei an jedem Standard in HTML (vielleicht mit @font-face) oder PDF zu wursteln. Barrierefreiheit ist für mich ganz wesentlich.