Der Workflow für chinesische Texte

1. textspezifisch

• Ich könnte genauso gut mit der Version arbeiten, wo die Figures bereits aus <p> herausgezogen sind. Aber erst, wenn entschieden ist, ob sm-Text raus kommt oder nicht. (Ansonsten: Einen Arbeitsschritt, in dem alle Skripte sind, mit dem aus der Bearbeitungsversion die Anzeigeversion wird? Problem: Dann wäre der Text vorher noch nicht schemakonform, also wahrscheinlich keine gute Idee.)

2. allgemein

GIS

Der Text enthält zurzeit nur ein einziges <place>-tag auf ​Seite 300. Zurzeit wird <gis-table> nicht ausgewertet und ist auch gar nicht in den Metadaten.

• Der GIS-Rücklink sollte nicht auf den Prototypen zeigen.
• Überflüssige spaces vor und nach dem link, wenn man im GIS-mode ist.

Was wird markiert?

Wie werden Orte wie das Pekinger Münzamt in N403023 markiert? Wird Peking und/oder das Münzamt markiert? (Ähnliches Problem wie bei <ref> im Benedetti.) Seite ​109B / 220:

<s xml:id="N403023" xml:space="preserve">唯北京寶源局黃錢與廣東高州爐青錢</s>

siehe Übersetzung p.165 ganz unten, und p.170 Fußnote 11.

Problem: 北京 寶源局 黃錢 meint Peking-Münzamt-Gelbmünzen. Vergleichbar mit dem Englischen: "Newcastle Brown Ale". Meint also eigentlich weder Peking noch das Münzamt. Das Münzamt ist hier nur ein "adjektivischer Ort". Hat das Auswirkungen darauf, was wir mit place markieren?

• Wahrscheinlich markieren wir nur Städe. Dann ist es einfach: (北京)寶源局黃錢
• Wenn wir auch Orte wie Tempel etc. (aber nicht die Gelbmünzen) markieren, gibt es mehrere Möglichkeiten. Frage ist: markieren wir unabhängig vom Münzamt noch die Stadt?
  • (北京寶源局): es ist nicht die Stadt gemeint, sondern das Münzamt der Stadt, und die Information "Peking" ist im Münzamt sowieso implizit enthalten
  • (北京)(寶源局): allerdings ist der Unterschied zu (北京寶源局) für das Münzamt eher ein rein optisches Problem; im authority file ist es egal, ob der Name 北京寶源局 oder nur 寶源局 ist, entscheidend ist die logische Beziehung der Elemente im authority file zueinander, also die Beziehung von Münzamt und Peking. Erbt das Münzamt das in-Peking-sein vom Eintrag Peking, oder erbt Peking das im-Text-erwähnt-werden vom Münzamt?
  • ((北京)寶源局): wäre auch sinnvoll, allerdings ist eine verschachtelte Markierung unglücklich
  • Wenn man zuerst die Städte markiert, hat man (北京)寶源局. Was einmal markiert wurde, sollte nicht mehr geändert werden. Von (北京)寶源局 kann man also entweder zu ((北京)寶源局) mit verschachtelten tags oder zu (北京)(寶源局).
• Und im gleichen Satz: Guangdong Gaozhou, also Stadt Gaozhou innerhalb der Stadt Maoming in der Provinz Guangdong: (廣東)(高州) oder 廣東(高州) oder (廣東高州) ? Gemeint ist ja die Stadt, die Provinz ist nur zu Erläuterung angegeben. Aber 廣東 ist nicht Teil des Stadtnamens. Probehalber (北京) und (廣東)(高州):

  唯​<place id="N403023-01">北京</place>​寶​源​局​黃​錢​與​<place id="N403023-02">廣東</place>​<place id="N403023-03">高州</place>​爐​青​錢，
  

  Die links auf Seite 220 funktionieren allerdings noch nicht. (ZWS zwischen den beiden <reg>? Wahrscheinlich ja, als Trennhilfe.)

(Nebenbei: 寶源局: Münze, i.e. Münzprägestelle, vs. Münzamt?)

