Anzeige-Modi für Text

Zusammenfassung

im Textmodus im Anzeigesystem soll der User zwischen drei Anzeige-Modi für den Text wählen können:

1. die Originalgestalt des Textes ("sphęræ"),
2. die regularisierte Fassung ("sphaeræ"), die durch <reg> festgelegt wird, und
3. die normalisierte Fassung ("sphaerae"), die durch eine zusätzliche sprachspezifische Normalisierung entsteht.

Nicht verfügbare Zeichen können durch Bilder oder SVG-Fragmente ersetzt werden, die an einer zentralen Stelle abgelegt sind.

Die sprachspezifische Normalisierung ist im Lateinischen und Griechischen nicht identisch mit der Normalisierung für Donatus/Pollux? (Beispiel ἀλλὰ versus ἀλλά), sondern wohl eine Teilmenge davon. Die Normalisierung für Sprachen wie Chinesisch muss noch genauer beschrieben werden.

Probleme der sprachspezifischen Suche müssen wir noch getrennt besprechen.

Die drei Anzeige-Modi

im Team Meeting 2010-05-12 haben wir besprochen, dass wir die Struktur von <reg> tatsächlich ändern, also zum Beispiel <reg norm="sphaeræ">sphęræ</reg> statt <reg orig="sphęræ">sphaeræ</reg>. Als default wird bei uns weiterhin die regularisierte Schreibweise sphaeræ angezeigt, nur steht sie jetzt im norm-Attribut.

Wenn man unsere xml-Texte zum Beispiel in einem Browser anschaut, sieht man jetzt den Originaltext und nicht wie vorher die regularisierte Textversion. Da der Originaltext jetzt also an deutlich prominenterer Stelle steht und nicht mehr wie vorher im orig-Attribut verschwindet, halte ich es für dringend, dass unser Anzeigesystem -- als Referenzsystem für unsere xml-Texte -- den Originaltext korrekt anzeigen kann.

Wir brauchen daher bei der Text-Anzeige drei Anzeige-Modi:

1. original
2. regularisiert
3. normalisiert

Original meint die größtmögliche Annäherung an die Buch-Vorlage mit Unicode-Mitteln. Default-Anzeige ist, wie gesagt, die regularisierte Version, also original plus <reg>. Die normalisierte Version entsteht aus der regularisierten Version, wenn man zusätzlich einen sprachspezifischen Normalisierungs-Service darauf anwendet. Für Latein sind das mindestens u/v, i/j, ſ/s, ß/ss, æ/ae, œ/oe. Zur Frage, ob ë/e, ò/o etc. dazugehören, siehe weiter unten.

Beispiel

Ein vielleicht etwas gewöhnungsbedürftiges Beispiel, erst als XML und dann in den drei Anzeige-Modi:

XML (mit einigen zusätzlichen Zeilenumbrüchen):

<s xml:lang="la">vnum peritißimo aër verò 
<reg norm="reſiduum" type="context">reſiduũ</reg> 
<reg norm="sphaeræ" type="simple">sphęræ</reg> 
<reg norm="idemque" type="simple">idem́</reg> 
<reg norm="ſcientia" type="wordlist">ſcīa</reg> 
<reg norm="aequa- les" type="simple">ęqua-<lb/>les</reg> 
<image xlink:href="symbols/alchemy/sulfur.gif"/>. </s>

<s xml:lang="zh">中国
<reg norm="歷" type="simple">歴</reg>
<reg norm ="中国" type="simple">中<image xlink:href="symbols/chinese/⿴口玉.svg"/></reg>。</s>

<s xml:lang="el">Ἀλλὰ ξύλινον. </s>

1. Original:

   vnum peritißimo aër verò reſiduũ sphęræ idem́ ſcīa ęqua-
   les [sulfur.gif]. 中国歴中[⿴口玉.svg]。Ἀλλὰ ξύλινον.
   

2. regularisiert:

   vnum peritißimo aër verò reſiduum sphaeræ idemque ſcientia aequa-
   les [sulfur.gif]. 中国歷中国。Ἀλλὰ ξύλινον.
   

3. normalisiert:

   unum peritissimo aer vero residuum sphaerae idemque scientia aequa-
   les [sulfur.gif]. 中国歷中国。Ἀλλὰ ξύλινον.
   

Anmerkungen

Ansicht im Browser:

