Regularisierung und Normalisierung, I: 1 2 3, II: 4 5 6 7

5. Wie soll regularisiert werden?

Die Regularisierung eines Textes mit Hilfe von <reg> ist wohlbekannt. Schon vor Beginn des MPDL-Projektes wurde das <expan> aus dem Archimedes-Projekt in <reg> umbenannt, und vor einem halben Jahr wurde die Struktur von <reg> umgestellt:

• Archimedes: <expan abbr="partẽ">partem</expan>
• alt: <reg orig="Original">Korrektur</reg> (wird in dieser Form in keinem Text mehr verwendet)
• neu: <reg norm="Korrektur">Original</reg>

Damit ist <reg> jetzt wie alle anderen tags eine Annotation des Originaltextes.

Neu ist eine weitere Funktion von <reg>: Wenn wir im Rohtext Informationen haben, die wir nicht darstellen können, kommen diese in ein neues Attribut namens "faithful". Beispiele sind griechische Ligaturen und chinesische Zeichenvarianten, die nicht in Unicode sind. (Die Idee, solche Zeichenvarianten in ein Attribut von <reg> zu schieben, stammt von Robert.)

Beispiele für Regularisierungen sind in dieser Tabelle zu sehen.

Ziele

Durch die Regularisierung soll im Idealfall eine Textgestalt geschaffen werden, die zusammen mit der Normalisierung einer klassischen Text-Edition entspricht.

• Wissen über den einzelnen Text und einzelne Textstellen muss in <reg> und nicht in die Normalisierung.
• Halte die Anzahl der benötigten <reg> möglichst klein.
• Idealerweise wird gerade so viel regularisiert, dass die Normalisierung aus dem regularisierten Text die in der jeweiligen Sprache oder Sprachschicht gewünschte Standardschreibweise ergibt.
• Informationen aus dem Rohtext, die wir zurzeit nicht nutzen können, sollen erhalten bleiben. Insbesondere wollen wir Griechisch von Rohtext in XML umwandeln können, ohne Informationen wegwerfen zu müssen.
• Sobald wir solche Informationen anzeigen können, soll dies mit dem unveränderten XML möglich sein.
• Die Suche soll funktionieren.
• Der regularisierte Text soll problemlos anzeigbar sein.
• Die Regularisierung soll robust genug für alle von uns verwendeten Sprachen sein.
• Die Hemmschwelle für Texte aus anderen Quellen soll niedrig sein: Auch Texte ohne <reg> sollen anzeigbar sein.
• Korrekt geschriebene Texte in modernen Sprachen sollten im Idealfall gar keine Regularisierungen benötigen.

Das faithful-Attribut

Das faithful-Attribut nimmt Informationen aus dem Rohtext auf, die wir zurzeit noch nicht richtig darstellen können und die die Suche brechen. (Ein anderer möglicher Name wäre "facsimile".)

Das faithful-Attribut muss nicht verwendet werden, insbesondere bei Texten, die nicht in China abgetippt wurden. Wenn es kein faithful-Attribut gibt, muss es aber, wie bisher auch, das norm-Attribut geben.

In vielen Texten wird es tatsächlich keine Notwendigkeit geben, es zu verwenden. Aber häufig enthalten unsere Rohtexte Informationen, die wir nicht sinnvoll in Unicode kodieren können. Zum Beispiel enthält Pappus 1660 aus Work Order 1 diverse griechische Ligaturen und Abbreviaturen, also Formen wie {πρ}ός (im Text steht meistens die Form {πρ}ὸς). Wir können es zurzeit nicht leisten, die Transkription des griechischen Textes auf Korrektheit zu überprüfen, deshalb verschieben wir die hier erkannte πρ-Ligatur in das faithful-Attribut:

<reg faithful="{πρ}ός">πρός</reg>

Die Informationen über Ligaturen sind insbesondere deshalb enthalten, weil wir eventuelle Transkriptionsfehler der Chinesen korrigieren können wollen. Ein mögliches Szenario: Ein Forscher findet, {πρ} ist falsch transkribiert worden. Festgestellt hat er das, indem er auf das Image der Buchseite geschaut hat. Jetzt kann er mit einer einzigen XQuery alle Stellen von {πρ} im Text finden und alles auf einmal korrigieren. Umgekehrt kann ein Forscher auch beschließen, dass die {πρ}-Ligatur in diesem Text nicht markierenswert ist. Diese Entscheidung muss nicht für weitere Texte gelten, denn sie hängt vom im Buch verwendeten Font ab. (Vermutlich gibt es aber eine Liste von Ligaturen, die in allen Fonts trivial sind.) Dann kann er alle {πρ} durch das simplere πρ ersetzen, also zum Beispiel {πρ}ός durch πρός.