Darstellung der Abbildungen

Problem des Bildbeschreibungstextes auf Seite ​83B / 168. Gehört nicht zum Haupttext, sondern unterbricht den Haupttext. Deshalb eine Textzeile von Seite 84A auf Seite 83A verschoben. (Kann man zurückändern, wenn man etwas wie <explanation> einführt, siehe unten.)

Wimmelbild auf Seite 154: im figures-Ordner das identische Seitenbild dreimal abgelegt. Die Kopie kann man löschen, sobald es <figurepart> gibt.

Problem der Überschriften, die eigentlich captions für Figure-Gruppen sind: zum Beispiel Seite 14A / 29 und 63A / 127. (In beiden Fällen trotzdem ein neues div begonnen.)

Problem der Doppelseitenbilder: Die Bildhälften passen nicht so zusammen, wie sie gedruckt sind (zum Beispiel 016A und 016B, die auf dem gleichen Blatt gedruckt sind), sondern wenn man das gebundene Buch aufschlägt. Ein Beispiel ("--" bedeutet, dass es auf der entsprechenden Seite keine caption bzw. description gibt):

Buchseiten	caption		descriptions
14A	汲水圖 (Figure-Gruppen-caption)
015A 014B	--	筒車	橛障 坡水 坡水 牐	規水 規水 岸
016A 015B	人車	--	蘢骨	--
017A 016B	--	--	--	中柱 牛轉盤外
017B	拔車		--
018A	桔槔		墜石 井

Sollte man auch JPGs der zusammengehörenden Bilder zur Verfügung stellen? Die Bilder wären leichter zu erfassen, aber die Numerierung der Seiten im Anzeigesystem wäre dann (zumindest zurzeit) verwirrender: Unter anderem sieht man der Zahl dann nicht mehr an, ob es eine rechte oder linke Seite ist. Man müsste dann auch die Information "014B" etc. anzeigen (das wäre allerdings sowieso sinnvoll!).

JPG	bisher	nachher
014B	30	30
015A	31	31
015A_014B		32
015B	32	33
016A	33	34
016A_015B		35
016B	34	36
017A	35	37
017A_016B		38
017B	36	39
018A	37	40
018B	38	41

Alternative wäre eine zwei-Seiten-Ansicht. Beachte außerdem die Umkehrung der links-rechts-Metapher.

small text

Bisher war die Idee, es als note herauszuziehen, allerdings wurde es bisher noch nie gemacht, weil die chinesischen Texte noch nicht umgewandelt wurden. Es gibt, trotz der suggestiven Aufteilung in <s>, keine technischen Gründe dagegen. Testweise beide Versionen erzeugen und dann vergleichen? -- Die Entscheidung bei den <sm> hängt offenbar vom Text ab. Kann auch textflows wie bei den Conimbricenses sein, also Original und Kommentar. Song Yingxing: Probehalber herausziehen? Das Skript dafür muss man sowieso schreiben. Jedenfalls: Fußnoten und nicht Marginalien.

58A / 117: vorher:

<head xml:id="N401B82">攻​稻 <emph style="sm">擊禾 \\ 軋禾 風車 \\ 水碓 石碾 \\ 臼 碓 \\ 篩 皆具圖</emph></head>

nachher (verkleinert):

<head xml:id="N401B82">攻​稻　<emph style="sm">擊禾\\軋禾</emph>　<emph style="sm">風車\\水碓</emph>　<emph style="sm">石碾\\臼</emph>　<emph style="sm">碓\\篩</emph>　<emph style="sm">皆具圖</emph></head>

<sm> kann nicht mehrere \\ hintereinander enthalten. Aber es kann ein oder mehrere <lb/> enthalten, und danach ist jeweils wieder ein \\ erlaubt. Beispiel 7B / 16, N400266 ff. (Schematron-Regel?) Und wenn man ein neues \\ auch nach "　" erlaubt, kann man es auch so schreiben:

<head xml:id="N401B82">攻​稻　<emph style="sm">擊禾\\軋禾　風車\\水碓　石碾\\臼　碓\\篩　皆具圖</emph></head>