• Man sieht in Firefox im wesentlichen die Original-Version. Dabei fehlen Zeichen wie "sulfur", die durch ein <image> dargestellt werden. Auch das <lb/> wird ignoriert. Ob idem́ korrekt angezeigt wird, hängt vom verwendeten Font ab. Man sieht also (siehe ​Beispiel-Text.xml):

  vnum peritißimo aër verò reſiduũ sphęræ idem́ ſcīa ęqua-les . 中国歴中。Ἀλλὰ ξύλινον.
  

Sprachen-Kennzeichnung:

• la soll irgendwann durch lat und zh durch zho oder sogar zho-Hant (für chinesisch mit traditional characters) ersetzt werden. Ebenso Altgriechisch grc statt el.

Latein:

• Wenn man für die normalisierte Version den sprachspezifischen Normalisierungs-Service für Donatus/Pollux? verwendet, wenn man also in der normalisierten Version genau die Vereinheitlichungen macht, die man auch für Donatus/Pollux? macht, muss man im Lateinischen aër und verò zu aer und vero vereinheitlichen. Will man das? (Noch problematischer ist es im Griechischen, siehe unten.)
• Ich gehe davon aus, dass ſcīa zu ſcientia regularisiert wird und nicht gleich zu scientia, und entsprechend rñdẽs zu reſpondens und nicht zu respondens.
• Wir regularisieren ę, aber nicht æ, denn ę muss regularisiert werden, weil viele Leute sonst nicht wissen, was gemeint ist. Bei æ gibt es dieses Problem nicht. Und wenn wir es zu ae regularisieren würden, müssten wir konsequenterweise auch jedes ſ (long s) zu s regularisieren. Dann hätte aber jedes zweite Wort ein <reg> tag. (Mit einem ähnlichen Argument verwenden wir bei fehlenden Trennstrichen nicht <reg>, sondern fügen ein "soft hyphen" ein.)
• Wir versuchen die Private Use Area in Unicode nach Möglichkeit zu vermeiden, aber zum Beispiel bei der "que"-Ligatur geht das nicht gut. Daher wird idem́ nur mit dem richtigen Font korrekt angezeigt. Brauchen wir noch einen vierten Anzeigemodus, wo ́ durch ein Bild ersetzt ist, oder kann man erwarten, dass jemand, der das Original korrekt angezeigt haben will, sich die Mühe macht, einen Font herunterzuladen und zu installieren?

Symbole:

• Die Symbole sind eigentlich nicht buchspezifisch. Deshalb sollten sie wohl auch nicht beim jeweiligen Buch-Verzeichnis gespeichert werden, sondern an einer zentralen Stelle. Also in etwa

  <image xlink:href="http://echo.mpiwg-berlin.mpg.de/symbols/alchemy/sulfur.gif"/>
  <image xlink:href="http://echo.mpiwg-berlin.mpg.de/symbols/chinese/⿴口玉.svg"/>
  

• Ich nehme an, wenn ein User nach "Saturn" sucht, würde er auch gerne das Symbol ♄ im Text finden. Möglich wäre das durch <reg norm="Saturn" type="symbol">♄</reg>. Können/wollen wir das leisten? Zum Beispiel soll das Symbol ja in der regularisierten Darstellung nicht durch den Text "Saturn" ersetzt werden. Man könnte eventuell ein neues Attribut wie searchValue="Saturn" einführen. Oder wäre das ein gutes Beispiel für eine overlay-Schicht? Vorläufig habe ich jedenfalls bei dem Alchemie-Symbol "Sulfur" kein <reg> um das <image> gemacht.
• Es gibt übrigens inzwischen ein Proposal, Alchemie-Zeichen in Unicode aufzunehmen: ​n3584.pdf

Chinesisch:

• Beachte, dass der Unterschied zwischen der Variante 歴 und dem Standardzeichen 歷 nicht leicht zu erkennen ist.
• Der reg-Typ "simple" bei dem Beispiel 歴 drückt aus, dass es sich um eine einfache kontextlose Ersetzung handelt. Eventuell könnte man auch den Typ "variant" nehmen, um auszusagen, dass eine Zeichenvariante durch das Standardzeichen ersetzt wurde. Aber nachdem ich das im Lateinischen durchexerziert und wieder verworfen habe, sehe ich keinen wirklich guten Grund, im Chinesischen doch wieder einen "erklärenden" reg-Typ einzuführen.
• Sobald die Unicode-Datenbank eine stabile Möglichkeit bietet, von einer Variante zum Standardzeichen zu gelangen, kann man statt <reg norm="歷" type="simple">歴</reg> auch einfach 歴 schreiben. Dann wird im Original und in der regularisierten Version die Variante 歴 dargestellt, und in der normalisierten Version findet das Anzeigesystem selbständig das Standardzeichen 歷.
• Zurzeit ist die normalisierte Version in chinesischen Texten aber noch mit der regularisierten Version identisch. Eine (VR-chinesische) Normalisierungsmöglichkeit wäre die Darstellung von traditional characters als simplified characters. Das wäre zwar recht einfach zu implementieren, aber für uns wohl nicht nötig.
• Auf alle Fälle soll die Suche nach 歷 auch 歴 (und andersrum!) finden. Probleme beim Suchen in den verschiedenen Sprachen müssen wir nochmal getrennt besprechen.
• Das Beispiel "⿴口玉" ist kein echtes Beispiel, weil es das Zeichen 国 in Unicode gibt. Es echtes Beispiel wäre "⿱井蛙". Weitere Beispiele ​hier.
• Der Text enthält keine invisible spaces, obwohl wir sie voraussichtlich irgendwann als Worttrenner verwenden werden (zum Beispiel im Wort "中国" für "China": [space]中[kein space]国[space]).
• Das SVG-Format wie in <image xlink:href="symbols/chinese/⿴口玉.svg"/> wurde mit einem ​Tool des ​Wenlin Institute erstellt. Als Nachbearbeitung habe ich in der Datei die Maßangaben von 200x200 auf 20x20 verkleinert und alle Koordinaten entsprechend verkleinert. SVG in html: <embed src="symbols/chinese/⿴口玉.svg" type="image/svg+xml"/>, funktioniert in Firefox 3.6.3 (siehe ​html-test.html und die Bilder ⿴口玉.bmp und ⿴口玉.svg im gleichen Verzeichnis). Wenlin erzeugt alternativ zu SVG auch BMP. Wäre BMP (oder GIF) besser als SVG ?

Griechisch:

• Spätestens im Griechischen muss man auf alle Fälle unterscheiden zwischen dem normalisierten Text und den Normalisierungen für Donatus/Pollux?: Zum Beispiel ein Gravis auf dem letzten Buchstaben von ἀλλὰ in ἀλλὰ ξύλινον sollte auch in der normalisierten Textversion ἀλλὰ bleiben, an das Wörterbuch sollte jedoch ἀλλά mit Akut geschickt werden.
• Mit den weiteren Problemen im Griechischen (verschiedene {και}-Ligaturen, Ligaturen versus Abbreviaturen, Akzente auf dem falschen Buchstaben bei Diphthongen, etc.) habe ich mich noch nicht näher beschäftigt. Bei falsch gesetzten Akzenten in Diphthongen ist die Frage, ob der Akzent schon im Text regularisiert wird, oder ob das als Merkwürdigkeit des Buches akzeptiert wird und erst in der normalisierten Version korrigiert wird.

Fraktur:

• Im obigen Beispiel fehlt Fraktur, weil Fraktur nicht als eigenständiges Alphabet in Unicode enthalten ist.
• Geben wir das alternative r wieder? Wir lassen es bisher als normales r tippen.
• Wir haben noch keinen Font, der die Zwangsligaturen (ch, ck, tz) und die weiteren üblichen Ligaturen (ff, fi, fl, ft, ll, ſi, ſſ, ſt, tt) in Unicode-kompatibler Weise darstellen kann. Trotzdem ist es zum jetzigen Zeitpunkt wohl nicht sinnvoll, diese Ligaturen explizit im Text zu markieren (Unicode-Ligaturen U+FB00 bis U+FB06) oder gar Ligatur-Bilder einzufügen. Fraktur-Fonts können bisher zum Beispiel mit ſt (U+FB05) nichts anfangen, und mit Ligatur-Bildern würde der halbe Text aus Bildern bestehen. Da die Regeln für Ligaturen ohnehin geradlinig sind, wäre die Markierung von Ligaturen im Text auch redundant, außer der Font im Original verwendet andere als die Standard-Ligaturen. Wir werden wohl warten müssen, bis ein Font die Ligaturen automatisch korrekt darstellt.
• Eventuell sollte der User die Möglichkeit haben, bei der Textansicht zwischen Fraktur und nicht-Fraktur umschalten zu können. Wenn er Fraktur wählt, sollte nur der Text selbst in Fraktur erscheinen, aber nicht die zusätzlichen Texte auf der Seite wie den Buchtitel, "elapsed time", etc.