Es wird ein Workflow-Skript geben, das dabei hilft, <reg faithful="{πρ}ός">πρός</reg> durch πρός zu ersetzen. Beachte dabei insbesondere den Fall, dass in einem Wort wie {πα}ρε{σκ}{ευ}ασ{μέν}η die ersten beiden Ligaturen {πα} und {σκ} recht einfach sind, die Ligaturen {ευ} und {μέν} jedoch nicht. Dieses Skript wird auch helfen, <reg> bei nachgetragenen Bindestrichen zu korrigieren, beispielsweise (eigentlich mit soft hyphen):

alt: <reg norm="exem" type="context">exẽ</reg> <lb/>plo
neu: <reg norm="exem- plo" type="context">exẽ-<lb/>plo</reg>

Sobald der Inhalt von faithful sogar mit Unicode-Mitteln dargestellt werden kann, kommt er zurück in den Original-Text.

Das type-Attribut in <reg> wird sich wohl weiterhin nur auf den Inhalt des norm-Attributs beziehen. Es wird sowieso nicht vom Anzeigesystem ausgewertet und soll nur menschenlesbar erklären, wie es zu einer bestimmten Regularisierung gekommen ist.

Zusammenhang mit den Anzeigemodi

Bei den Anzeigemodi ist "faithful" als eine Checkbox von Original realisiert.

	Original	faithful	Regularized	Normalized
orig	orig	orig	orig	normalisiertes orig
<reg norm="reg">orig</reg>	orig	orig	reg	normalisiertes reg
<reg faithful="faithful">orig</reg>	orig	faithful	orig	normalisiertes orig
<reg faithful="faithful" norm="reg">orig</reg>	orig	faithful	reg	normalisiertes reg

Wahrscheinlich werden wir in absehbarer Zukunft keinen Mechanismus zur korrekten Anzeige von Ligaturen wie {πρ} anbieten, so dass im faithful-Modus einfach {πρ}ός angezeigt wird. Die Textdarstellung funktioniert auch ohne einen geeigneten Mechanismus, und der Mechanismus kann jederzeit nachgeliefert werden.

Das norm-Attribut hat immer noch einen unglücklichen Namen, denn der Name klingt, als ob es etwas mit der Normalisierung zu tun hätte. Ich möchte aber auch nicht <reg reg="korrigiert">Fehler</reg> verwenden. Wie wäre es mit "std"?

Die Grenze zwischen orig und faithful

In diesem Abschnitt geht es um die Frage, wo die Grenze zwischen Original und faithful gezogen wird.

Gruppen, die entweder in orig oder in faithful gehören:

1. Unicode-Zeichen: Kernbereich, d.h. alle Zeichen, die auf heutigen Computern problemlos angezeigt werden können (zum Beispiel "a")
2. Unicode-Zeichen: alle offiziellen Codepoints, die direkt einem Zeichen oder einem Diakritikum im Text entsprechen; zum Beispiel
   • Zeichen aus Spezialgebieten, wie der medievalist character "ꝫ", für den man einen MUFI-Font benötigt
   • combining characters, die generell ein Problem sind
   • offizielle Zeichen, für die wir selbst noch keinen Font haben, wie die Alchemie-Zeichen (nur in diesem Fall würden wir nicht den Codepoint selbst, sondern eine escape sequence wie &x1F70D; verwenden)
3. Unicode-Zeichen: PUA der MUFI (zum Beispiel "")
4. Unicode-Zeichen: IDS- und IVS-Sequenzen
5. idiosynkratische Notationen wie {πρ}, {q3-it-a}

Gruppe 1 gehört offensichtlich zu Original. Auch Gruppe 2 soll zu Original gehören; ein Kernbereich von Unicode-Zeichen ist sowieso nicht klar definierbar. Der Benutzer kann den XML-Text mit Zeichen aus diesen Gruppen auf seinem eigenen System im Prinzip mit geringem Aufwand korrekt darstellen. Geringer Aufwand ist zum Beispiel, Unicode-Fonts zu installieren, die bestimmte Codepoints enthalten oder die combining characters korrekt anzeigen. Wir erwarten zum Beispiel, dass der Benutzer sich für chinesische Texte einen Font für die CJK-Extension B installiert. Bei den Alchemie-Zeichen gehen wir davon aus, dass es bald einen freien Font für diese Zeichen geben wird.