Dann muss allerdings das Anzeigesystem damit umgehen könnnen. Andererseits muss es sowieso mit \\ bzw. <lb type="halfline"/> umgehen können.

Ersetze \\ durch <lb type="halfline"/>:

<head xml:id="N401B82">攻​稻　<emph style="sm">擊禾<lb type="halfline"/>軋禾</emph>　<emph style="sm">風車<lb type="halfline"/>水碓</emph>　<emph style="sm">石碾<lb type="halfline"/>臼</emph>　<emph style="sm">碓<lb type="halfline"/>篩</emph>　<emph style="sm">皆具圖</emph></head>
<head xml:id="N401B82">攻​稻　<emph style="sm">擊禾<lb type="halfline"/>軋禾　風車<lb type="halfline"/>水碓　石碾<lb type="halfline"/>臼　碓<lb type="halfline"/>篩　皆具圖</emph></head>

Für das, was es tut, ist <lb type="halfline"/> ziemlich lang. Statt dessen etwas wie <hlb/> oder <hb/>? Oder wenigstens <lb type="half"/>? (Koordination mit textflows, i.e. <pb flow="3"/>? In textflows sind andererseits die <lb/> normal.) Und <sm> unterscheidet sich von normalem <emph> dadurch, dass es einen besonderen Anzeigemechanismus braucht. Es ist also nicht direkt mit kursiv etc. vergleichbar. Warum dann nicht bei <sm> bleiben? (Vermutlich würde es kein <s style="sm"> geben.)

<head xml:id="N401B82">攻​稻　<sm>擊禾<hb/>軋禾</sm>　<sm>風車<hb/>水碓</sm>　<sm>石碾<hb/>臼</sm>　<sm>碓<hb/>篩</sm>　<sm>皆具圖</sm></head>
<head xml:id="N401B82">攻​稻　<sm>擊禾<hb/>軋禾　風車<hb/>水碓　石碾<hb/>臼　碓<hb/>篩　皆具圖</sm></head>

Dann wäre die obere Version optisch wohl klarer. In Originalgröße:

<head xml:id="N401B82">攻​稻　<sm>擊禾<hb/>軋禾</sm>　<sm>風車<hb/>水碓</sm>　<sm>石碾<hb/>臼</sm>　<sm>碓<hb/>篩</sm>　<sm>皆具圖</sm></head>

Und in <p>? Einzelne <s> mit style="sm" zu markieren, wie ich es testweise gemacht habe, ist eigentlich Unsinn, weil es auf der falschen Ebene ansetzt (selbst bei einem einzigen <s>, schon wegen der einheitlichen Optik). Vorschlag: <sm>, vergleichbar mit <quote> innerhalb von <p>. Testweise auf Seite 7A / 15 (dort als <quote>, weil das Schema <sm> noch nicht erlaubt).

Oder gleich <fn>? Testweise siehe Seite 10A / 21. Es mag sein, dass es sinnvoll ist, zwischen <sm> (bleibt im Text) und <fn> (wird herausgezogen) wählen zu können. Neuer Type "sm"?

• Beim note-Test (beginnend mit N400515): </s> vom Satz davor hinter die footnote verschoben, weil notes nicht direkt in <p> sein dürfen. Ist das bei notes im Text sinnvoll oder nicht? Beispiele angucken! Doch neuer tag <sm>, der sich etwas anders als die anderen notes verhält? Aber in jedem Fall müsste man <anchor> direkt in <p> erlauben (in echo-chinese-text, weil es bisher nur in chinesischen Texten sinnvoll ist), und dann kann man auch die normale note erlauben.
• Und nach dem Herausziehen der floats das xml:space="preserve" in <note> per Hand entfernt. Das im Skript zu ändern ist wohl sinnlos, denn es ist nicht der normale workflow.

