Changes between Version 5 and Version 6 of normalization/5

Timestamp:

Dec 8, 2010, 2:09:47 PM (13 years ago)

Author:

Wolfgang Schmidle

Comment:

--

normalization/5

@@ -12 +12 @@
 
 Ziele:
- * Wissen über den einzelnen Text muss in <reg>
- * halte die Anzahl der benötigten <reg> möglichst klein
+ * Wissen über den einzelnen Text und einzelne Textstellen muss in <reg>
+ * 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 endlich 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.
@@ -146 +147 @@
 Aber wir haben keinen Font, der es dann auch in seiner kursiven Form anzeigen 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, svg, etc. 
+{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. Das Problem ist zwar im reg-Skript lösbar, aber vielleicht wäre das ein weiteres Argument, PUA-Zeichen doch nur im faithful-Attribut zuzulassen. Dann kann man nämlich automatisiert ein funktionierendes <reg> erstellen:
@@ -175 +176 @@
 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.)
+
 === Chinesisch === 
 
@@ -186 +189 @@
 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 国.)
+(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.
 
 === Griechisch ===