Gruppen 4 und 5 gehören zu faithful; für diesen Gruppen ist faithful ja eingeführt worden. Entscheidend ist, dass wir ein Zeichen in der Vorlage nicht durch mehrere Zeichen in Original wiedergeben wollen. Zum Beispiel können wir IDS-Sequenzen, die naturgemäß aus mehreren offiziellen Unicode-Zeichen bestehen, zurzeit noch nicht richtig (d.h. als ein einzelnes Schriftzeichen) darstellen. Eine nicht umgewandelte IDS-Sequenz würde also die Textvorlage nur indirekt wiedergeben. Um diese Gruppen korrekt anzuzeigen, muss man also auf der Server-Seite Programmieraufwand betreiben.

Die PUA

Wir würden gerne einfach alle PUA-Zeichen zum Beispiel der MUFI verwenden, aber unsere Texte müssen in einem Web-basierten System anzeigbar sein. Die Anzeigeprobleme für die vorliegende Wiki-Seite auf dem Bildschirm und auf Papier sind bereits ein Hinweis für die Schwierigkeiten des Themas. Klar ist:

• Wir erfinden selbst keine PUA-Zeichen, sondern verwenden nur PUA-Zeichen aus Standard-Quellen wie der MUFI.
• PUA-Zeichen müssen regularisiert werden.

Bei der Verwendung von PUA-Zeichen gibt es mindestens folgende Fälle:

1. Das Zeichen kann nur durch ein PUA-Zeichen völlig korrekt wiedergegeben werden. Beispiel "", das immerhin durch "qꝫ" angenähert werden könnte. Wie bei griechischen Ligaturen wollen wir aber die im Rohtext vorhandene Information aufbewahren.
2. Das Zeichen kann am besten durch ein PUA-Zeichen wiedergegeben werden, es gibt aber auch nicht-PUA-Alternativen. Beispiel "", das auch "uͦ" geschrieben werden kann.
3. Das Zeichen könnte im Prinzip mit einem PUA-Zeichen wiedergegeben werden, aber wir haben keinen Font, der es dann auch anzeigen kann. Beispiel: kursives "" wie in ſenatori́ (Benedetti p.296). Siehe die ausführliche Diskussion unten.

Die ausstehende Frage zu Original und faithful ist, ob PUA-Zeichen in Original oder in faithful kommen. Regularisiert wird das Wort in jedem Fall, denn zum Beispiel "ꝫ" ist mit oder ohne Ligatur ein Abkürzungszeichen. Man kann also kein <reg> einsparen, wenn man PUA-Zeichen in Original erlaubt, allerdings werden sie bei PUA in faithful durch das zusätzliche faithful-Attribut etwas länger.

Ich neige eher dazu, PUA-Zeichen in faithful zu verschieben.

Für PUA in Original spricht:

• Um MUFI-Zeichen aus Gruppe 2 korrekt anzeigen zu können, muss der Benutzer einen MUFI-Font installieren. Normale Fonts können "ꝫ" nicht anzeigen. Dann kann der Benutzer aber auch bereits Zeichen der Gruppe 3 anzeigen.

Für PUA in faithful spricht:

• Bei offiziellen Zeichen greift der normale Font-Ersetzungsmechanismus: Man muss nur einen MUFI-Font installiert haben, dann wird das Zeichen korrekt angezeigt, selbst wenn man diesen Font nicht als Anzeige-Font verwendet. Ein PUA-Zeichen wird dagegen nur dann korrekt angezeigt, wenn das Zeichen im Anzeige-Font vorhanden ist. Zum Beispiel im Alvarus:
  • PUA in Original: <reg norm="numquam">nū̄</reg>. Original wird nur dann korrekt angezeigt, wenn man sich den Text mit einem MUFI-Font anzeigen lässt.
  • PUA in faithful: <reg faithful="nū̄" norm="numquam">nūq̄ꝫ</reg>. Original wird mit jedem Font korrekt angezeigt, solange es auch einen MUFI-Font auf dem System gibt. (Eventuell hat der verwendete Anzeige-Font auch Schwierigkeiten, ein "combining macron" korrekt als Makron über dem Zeichen anzuzeigen. Um dieses Problem, nämlich dass viele Fonts mit den Standard-Mechanismen von Unicode noch nicht umgehen können, geht es aber hier nicht.)