Und will man small text wie im Buch in zwei Zeilen anzeigen? Dafür spricht, dass es dem Seitenbild besser entspricht. Dagegen spricht, dass es dann eventuell nicht mehr gut lesbar ist. Alternativ kann man die normalen Zeichen größer anzeigen anstatt die kleinen kleiner. (Und man kann nicht garantieren, dass ein sm-Zeichen wirklich die gleiche Höhe wie ein normales Zeichen hat; allerdings wird es bei gedruckten Büchern fast immer so sein.)

zero width spaces

Die ZWS sind schwierig zu kontrollieren, weil sie für den normalen Bearbeiter nicht sichtbar sind. Gibt es Alternativen, die auch in Arboreal funktionieren und den optischen Eindruck nicht stören? (Ich fürchte nicht; sichtbare Zeichen wie zum Beispiel ASCII-spaces zwischen den Schriftzeichen fallen als eurozentrische Lösungen weg.) Normalisierungs-Skript schreiben. Darf bestehende bedeutungstragende ZWS (wo ihre Abwesenheit also bereits ein mehr-Zeichen-Wort ausdrückt) nicht verändern. Gesucht ist eine Lösung, die die Suche im XML nicht zerbricht.

Problem des Skripts zum Eintragen der ZWS: Woher soll man wissen, dass das Fehlen eines ZWS nicht bedeutungstragend ist? Man braucht eigentlich nicht nur den ZWS, sondern auch ein positives Signal, zum Beispiel den zero width joiner (ZWJ). Dann muss das Skript nur zwischen direkt aufeinanderfolgenden Schriftzeichen ein ZWS einfügen. Aber der ZWJ schafft sicher neue Probleme. Und eigentlich hat der ZWJ eine andere Aufgabe!

• Welche konkret, für Textanzeige oder Suche?

Überschriften

Überschriften werden zentriert angezeigt. Die unterschiedlichen Verschachtelungstiefen werden durch die Zentrierung verschleiert. Kann man das ändern? Das Problem ist offensichtlicher als bei europäischen Texten, weil es die Verschachtelung durch Einrückung markiert wird und nicht durch Hinweise im Text. Der Zusammenhang mit der Einrückung ist nicht gradlinig, allerdings sollen die Chinesen <ti>, <h 1>, <h 2> etc. tippen.

• Ebene 1 (alle <ti>, z.B. 天工開物卷上 und 分宜教諭宋應星著 auf Seite 6A): Einrückung entweder 0 oder nahezu rechtsbündig
• Ebene 2 (<h 1>, z.B. 乃​粒​第​一卷): Einrückung 2
• Ebene 3 (<h 2>, z.B. 總​名): Einrückung 1
• (im toc ist es wieder anders)

Lösung ist wohl einfach, dass <head> (aber wohl nur bei chinesischen Texten) ein Attribut "headlevel" bekommt, siehe oben. Sonst: Eine Überschrift "weiß" von seinem übergeordneten div, wie weit es verschachtelt ist, allerdings fängt die Zählung nicht bei null an.

Dann kann ich mir auch die verschachtelten div's im toc sparen. Allerdings funktioniert das dann nur bei chinesischen Texten, nicht bei europäischen.

Andererseits: wenn man "headlevel" auch für europäische Texte einführt, müsste man es zwar im post-processing per Hand einfügen, aber danach könnte das div-Skript automatisch eine hierarchische div-Struktur einfügen. Letztlich eine Frage von Henne oder Ei, irgendwo muss die Information hinein, egal ob über head oder über div. Bei chinesischen Texten steht sie bereits im head. (Selbst dann könnte das "div einfügen"-Skript die Information in zum Beispiel <h 2> direkt auswerten. Leichter wäre es allerdings mit einem Attribut.) Bei europäischen Texten würde das (dann fehlende) headlevel-Attribut eventuell eine weitere Hürde schaffen, andererseits verwendet das div-Skript es halt nur, wenn es da ist.

Zeichen-Varianten

Eventuell steigen wir von IDS-Sequenzen auf IVS-Sequenzen um.

