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 ("ſphęræ"),
2. die regularisierte Fassung ("ſphaeræ"), die durch <reg> festgelegt wird, und
3. die normalisierte Fassung ("sphaerae"), die durch eine zusätzliche sprachspezifische Normalisierung entsteht.

Bei Fraktur-Texten sollte man zusätzlich zwischen Fraktur-Ansicht und Antiqua-Ansicht umschalten können.

Zeichen, die in Unicode nicht verfügbar sind, werden im xml durch links auf Bilder oder SVG-Fragmente ersetzt, die an einer zentralen Stelle abgelegt sind. Zeichen-Bilder müssen genau an der richtigen Stelle angezeigt werden.

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="ſphaeræ">ſphęræ</reg>

statt

<reg orig="ſphęræ">ſphaeræ</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="ſphaeræ" type="simple">ſphę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ũ ſphęræ idem́ ſcīa ęqua-
   les [sulfur.gif]. 中国歴中[⿴口玉.svg]。Ἀλλὰ ξύλινον.
   

2. regularisiert:

   vnum peritißimo aër verò reſiduum ſphaeræ 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ũ ſphę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:

• Die normalisierte Textversion soll im Lateinischen (und Griechischen) der Schulschreibweise entsprechen.
• 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? Wie wäre die Schulschreibweise? (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 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?

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. Wahrscheinlich sind die Textnormalisierungen eine Teilmenge der Normalisierungen für Donatus / Pollux, sodass man den Normalisierungsservice in zwei Teile teilen kann und für die Textnormaliserung nur den ersten Teil aufruft.
• 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.

Symbole:

• Mit <image> eingefügte Zeichen-Bilder müssen genau an der richtigen Stelle angezeigt werden, damit der Text lesbar bleibt. Im Gegensatz zu <image> von Abbildungen gibt es dabei keinerlei Spielraum.
• 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"/>
  

• Eine absolute URL macht den xml-Text unabhängiger von unserem Anzeigesystem. Trotzdem wäre es vielleicht wünschenswert, das file-Attribut nachmachen zu können, das lediglich den Dateinamen der Abbildung enthält und erst mit dem Pfad des Textes auf Foxridge und dem Unterverzeichnis figures/ eine vollständige URI ergibt. Wie kann man das erreichen, wenn die Symbole zentral gespeichert werden? Zum Beispiel könnte "symbols/" im file-Attribut als Verweis auf diese zentrale Stelle statt als lokales Verzeichnis interpretiert werden. Oder ein neues Attribut? (Eine neuer tag wäre wohl übertrieben.)
• 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. Eine weitere Normalisierungsmöglichkeit, die der Idee der Schulschreibweise im Lateinischen nahekommt, wäre die Reduktion auf eine offizielle VR-chinesische Liste von 8000 Zeichen (Liste als ​PDF, Erklärung auf chinesisch ​hier). Natürlich gibt es auch eine taiwanesische Version, die insbesondere keine simplified characters enthält. Es ist allerdings nicht ganz klar, wie die Reduktion automatisiert erfolgen soll. Daher ist auch diese Normalisierung vorläufig unrealistisch.
• 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 ?

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.

Was wird regularisiert?

Die Anzeige-Modi haben eine klare Beschreibung: Die regularisierte Version ist das Original mit den Änderungen durch <reg>, und die normalisierte Version ist die regularisierte Version, wo zusätzlich noch ein sprachspezifischer Normalisierungsservice angewendet wurde.

Und was wird regularisiert? Rein pragmatisch regularisieren wir ę, weil viele Leute sonst nicht wissen, was gemeint ist, aber nicht æ, denn bei æ gibt es dieses Problem nicht. Und wenn wir æ regularisieren würden, müssten wir vielleicht auch ſ (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.)

Zurzeit wird also regularisiert, was wir pragmatisch für regularisierenswert halten. Ist es sinnvoll und möglich, hierfür klarere Regeln anzugeben? Offenbar kann man jedenfalls nicht einfach sagen, dass <reg> alle textspezifischen Korrekturen enthält. Denn zum Beispiel ae für ę ist nicht textspezifisch und könnte daher auch erst in der normalisierten Version zu ae aufgelöst werden.

Kann man sagen, dass wir zumindest im Lateinischen eine damals übliche Textgestalt erreichen wollen und dabei Zeichen regularisieren, die damals als reine Abkürzungszeichen empfunden wurden? Zum Beispiel ist ſ Teil der damals üblichen Textgestalt im Lateinischen. Es gibt klare Gebrauchsregeln für ſ, und es ist nicht einfach austauschbar mit s. Das ę ist dagegen ein Abkürzungszeichen, das der Setzer verwendet, wenn ae zuviel Platz wegnimmt. Das æ verhält sich offenbar eher wie ſ als wie ę, zum Beispiel in Formen wie quæ. Muss man dann quę zu quæ statt zu quae regularisieren, genauso wie ſcīa zu ſcientia und nicht zu scientia regularisiert wird? Und ſphęræ zu ſphæræ (diese Form kommt in Benedetti recht oft vor) statt zu ſphaeræ?