• Ein konzeptionelles Argument ist, dass der Original-Modus aus offiziellen Unicode-Zeichen bestehen sollte, und dass die PUA-Zeichen, selbst wenn es MUFI-Zeichen sind, eher unseren idiosynkratischen Notationen aus den DESpecs entsprechen. Paul könnte sich den Text dann im faithful-Modus anschauen.
• Im faithful-Attribut könnte man auch die Idee wiederbeleben, das Zeichen durch die Sequenz q́ ZWJ ꝫ darzustellen. Hätte das irgendwelche Vorteile gegenüber dem PUA-Zeichen? Das Problem des ZWJ war, dass er nicht tut, was er tun soll, nämlich dem Font mitzuteilen, dass hier eine Ligatur ist, sondern im Gegenteil Ligaturen aktiv verhindert und die Suche bricht.
• Der XML-Text soll ohne Änderungen auch in zehn Jahren noch korrekt anzeigbar sein. Wenn ein MUFI-Zeichen aus der PUA einen offiziellen Unicode-Codepoint erhält, können aktualisierte Versionen der MUFI-Fonts das Zeichen vom PUA-Codepoint entfernen und nur noch den offiziellen Codepoint korrekt anzeigen. Die Nachbesserung am XML ist zwar an sich trivial und kann von einem maintenance-Skript übernommen werden, aber vielleicht wäre es trotzdem besser, wenn solche Probleme nur innerhalb des faithful-Attributs auftreten können.

Ein weiteres Argument: Benedetti enthält einige medievalist characters, sie werden aber nicht mehr wie im Alvarus standardmäßig verwendet. Ein schwieriger Fall ist das kursive Wort $enatori\'{que} (Benedetti p.296). Das Zeichen {que} könnte wieder mit dem PUA-Zeichen  wiedergegeben werden:

<reg norm="ſenatorique">ſenatori́</reg>

Aber wir haben keinen Font, der es dann auch in seiner kursiven Form anzeigen kann. (Eine Anfrage an die MUFI-Liste ergibt: Es gibt einen kommerziellen Font, der dieses Zeichen enthält (​Andron Mega). Dieser Font ist aber leider nicht frei, so dass wir ihn nicht in einem Web-basierten System verwenden können. Außerdem enthält die allerneueste Version von Junicode von 2010-12-12 dieses Zeichen. Die folgende Diskussion hängt aber nicht an diesem speziellen Zeichen, sondern sie illustriert, was bei PUA-Zeichen passieren kann.)

Stattdessen müsste man schreiben:

<reg faithful="ſenatori{q3-it-a}" norm="ſenatorique">ſenatoriq́ꝫ</reg>

{q3-it-a} wird dann entweder als Text wiedergegeben, oder es gibt eine Datei q3-it-a vom Typ jpg/gif/bmp, svg, etc.

Es ist unklar, in welchem Arbeitsschritt die Information hineinkommt, dass es eine kursive Textstelle ist, und dass wir dieses spezielle Zeichen kursiv nicht anzeigen können. Zur Not wäre das Problem im reg-Skript lösbar. Man kann nämlich automatisiert ein funktionierendes <reg> erstellen:

<reg faithful="ſenatori́" norm="ſenatorique">ſenatoriq́ꝫ</reg>

Wenn zu irgendeinem Zeitpunkt klar wird, dass wir das Zeichen im faithful-Attribut gar nicht anzeigen können, kann man es ändern in

<reg faithful="ſenatori{q3-it-a}" norm="ſenatorique">ſenatoriq́ꝫ</reg>

Der Name {q3-it-a} ist eine Verkürzung des MUFI-Namens "q3app" mit dem Zusatz it für kursiv und a für Akut. {q3-it-a} enthält also den Akut bereits. Selbst wenn wir ein Bild von {q3-it} haben, können wir wohl nicht erwarten, ein Bild korrekt mit einem combining acute anzuzeigen.

Benedetti enthält das Zeichen nur in kursivem Text. Gäbe es das Zeichen auch in normalem Text, würde die entsprechenden <reg> so aussehen:

• PUA in Original erlaubt:
  • upright: <reg norm="ſenatorique">ſenatori́</reg>
  • kursiv: <reg faithful="ſenatori{q3-it-a}" norm="ſenatorique">ſenatoriq́ꝫ</reg>
• PUA in Original nicht erlaubt:
  • upright: <reg faithful="ſenatori́" norm="ſenatorique">ſenatoriq́ꝫ</reg>
  • kursiv: <reg faithful="ſenatori{q3-it-a}" norm="ſenatorique">ſenatoriq́ꝫ</reg>

Dass im zweiten Fall im faithful-Attribut unterschiedliche Dinge stehen, ist unbefriedigend, aber vielleicht nicht zu ändern. (Man könnte den Unterschied eventuell kleiner machen, indem man "ſenatori́" durch "ſenatori{q3-a}" ersetzt. Für {q3-a} könnte dann im System statt einem Bild das PUA-Zeichen ́ hinterlegt sein.) Der Unterschied im ersten Fall ist allerdings noch viel unbefriedigender als der zweite Fall. Das wäre also ein Argument gegen PUA-Zeichen in Original.

Abkürzungen

Abkürzungszeichen wie ꝙ oder ũ werden regularisiert, denn sie sind tatsächlich als Abkürzungen gedacht, wo der Setzer nicht genug Platz hatte. Zeichen wie ę sind dagegen wohl keine Abkürzungszeichen in diesem Sinne, sondern eine bestimmte Weise, den ehemaligen Diphthong ae zu verschriftlichen (zu ę siehe auch hier).

Was ist mit Abkürzungen wie "&c."? Wird das zu "et cetera" oder nur zu "etc."? Im Benedetti steht zurzeit <reg norm="&amp;c." type="unresolved">&amp;c.</reg>. Die Idee davon ist unter anderem, dass jeder Punkt im Text, der nicht Satzendepunkt ist, sich rechtfertigen muss. Eine Art, das zu tun, ist, in einem tag wie <reg> zu verschwinden. Dieses Kriterium wird aber nur für sehr aufwändig nachbearbeitete Texte realistisch sein.

Moderne Abkürzungen wie "z.B." werden möglicherweise gar nicht regularisiert oder normalisiert. In der Normalisierung wäre es wohl zu schwierig und ginge sicher nur, wenn die Schreibweise so standardisiert ist, wie es in unseren Texten wohl nie sein wird (ist ein Abstand zwischen z. und B. oder nicht?). Es gibt im Deutschen viele Abkürzungen, die man auch gar nicht ausschreiben möchte, wie ursprünglich lateinische Wörter "p.", "etc.", "ibid.", "i.e.", oder im Englischen "AD", "BC". (Was ist mit Maßangaben wie mm, l, etc.? Will man unterscheiden zwischen Abkürzungen mit und ohne Punkt?) Trotzdem sollten sie wohl wenigstens im Wörterbuch gefunden werden. Aber in solchen Fällen kann man vermuten, dass auch die Abkürzung im Wörterbuch zu finden ist.

Die Lösung wie im Benedetti hätte jedenfalls den Vorteil, dass die Abkürzungen in der Textanzeige optisch erkennbar sind, weil alle <reg> optisch erkennbar sind. Und es wäre klar, was man im Wörterbuch suchen muss (unabhängig davon, ob es dann auch einen Wörterbucheintrag gibt).

Automatische Fehlerkorrektur

In dieser Tabelle geht es um korrekt transkribierte Formen, d.h. die Transkription gibt wieder, was im Original steht. Dies wird natürlich nicht immer der Fall sein. Es steht daher an, die Textqualität automatisiert zu verbessern.

Ein Problem der automatischen Fehlerkorrektur ist, dass es oft nicht selbstverständlich ist, ob der Fehler schon im Original steht oder erst der Transkription hinzugekommen ist. Zwar kann man vermuten, dass zum Beispiel "ipfius" ein Transkriptionsfehler ist, aber es ist nicht sicher. Deshalb wird es bei der automatischen Fehlerkorrektur ein type="unverified" geben. Wenn es feststeht, dass der Fehler erst in der Transkription entstanden ist, kann das <reg> durch die stillschweigend korrigierte Form ersetzt werden.

• Vorlage: ipſius
• Transkription: ipfius
• automatisierte Fehlerkorrektur: <reg norm="ipſius" type="unverified">ipfius</reg>
• stillschweigende Korrektur nach manueller Prüfung: ipſius