• IDS-Sequenzen geben wieder, wie das Zeichen aussieht, aber das Ergebnis ist unförmig.
• IVS-Sequenzen verweisen auf eine Liste, in der die Variation aufgeführt ist. Wenn das Zeichen in der Liste nicht vorkommt, gibt es keinen Anhaltspunkt, wie das Zeichen genau aussieht (außer dass es eine Variation des angegebenen Zeichens ist). Und selbst wenn das Zeichen in der Liste vorkommt, haben wir keine einfache Möglichkeit, das korrekte Zeichen auch anzuzeigen, sondern müssen auf die Liste verweisen (oder?). Vorteil wäre aber, dass man kein <reg> braucht, sondern einfach ein unsichtbares Zeichen einfügt. Es ist unklar, ob die vorhandene Liste unsere Beispiele bereits enthält; die bisher geprüften Beispiele haben sich zum Teil als nicht markierwürdig herausgestellt, und das restliche Zeichen war nicht in der Liste.

Vielleicht ist es am besten, eine IVS-Sequenz zu verwenden, wenn es das Zeichen in der Liste schon gibt, und sonst eine IDS-Sequenz.

weitere mögliche Konsequenzen

für die DESpecs

• Die Regelung, dass Zeichenvarianten nur beim ersten Mal markiert werden sollen, muss noch überarbeitet werden. Problem ist, dass ein Text sowohl das Standardzeichen als auch mehr als eine Variante enthalten kann. An welcher Ebene setzt man an, beim Abtippen oder bei der Nachbearbeitung?
  • wenn im post-processing: Man hat die Information, welche Zeichen es betrifft. Man hat auch (oder erstellt mit wenig Aufwand) eine Liste der möglichen Zeichen. Gehe alle Vorkommnisse des Schriftzeichens im Text durch. Standardzeichen: ok: Variante: prüfe, ob nicht doch in Unicode. Sonst IDS-Sequenz erstellen. Im Text nur markieren mit v1, v2, etc. hinter dem Zeichen. Wird dann automatiisiert durch ein <reg> ersetzt, das im besten Fall die IDS-Sequenz verwendet. Wie groß wäre der Aufwand in der Praxis?
• \\ in <desc> erlauben, oder nur einfach damit umgehen können, falls es gemacht wird?
• nochmal darüber nachdenken: large spaces in Überschriften doch genau tippen lassen?

für das Schema

• < V> vorläufig als <reg norm="鬵" type="unresolved">鬵</reg>. Explizite Typen einführen, z.B. "variant/auto" (für mit < V> markierte Zeichen) und "variant?/auto" (für Zeichen, die bereits an anderer Stelle als < V> markiert wurden). Siehe Variantenmarkierung in den DESpecs.
• Attribut von <head>: Verschachtelungstiefe. Siehe unten.
• aufgeteiltes Bild auf Seite 76B / 154: Lösung für das Problem von mehr als einer caption. Okay so, oder muss man in <figure> etwas wie Unter-Figures oder <teil-figure> erlauben? Problem ist auch: Nach den bisherigen Erfahrungen wird das bei der Transkription nicht funktionieren, wir sprechen also über etwas, was man im post-processing machen müsste.
• ein bisschen (aber nicht völlig) analog zu <pb>: <anchor> direkt in <p> erlauben, damit man nicht </s> hinter die Figure verschieben muss? Kein großer Leidensdruck, und das Ergebnis wäre auch nicht konsequent.

Bild mit Beschreibungstext auf Seite 83B / 168: Weitere Kategorie neben caption, description, variables? Zum Beispiel <explanation>. (Oder man erlaubt einfach <p> in <figure>? Aber das wäre ein bisschen inkonsequent.)

Eine Alternative wäre, in <description> das echo.flexible.model zu erlauben: Also

echo.description.attlist = echo.inline.attrib
echo.description.content = echo.inline.model

wird zu

echo.description.attlist = empty
echo.description.content = echo.flexible.model

(und genauso für <caption>, aber nicht für <variables>). Die Lösung mit <explanation> kommt mir aber geeigneter vor. Insbesondere weil <description> normalerweise im Bild ist und nicht neben oder unter dem Bild.

Beispiel Bion 1765 (WO 6):

<cap><rom>TABULA I</rom>.</cap>
<cap it>pag. 6.</cap>

