Context Navigation

Changes between Version 10 and Version 11 of normalization/5

Timestamp:: Dec 12, 2010, 10:24:13 AM (13 years ago)
Author:: Wolfgang Schmidle
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

normalization/5

-                      v10
+                      v11
 . idiosynkratische Notationen wie {πρ}, {q3-it-a}
 Gruppe 1 gehört offensichtlich zu Original. Auch Gruppe 2 soll zu 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.
+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.
 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.
 …
   * ohne PUA: <reg faithful="nū̄" norm="numquam">nūq̄ꝫ</reg>
  * 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 zum einen 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.
+ * 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.
 Ein weiteres Argument: Benedetti enthält einige medievalist characters, sie werden aber nicht mehr wie im Alvarus standardmäßig verwendet. Ein schwieriger Fall ist aber das kursive Wort $enatori\'{que} (Benedetti p.296). Das Zeichen {que} könnte wieder mit dem PUA-Zeichen  wiedergegeben werden:
 …
   * 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 erste Fall ist allerdings noch viel unbefriedigender als der zweite Fall. Das wäre also ein Argument gegen PUA-Zeichen in Original.
+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 ===
 Es ist recht geradlinig, Abkürzungszeichen wie ꝙ oder ũ aufzulösen, 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.
+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.
 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.
+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 ===
 …
 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" tpye="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.
 …
 * Fehler-Korrekturen
+* Abkürzungszeichen auflösen
 === Latein ===
 …
 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 die Information uͤ versus ü markieren lassen? In Cardano kommt beides vor, offenbar ohne Bedeutungsunterschied.)
+(Sollten wir in Zukunft die Information uͤ versus ü markieren lassen? In Cardano kommt beides vor, offenbar ohne Bedeutungsunterschied.)
 === 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. Noch vor der Regularisierung wird im XML-Workflow das 中<国V> im Rohtext in einem ersten Schritt in ein XML-kompatibles 中{国V} geändert. Bei der Regularisierung:
+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. Man kann man diesen Schritt auch auslassen und das <reg> gleich per Hand erstellen.
   * <reg faithful="中{⿴口或}">中国</reg> per Hand (Wortgrenzen beachten, eventuell IDS-Sequenz einfügen)
+  * 中<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.
+(Die IDS-Sequenz {⿴口或} ist natürlich nicht echt, denn sie beschreibt einfach das Langzeichen 國 des Kurzzeichens 国. Es echtes Beispiel wäre {⿱井蛙}. Weitere Beispiele [http://www.unicode.org/reports/tr45/tr45-sourcedata-2.txt hier].
+Im faithful-Attribut könnten wir auch IVS-Sequenzen unterbringen. Diese bestehen aus einem Schriftzeichen und einem weiteren Zeichen aus dem Bereich FE00-FE0F (und nochmal ab E0100). 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. Nach der Logik der oberen Beispiele sollte man { } darum machen. Das { } wäre eigentlich hier nicht nötig. Eigentlich ist es auch bei IDS-Sequenzen nicht wirklich nötig, aber dann müsste das System ausrechnen, wo die Sequenz wieder zuende ist.
+Wir haben bisher noch keinen Font für Extension C und Extension D. Diese Extensions sind viel kleiner als Extension B, und uns ist auch noch kein Zeichen aus diesen Extensions begegnet. Wir werden mit dem Problem umgehen, wenn es auftritt.
+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 ===
 Übliche Fehler sind:
+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
+ * Transkriptionsfehler: Tonos statt Akut (wird stillschweigend korrigiert)
+Bei der Aufarbeitung von griechischem Text stehen wir noch am Anfang.
 Ähnlich wie im Chinesischen ist die Regularisierung 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.
+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 [#Dasfaithful-Attribut 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. 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.
+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.