Bestimmte Fehler, wie zum Beispiel überflüssige oder fehlende spaces, werden wir voraussichtlich von vornherein stillschweigend korrigieren.

Lesehilfe-Diakritika können wir möglicherweise zur Wortgrenzenerkennung verwenden, zum Beispiel beim fehlenden Leerzeichen in "ferècæteri" (Benedetti p.7).

Standard-Regularisierungen in allen Sprachen

• Fehler-Korrekturen
• Abkürzungszeichen auflösen

Latein

• reſiduũ wird zu reſiduum
• ę wird nicht regularisiert und erst in der Normalisierung zu ae. Ich werde die entsprechenden <reg> noch aus dem Benedetti entfernen.
• alle Variationen von -que werden regularisiert
• alle medievalist characters (Standard-Unicode und PUA-Zeichen) werden regularisiert

Deutsch

Die Vorgehensweise in deutschen Texten ist noch unklar. Bei einem modernen Text werden wohl nur echte Fehler regularisiert.

• Auflösung von "Vor- und Rücksicht" mit <reg>? Der Benutzer muss sich dann entscheiden, ob er den Text mit Tippfehlern und ohne Auflösungen (Original) oder ohne Tippfehler und mit Auflösungen (Regularized) sehen möchte.

Fraktur

Die MUFI hat ein PUA-Zeichen für das {uo} in z{uo}. Wenn man es verwendet, muss jedes z{uo} in ein <reg>, damit es im regularisierten Text kein PUA-Zeichen mehr gibt. Wenn man stattdessen ein "combining letter o" verwendet, reicht es aus, das Zeichen zu normalisieren. Ich neige zum zweiten, insbesondere weil es keine buchspezifische Schreibweise ist.

(Sollten wir in Zukunft die Information uͤ versus ü markieren lassen? In Cardano kommt beides vor, offenbar ohne Bedeutungsunterschied. Und das alternative r? Eher vergleichbar mit ſ oder mit letter variation ϐ? Immerhin ist das alternative r in Unicode: ꝛ (A75B). Wenn sich der Benutzer den Text mit einem Fraktur-Font anzeigen lässt, wäre es sicher netter, wenn das alternative r richtig dargestellt wird. Aber gibt es überhaupt Fraktur-Fonts, die ausreichend kompatibel mit Unicode sind? Zwangsligaturen wie ch, ck, tz lassen wir auch nicht markieren und überlassen es einem eventuellen Fraktur-Font, sie korrekt darzustellen.)

Chinesisch

In Unicode enthaltene Zeichenvarianten auf ihr Standardzeichen zurückzuführen ist Aufgabe der Normalisierung.

Die Regularisierung ist im Chinesischen insbesondere für die Erschließung der Zeichenvarianten zuständig, die nicht in Unicode enthalten sind. Ein Beispiel: Angenommen, im Text steht eine Variante von 国, die durch die IDS-Sequenz ⿴口或 beschrieben werden kann. (Die IDS-Sequenz ⿴口或 ist natürlich nicht echt, denn sie beschreibt einfach das Langzeichen 國 des Kurzzeichens 国.) Wie bei den griechischen Ligaturen kommt bei uns ein { } um die IDS-Sequenz. Technisch gesehen ist das zwar nicht nötig, aber sonst müsste das System ausrechnen, wo die Sequenz zuende ist.

Noch vor der Regularisierung wird im XML-Workflow das 中<国V> im Rohtext in einem ersten Schritt in ein XML-kompatibles 中{国V} geändert. Die Regularisierung sieht dann so aus:

• 中<reg faithful="{⿴口或}">国</reg>, falls das Skript nicht auf eine von den Chinesen erstellte IDS-Sequenz wie ⿴口或 zurückgreifen kann
• 中<reg faithful="{国}" type="unresolved">国</reg>, falls das Skript nicht auf eine IDS-Sequenz zurückgreifen kann; dann funktioniert immerhin die Suche. Diesen Schritt kann man auch auslassen und das <reg> gleich per Hand erstellen.
• <reg faithful="中{⿴口或}">中国</reg> per Hand (Wortgrenzen beachten, spätestens jetzt eine IDS-Sequenz einfügen)