Das hat Klaus jeweils zu einer caption mit einem <lb> gemacht. Analogie zu Überschriften wäre aber, es als zwei captions zu lassen. Brauchen wir also auch caption-Gruppen analog zu head-Gruppen? (Diese Frage ist unabhängig von de figurepart-Frage, denn es bezieht sich nur auf captions, die unmittelbar hintereinander kommen.)

xhtml-Listen:

• ich musste ein <pb> (Seite 208A / 417) tiefer verschieben, d.h. vorher zwischen </dd> und <dt>, nachher auf einer Höhe wie <s> im <dd> davor. Ist das so gewünscht?
• <dl> kann laut Schema überall da sein, wo auch ein float sein kann, also nicht direkt in <dl>, sondern nur in <s>. Das ist aber bei verschachtelten Listen Unsinn. Schema ändern? Das Flow-Model und Inline-Model von xhtml wurde ja im Schema umdefiniert und würde dann nochmal umdefiniert werden. Konkret könnte man in <dl> auch weiteres xhtml erlauben. (Oder in <dd> sowohl das echo-inline-model als auch weiteres xhtml ?) Erstmal jedenfalls: auf die Einrückung verzichtet. (Ändern, sobald es geht!)

mögliche Änderungen in echo-chinese-text:

• <sm>, <hb/>
• "variant", "variant/auto", "variant?/auto"
• headlevel (oder nur level)? wenn, dann optional
• figure: <part>? <explanation> oder <subcaption>? Wie heißen figure-Teile bei TEI?
• bei note-Type footnote: position "sm"
• <anchor> direkt in <p> erlauben?
• Attribut für "73B" in <pb>? Oder doch "o" verwenden?
• Inhalt von xhtml?

für den Workflow

• Die Logik, die <pb> so weit wie möglich in der Hierarchie zu verstecken, habe ich bei diesem Text nicht angewendet. Sollte man das nachholen? Dann müsste zum Beispiel eine Seiten-Figure auch den nachfolgenden <pb> enthalten. Keine technische, sondern eine konzeptionelle Frage. Zumindest bei <div> ist aber klar, dass <pb> hineingezogen wird. Und in <s> könnte man <pb> auch problemlos hineinziehen.
• In chinesischen Texten können problemlos Überschriften in der letzten Zeile auftreten, das ist also kein Hinweis auf einen Fehler, im Gegensatz zu europäischen Texten. Beispiel 104B, wo man den folgenden Text auf 105A im aufgeschlagenen Buch nebeneinander sieht, und auch 148A / 148B, wo das nicht der Fall ist. (Die Überschrift auf Seite 85B ist wirklich ein footer.) Konsequenterweise müsste man <pb> auch in <head> verschieben. Dieser Fall kommt in europäischen Texten bisher nur bei mehreren Textflows vor, also beispielsweise beim Eipo-Text.
• Skript für "pb verstecken"? Das wäre auch wichtig, um andere workflows zu integrieren.
• Was machen wir aus large spaces?
  • In Song Yingxing will Dagmar sie genau so getippt haben, wie sie im Text stehen.
  • Laut DESpecs als ein einzige space getippt. (Large) spaces zu Doppelpunkten wenigstens in Überschriften, siehe 8B; wird nicht immer sinnvoll sein, insbesondere bei mehr als einem large space.
  • # in <p>? Gibt es eine allgemeine Lösung? (Manchmal auch "übersehenes" Absatzende?)
• Aufzählungen: Gibt es überhaupt Bedarf, Aufzählungen ausdrücklich zu markieren? Wenn ja: Wie beschreibt man die verschiedenen Aufzählungstypen in chinesischen Texten? Zum Beispiel 194B: Wohl nicht mit xhtml? Einfach als <s>, und akzeptieren, dass es "zu kurze Zeilen" gibt? Wenn man 25B ff zu einer Aufzählung machen will innerhalb des Absatzes, wie sollte das dann aussehen? Woran erkennt man den Unterschied "Aufzählung innerhalb eines Absatzes" vs "neuer Absatz"?