| 39 | | 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, beispielsweise [[BR]] `<reg norm="exem" type="context">exẽ</reg> <lb/>plo` durch [[BR]] `<reg norm="exem- plo" type="context">exẽ-<lb/>plo</reg>` [[BR]] zu ersetzen (eigentlich mit soft hyphen). |
| | 39 | 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, beispielsweise [[BR]] `<reg norm="exem" type="context">exẽ</reg> <lb/>plo` durch [[BR]] `<reg norm="exem- plo" type="context">exẽ-<lb/>plo</reg>` [[BR]] zu ersetzen (mit soft hyphen). |
| 77 | | Mögliche Kriterien, um zu entscheiden, ob die anderen Gruppen in Original oder in faithful kommen, sind: |
| 78 | | A. vom Benutzer zu schaffen, versus Programmieraufwand |
| 79 | | A. Unicode: Standard versus PUA |
| 80 | | A. idiosynkratisch versus Standard |
| 81 | | |
| 82 | | Mit diesen Kriterien ergibt sich: |
| | 76 | 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. |
| 93 | | Kriterium A und B widersprechen sich nicht vollständig, und es gibt auch Argumente (siehe [#Dasfaithful-Attribut hier] und [#Latein hier]), die dafür sprechen, PUA-Zeichen nur im faithful-Attribut zu erlauben. Dann wäre die Trennung 1 2 versus 3 4 5. |
| 94 | | |
| 95 | | Gegen Kriterium C: Zum Beispiel IDS-Sequenzen können wir zurzeit noch nicht richtig (d.h. als ein einzelnes Schriftzeichen) darstellen, obwohl sie aus offizellen Unicode-Zeichen bestehen. |
| 96 | | |
| 97 | | |
| 98 | | === Die Private Use Area === |
| 99 | | |
| 100 | | Im folgenden wird unser Umgang mit der Private Use Area (PUA) von Unicode besprochen. Wir würden gerne alle PUA-Zeichen zum Beispiel der MUFI nehmen, 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 Schwierigkeit des Themas. |
| 101 | | |
| 102 | | * Wir erfinden selbst keine PUA-Zeichen. |
| 103 | | * PUA-Zeichen müssen regularisiert werden. |
| 104 | | * These: Standardisierte PUA-Zeichen wie die MUFI-Zeichen dürfen in "Original" stehen, anstatt in @faithful geschoben zu werden. |
| 105 | | |
| 106 | | Mehrere mögliche Fälle: |
| | 85 | Bei der Verwendung von PUA-Zeichen gibt es mindestens folgende Fälle: |
| 111 | | PUA-Zeichen in Original zu erlauben, scheint mir sinnvoll zu sein (siehe oben). Es gäbe aber auch Gründe, PUA-Zeichen ganz in das faithful-Attribut zu verbannen. Zum Beispiel greift bei offiziellen Zeichen 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: |
| 112 | | * mit PUA: <reg norm="numquam">nū̄</reg> |
| 113 | | * ohne PUA: <reg faithful="nū̄" norm="numquam">nūq̄ꝫ</reg> |
| | 90 | Die ausstehende Frage ist 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. |
| 117 | | Regularisiert wird das Wort in jedem Fall, denn ꝫ ist mit oder ohne Ligatur ein Abkürzungszeichen. Man kann also kein <reg> einsparen, allerdings werden sie etwas länger. Immer noch kein Vergleich zu griechischem Text. |
| | 95 | Für PUA in faithful spricht: |
| | 96 | * 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: |
| | 97 | * mit PUA: <reg norm="numquam">nū̄</reg> |
| | 98 | * ohne PUA: <reg faithful="nū̄" norm="numquam">nūq̄ꝫ</reg> |
| | 99 | * 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. |
| | 100 | * 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. |
| 119 | | |
| 120 | | === Abkürzungen === |
| 121 | | |
| 122 | | 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. |
| 123 | | |
| 124 | | Was ist mit Abkürzungen wie "&c."? Wird das zu "et cetera" oder nur zu "etc."? Im Benedetti steht zurzeit `<reg norm="&c." type="unresolved">&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. |
| 125 | | |
| 126 | | 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. |
| 127 | | |
| 128 | | 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. |
| 129 | | |
| 130 | | |
| 131 | | === Automatische Fehlerkorrektur === |
| 132 | | |
| 133 | | In [wiki:normalization/overview 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. |
| 134 | | |
| 135 | | 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. |
| 136 | | |
| 137 | | Bestimmte Fehler, wie zum Beispiel überflüssige oder fehlende spaces, werden wir voraussichtlich von vornherein stillschweigend korrigieren. |
| 138 | | |
| 139 | | |
| 140 | | === Standard-Regularisierungen in allen Sprachen === |
| 141 | | |
| 142 | | * Fehler-Korrekturen |
| 143 | | |
| 144 | | === Latein === |
| 145 | | |
| 146 | | * reſiduũ wird zu reſiduum |
| 147 | | * ę wird nicht regularisiert und erst in der Normalisierung zu ae. Ich werde die entsprechenden <reg> noch aus dem Benedetti entfernen. |
| 148 | | * alle Variationen von -que werden regularisiert |
| 149 | | * alle medievalist characters (Standardzeichen und PUA-Zeichen) werden regularisiert |
| 150 | | |
| 151 | | 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: |
| | 102 | 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: |
| | 126 | 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. |
| | 127 | |
| | 128 | Was ist mit Abkürzungen wie "&c."? Wird das zu "et cetera" oder nur zu "etc."? Im Benedetti steht zurzeit `<reg norm="&c." type="unresolved">&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. |
| | 129 | |
| | 130 | 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. |
| | 131 | |
| | 132 | 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. |
| | 133 | |
| | 134 | === Automatische Fehlerkorrektur === |
| | 135 | |
| | 136 | In [wiki:normalization/overview 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. |
| | 137 | |
| | 138 | 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. |
| | 139 | |
| | 140 | Bestimmte Fehler, wie zum Beispiel überflüssige oder fehlende spaces, werden wir voraussichtlich von vornherein stillschweigend korrigieren. |
| | 141 | |
| | 142 | === Standard-Regularisierungen in allen Sprachen === |
| | 143 | |
| | 144 | * Fehler-Korrekturen |
| | 145 | |
| | 146 | === Latein === |
| | 147 | |
| | 148 | * reſiduũ wird zu reſiduum |
| | 149 | * ę wird nicht regularisiert und erst in der Normalisierung zu ae. Ich werde die entsprechenden <reg> noch aus dem Benedetti entfernen. |
| | 150 | * alle Variationen von -que werden regularisiert |
| | 151 | * alle medievalist characters (Standard-Unicode und PUA-Zeichen) werden regularisiert |