Die Entscheidung, ob eine nicht in Unicode vorhandene Zeichenvariante überhaupt markiert werden muss oder ob man einfach das Standardzeichen tippen kann, haben die Chinesen bereits aufgrund der Regeln in den chinesischen DESpecs getroffen. Da ein Zeichen nur beim ersten Mal markiert werden muss, muss man den Text durchgehen auf alle Vorkommnisse des Zeichens, und eventuell ein <reg> einfügen. Dafür wäre ein interaktives Skript wünschenswert. Beachte, dass im gleichen Text das Standardzeichen und mehr als eine Variante vorkommen können.

Im faithful-Attribut könnten wir auch IVS-Sequenzen unterbringen. Wir haben noch keine Möglichkeit, bei IVS-Sequenzen das korrekte Zeichen anzuzeigen. Wenn man damit gar nichts anfangen kann, wird das zusätzliche Zeichen wohl einfach nicht angezeigt, d.h. man sieht das Ausgangszeichen und eventuell einen space, und die Suche in faithful bricht vermutlich. Wie bei IDS-Sequenzen kommt bei uns ein { } um die IVS-Sequenz, auch wenn technisch gesehen nicht nötig wäre.

Wir haben bisher noch keinen Font für Extension C und Extension D. Diese Extensions sind viel kleiner als Extension B, und unsere Texte enthalten bisher keine Zeichen aus Extension C oder D. Wir werden mit dem Problem umgehen, wenn es auftritt.

Griechisch

Bei der Aufarbeitung von griechischem Text stehen wir noch am Anfang. Übliche Fehler in der Vorlage sind:

• Akzent über dem falschen Buchstaben bei einem Diphthong
• lateinische Zeichen als Ersatz für griechische Zeichen, zum Beispiel small-caps-H für η.
• echte Satzfehler

Mögliche Transkriptionsfehler (werden stillschweigend korrigiert):

• Tonos statt Akut

Ähnlich wie im Chinesischen ist die Regularisierung im Griechischen für Ligaturen zuständig, die wir nicht mit Unicode-Mitteln ausdrücken können. Dabei wird einfach das Wort aus dem Rohtext in das faithful-Attribut geschoben.

Es wäre schön, bei unseren Texten jeweils eine Liste aller Zeichen zu haben, die dem Setzer zur Verfügung standen, und welches Zeichen der Setzer an einer bestimmten Stelle verwendet hat. Es ist aber wohl nicht realistisch, dies auch im XML-Text zu kodieren. Schon im Lateinischen gibt es Standard-Ligaturen wie "fi", die wir nicht markieren lassen. Und gerade bei frühen griechischen Drucken hängt die Ligaturenliste sehr stark von der verwendeten Schriftart ab. Die Bedeutung der im Rohtext markierten Ligaturen ist daher wohl eher, dass wir Transkriptionsfehler besser bereinigen können; siehe auch das Szenario im Abschnitt über das faithful-Attribut.

In den DESpecs steht, dass letter variations wie die alternative Form ϐ von β gar nicht erst getippt werden sollen. Die DESpecs verlangen auch explizit, dass verschiedene Ligaturen von καὶ, die auch im gleichen Text auftreten, nicht optisch mit {καὶ1}, {καὶ2}, etc. als unterschiedliche καὶ-Ligaturen, sondern semantisch als "die" Ligatur {καὶ} markiert werden. Das widerspricht allerdings der Idee, dass die Markierung der Ligaturen helfen soll, Transkriptionsfehler leichter zu korrigieren. Die Regeln für griechische Ligaturen in den DESpecs haben wir gemacht, als wir noch nicht wussten, was wir mit der Information eigentlich anfangen sollen.

In Abhängigkeit von der in der Vorlage verwendeten Schriftart kann im Extremfall fast jedes griechische Wort ein <reg> haben. Vielleicht kann man deshalb bei dieser Gelegenheit offensichtlich triviale Ligaturen stillschweigend entfernen. Ein Kandidat für eine triviale Ligatur wären zwei ineinander verschränkte λ. Die gleiche Ligatur kann aber in einem Buch einfach und im nächsten Buch schwierig sein. Da wir aber bisher nur theoretische Aussagen von Gräzisten haben, wo die Grenze zwischen trivialen und nicht-trivialen Ligaturen verläuft, halte ich es für sinnvoll, vorläufig alle Ligaturen zu behalten, bis das System tatsächlich verwendet wird. Informationen weglassen können wir immer noch.