Changes between Version 13 and Version 14 of normalization/5

Timestamp:

Dec 13, 2010, 11:10:56 AM (13 years ago)

Author:

Wolfgang Schmidle

Comment:

--

normalization/5

@@ -72 +72 @@
   * 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 `&x1F700;` verwenden)
  1. Unicode-Zeichen: ''PUA'' der MUFI (zum Beispiel "")
- 1. Unicode-Zeichen: ''IDS''- und ''IVS''-Sequenzen
+ 1. Unicode-Zeichen: ''IDS''- und ''IVS-Sequenzen''
  1. 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.
+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.
@@ -101 +101 @@
   * 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 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:
  <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 ([http://www.signographie.de/cms/front_content.php?idart=223 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 dieses Zeichen. Das Argument hängt aber nicht an diesem speziellen Zeichen, sondern es illustriert, was bei PUA-Zeichen passieren kann.) 
+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 ([http://www.signographie.de/cms/front_content.php?idart=223 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. Das Argument hängt aber nicht an diesem speziellen Zeichen, sondern es illustriert, was bei PUA-Zeichen passieren kann.) 
 
 Stattdessen müsste man schreiben:
@@ -186 +186 @@
 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.
+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 ===