Erfassung visueller Strukturen des Textträgers

Angaben zu Inhaltsflächen

<surface>/@ana Die Art der von <surface> repräsentierten Inhaltsfläche wird an @ana angegeben, in der Regel handelt es sich dabei um eine Seite (hc:Page).

hc:Page ( ›Seite‹ ): Eine der beiden Seiten eines Blattes.

Andere vorgesehenen Typen von Inhaltsflächen sind:

hc:FrontCover ( ›Vorderdeckel‹ ):

hc:BackCover ( ›Hinterdeckel‹ ):

hc:FrontPasteDown ( ›Vorderspiegel; Rückseite des Vorderdeckels; Innenseite des Vorderdeckels‹ ):

hc:BackPasteDown ( ›Hinterspiegel; Rückseite des Hinterdeckels; Innenseite des Hinterdeckels‹ ):

hc:BookBack ( ›Buchrücken‹ ):

hc:ForeEdge ( ›Vorderschnitt‹ ):

hc:TopEdge ( ›Kopfschnitt; Oberschnitt; Oberkante‹ ):

hc:BottomEdge ( ›Fußschnitt; Unterschnitt; unterer Buchschnitt‹ ):

<surface>/@n Der Wert des Attributs @n wird als Seitenbezeichner in der Visualisierung angezeigt. Er enthält meist eine Nummer, bei mittelalterlichen Handschriften häufig zusätzlich mit ›r‹ oder ›v‹ (für recto bzw. verso). Möglich sind aber auch verbale Bezeichner wie Vorderdeckel oder Nummern mit Zusätzen wie Buchstaben oder Sternchen, z. B. 4a oder 1*, oder auch Kombinationen solcher Muster.⁴⁾

<surface>/@xml:id Der Wert des Attributs @xml:id ist vom Herausgeber grundsätzlich frei wählbar. Wir empfehlen eine Syntax, die dem für @n gewählten Seitenbezeichner einen Identifier für den Inhaltsträger bzw. Textzeugen voranstellt, getrennt durch einen Unterstrich, z. B. cpg389_4r oder A_4r.⁵⁾

Eine typische Abfolge der <surface>-Elemente mit ihren Attributen wäre z.  B.:

Verknüpfung zum Digitalisat Das Element <surface> trägt als erstes Kindelement das Element <graphic>, das die Verknüpfung zu einer digitalen Abbildung der Inhaltsfläche herstellt:

• <graphic> ( ›Abbildung‹ ) Strukturierte Angabe der Verknüpfung zu einer digitalen Abbildung des visuellen Objekts, dessen Inhalt durch das Elternelement repräsentiert, dokumentiert und erschlossen wird. (Für die Definition der TEI s. ↪ TEI.)
  • @url( ›URL‹ ) gibt die URL einer digitalen Abbildung an.
  • @mimeTypegibt den Medientyp des verknüpften Bildes als MIME media type an.

Angaben zu Typen von Inhaltsbereichen

Auf einer Inhaltsfläche (› hc:ContentSurface ‹) sind einzelne Inhalte in Inhaltsbereichen (› hc:ContentZone ‹) untergebracht. Inhaltsbereiche werden <zone>-Elemente repräsentiert, die in <facsimile> entweder direkt als Kindelemente innerhalb von <surface> oder innerhalb eines übergeordneten <zone> stehen. Ein Element <zone>, das seinerseits kein Kindelement <zone> enthält, ist ein Inhaltsbereich (von Ausnahmen bei Hilfsbereichen – › hc:AuxiliaryZone ‹ – abgesehen).

<zone>/@ana Je nach Inhaltstyp werden in ›heiEDITIONS‹ folgende Kategorien von Inhaltsbereichen unterschieden, die jeweils an @ana anzugeben sind:

hc:TextZone ( ›Textbereich‹ ): Inhaltsbereich, der aus mindestens einer Zeile besteht.

hc:InitialZone ( ›Bereich mit einer Initiale‹ ): Bereich, der eine Initiale enthält. Solche Bereiche haben einen hybriden Charakter, weil sie textuellen und bildlichen Inhalt gleichzeitig tragen. Sie enthalten eine Textzeile mit meist einem einzigen Zeichen und verweisen gleichzeitig auf einen Bildausschnitt.

hc:TableZone ( ›Tabellarischer Bereich‹ ): Inhaltsbereich, der aus einer Tabelle oder einem Teil einer Tabelle besteht.

hc:MathematicalFormulaZone ( ›Bereich mit einer mathematischen Formel‹ ):

hc:ChemicalFormulaZone ( ›Bereich mit einer chemischen Formel‹ ):

hc:MusicalNotationZone ( ›Bereich mit musikalischer Notation‹ ):

hc:ImageZone ( ›Bildbereich‹ ):

hc:LineDrawingZone ( ›Bereich mit Strichzeichnung‹ ):

hc:GraphicZone ( ›Graphikbereich‹ ):

hc:ChartZone ( ›Diagrammbereich‹ ):

hc:MapZone ( ›Kartenbereich‹ ):

hc:SeparatorZone ( ›Trennbereich‹ ):

hc:SpaceZone ( ›Freiraumbereich; Aussparungsbereich‹ ):

In einem einfachen Fall, wenn sich auf einer Seite ein einziger Textbereich befindet, könnte dies innerhalb von <facsimile> auf folgende Weise deklariert werden:

Abb. 1: Eine Seite mit einem einzigen, nicht näher beschriebenen Textbereich.

Layouterfassung

Wenn auf einer Inhaltsfläche mehrere Inhaltsbereiche vorkommen, die in einer bestimmten Anordnung zueinander stehen, bietet ›heiEDITIONS‹ die Möglichkeit, ohne Rückgriff auf explizite Koordinatenangaben das Layout mithilfe rechteckiger horizontaler und vertikaler Container grob zu beschreiben. Dazu dienen <zone>-Elemente innerhalb von <surface>, die als übergeordnete Container einzelne Inhaltsbereiche gruppieren. Eine solche Deklaration des Layouts kann direkt für die Visualisierung in der Quellenansicht nachgenutzt werden.⁶⁾

Ohne eine Deklaration des Layouts mithilfe übergeordneter <zone>-Elemente werden die ggf. direkt auf Kindebene von <surface> platzierten und einzelne Inhaltsbereiche repräsentierenden <zone>-Elemente als vertikal übereinander stehend verstanden und entsprechend verarbeitet. Diese einfache Struktur kann (und soll) verwendet werden, wenn sich tatsächlich innerhalb einer Inhaltsfläche mehrere Inhaltsbereiche vertikal übereinander befinden und keine weiteren Informationen zu ihrer Anordnung (etwa zur Ausrichtung) angegeben werden sollen. So könnte eine Seite mit einem Textbereich und einem darunter befindlichen Bildbereich wie folgt beschrieben werden:

Abb. 2: Eine Seite mit einem Textbereich und einem Bildbereich darunter.

Komplexere Anordnungen lassen sich mit horizontalen und vertikalen Containern beschreiben, die mit <zone> des Typs › hc:HorizontalLayout ‹ bzw. › hc:VerticalLayout ‹ kodiert werden.

hc:HorizontalLayout ( ›horizontales Layout‹ ): Gruppierungsbereich, dessen Elemente nebeneinander horizontal fest angeordnet sind, vergleichbar mit einer Zeile.

hc:VerticalLayout ( ›vertikales Layout‹ ): Gruppierungsbereich, dessen Elemente übereinander vertikal fest angeordnet sind, vergleichbar mit einer Spalte.

Die Beschreibung einer Seite mit zwei Textbereichen nebeneinander demonstriert das folgende Beispiel. Hier dient das übergeordnete <zone> als Container für die Gruppierung und richtige Anordnung der beiden Textbereiche. Erst die beiden Textbereiche sind jeweils Inhaltsbereiche (› hc:ContentZone ‹). Auf eine mögliche Bezeichnung der beiden Textbereiche als ›Spalten‹ wird hier übrigens noch verzichtet, vgl. dazu unten den Abschnitt Semistrukturelle Angaben zu Layout- und Inhaltsbereichen.

Abb. 3: Eine Seite mit zwei Textbereichen nebeneinander.

Das Attribut @hei:width am Kindelement eines Containers macht es möglich, mit Prozentangaben die relative Breite eines Bereichs in Bezug zur Breite seines übergeordneten Containers anzugeben. Die Summer aller Breitenangaben an Kindelementen eines horizontalen Containers darf nicht 100 überschreiten (bei einem vertikalen Container ist das denkbar, da sich die Breitenangabe dann auf die Ausdehnung entlang der Querachse bezieht).⁷⁾

Abb. 4: Eine Seite mit zwei unterschiedlich breiten Textbereichen nebeneinander.

Eine explizite Angabe der relativen Höhe eines Bereichs ist nicht vorgesehen.⁸⁾

Durch die Kombination eines horizontalen Containers mit einem nachfolgenden direkten Kindelement von <surface> ist es beispielsweise möglich, ein Layout zu beschreiben, bei dem zwei Textbereiche nebeneinander stehen und unter ihnen beiden sich ein dritter Textbereich befindet, wie das folgende Beispiel vorführt.

Abb. 5: Eine Seite mit zwei Textbereichen nebeneinander und einem dritten Textbereich unter ihnen.

Bei den Beispielen auf Abb. 2 und 5 befinden sich auf oberster Ebene

Semistrukturelle Angaben zu Layout- und Inhaltsbereichen

Ergänzend zur Angabe des jeweiligen Inhaltstyps eines Inhaltsbereichs und zur strukturellen Beschreibung des Layouts mithilfe von Angaben zu einem Containertyp und dessen Ausrichtung an @ana und @rendition können <zone>-Elemente am Attribut @ana weitere ergänzende Angaben tragen, die ihre Stellung im Layoutsystem einer Inhaltsfläche beschreiben. Die Bereitstellung solcher Angaben und deren Präzision ist dem Ermessen des Herausgebers überlassen; wenn verwendet, sollten diese Angaben aber semantisch mit ›heiEDITIONS Concepts‹ konform sein.

hc:MainZone ( ›Hauptbereich‹ ): Bereich einer Inhaltsfläche, der sich innerhalb des Satz- oder Schriftspiegels befindet.

hc:MarginalZone ( ›Randbereich‹ ): Bereich einer Inhaltsfläche, der sich außerhalb des Satz- oder Schriftspiegels befindet, in mehrspaltigem Layout ggf. auch zwischen Spalten.

hc:Column ( ›Spalte‹ ): Planvoll angelegter und für regelmäßig zu platzierenden Inhalt geschaffener Bereich einer Inhaltsfläche, der entweder direkt einen homogenen Inhalt enthält oder als Container für andere untergeordnete Inhaltsbereiche fungiert.

hc:MainColumn ( ›Hauptspalte‹ ): Spalte innerhalb des Satz- oder Schriftspiegels.

hc:MarginalColumn ( ›Randspalte‹ ): Spalte außerhalb des Satz- oder Schriftspiegels.

Ergänzende Angaben zur Platzierung von Randbereichen

TODO

Grundsätzliches zur Zeilenerfassung

Die Zeile ist in der visuellen Strukturhierarchie einer inhaltstragenden Fläche unterhalb der Ebene von Inhaltsbereichen angesiedelt und ist in dieser Hierarchie ›von oben kommend‹ die erste Einheit, die direkt Textzeichen enthalten kann.

hc:Line ( ›Zeile‹ ): Eine geordnete, gerichtete und visuell kohärente Sequenz von Glyphen und ggf. anderen Elementen, die in der Regel, jedoch nicht zwingend einer geometrischen Geraden folgt, immer aber auf einem intentional geschaffenen visuellen Zusammenhang gründet.

Zeilen sind die konstituierenden Komponenten von Textbereichen (› hc:TextZone ‹), die in der Regel als unmittelbare Container für jeweils eine geordnete Sequenz von Zeilen fungieren.⁹⁾

Wenn das Digitalisat der Quelle (das inhaltstragende Artefakt) einer Expression nicht mithilfe von Koordinatenangaben segmentiert wird (typischerweise anhand eines OCR/HTR-Systems), sodass Koordinatenangaben in das TEI-Dokument integriert würden, sind innerhalb der Layoutdeklaration in <facsimile> keine Angaben zu Zeilen erforderlich. In der Arbeitskodierung werden lediglich im laufenden Text (innerhalb von <text>) punktuell die Zeilenanfänge mit <lb> markiert. Dabei ist für die Anordnung der Zeilen innerhalb eines Inhaltsbereichs die Nummerierung der <lb>-Elemente mit @n signifikant. Die so markierten Zeilen werden implizit auf den nächsten vorausgehenden, im Text mit <cb>, <milestone ana="hc:ZoneBeginning"> oder <milestone ana="hc:ZoneShift"> (s. oben Verknüpfung zwischen Text und Faksimiledeklaration) angegebenen Inhaltsbereich bezogen und diesem zugewiesen.

Zeilenanfänge Nachdem also, wie oben unter Verknüpfung zwischen Text und Faksimiledeklaration beschrieben, jeweils der Anfang eines Inhaltsbereichs mit <cb> (bei Spaltenanfängen) oder <milestone ana="hc:ZoneBeginning"> (bei Anfängen sonstiger Inhaltsbereiche) gekennzeichnet worden ist (bzw. ggf. der Wechsel zurück in einen zuvor bereits einmal begonnenen Inhaltsbereich mittels <milestone ana="hc:ZoneShift"> deklariert worden ist), wird vor den Text jeder Zeile das Element <lb> (line beginning) gesetzt. Dieses Element ist immer leer, es muss jedoch das Attribut @n tragen.

Im vorangehenden Beispiel befindet sich der Text mit jeweils markierten Zeilenanfängen in einem <p>, der Text der fünf Zeilen bildet also semantich-logisch einen Absatz als Sinneinheit. Die Verwendung semantisch-logischer Elemente (wie <p> oder <l>) bringt keine implizite Aussage über die Zeilenaufteilung mit sich, sie ersetzt nicht die Kennzeichnung eines Zeilenanfangs mit <lb>.

Es spielt jedoch keine Rolle, ob beim Zusammentreffen visueller Anfänge und der Anfänge von Sinneinheiten das eine oder andere zuerst gesetzt wird. Im vorliegenden Beispiel wird zunächst <p> als Sinneinheit geöffnet und innerhalb des <p> werden der Spaltenanfang under Zeilenanfang gesetzt. Genauso könnte aber auch das <cb> direkt vor dem <p> stehen; das <lb> für Zeile 1 könnte dann entweder am Anfang des <p> bleiben oder ebenfalls dem <p> vorangehen.¹⁰⁾

In einer Gedichtstrophe (<lg>) könnten – bei einer regelmäßigen Absetzung jedes Verses in der Quelle – die Zeilenanfänge einzelner Verse (<l>) so erfasst werden:

Genauso möglich wäre aber stattdessen auch:

Die Insignifikanz der Position von Markern visueller Anfänge beim Zusammentreffen mit Anfängen von Sinneinheiten ergibt sich daraus, dass sie konzeptionell unterschiedliche ›Textdimensionen‹ eingrenzen, die zumindest technisch voneinander unabhänig sind. Da auf die Frage, ob zuerst ein Vers anfängt oder die Zeile, in der der Vers steht, keine eindeutige Antwort möglich ist, ist die Position der entsprechenden Elemente in ›heiEDITIONS‹ irrelevant. Von der Sache her verhält es sich am ehesten so, dass beides gleichzeitig anfängt, dies lässt jedoch mit XML/TEI nicht unmittelbar abbilden, da zwei XML-Elemente nicht dieselbe Position in einem XML-Dokument einnehmen können.¹¹⁾ Auch wenn die technische Abfolge der beiden Typen von Anfängen in einem TEI-Dokument also letztlich beliebig ist, empfiehlt sich jeweils projektspezifisch eine einheitliche Regelung.

Wie bei <pb>, <cb>, <milestone ana="hc:ZoneBeginning"> oder <milestone ana="hc:ZoneShift"> gilt auch für die Markierungen von Zeilenanfängen mit <lb>, dass Leeraum (Leerzeichen oder Zeilenumbruchzeichen im TEI-Code) davor und danach grundsätzlich insignifikant ist. Zur besseren Lesbarkeit kann also <lb> z. B. jeweils auf eine eigene Zeile gesetzt werden.

In tokenisierten Texten, in denen Leerzeichen explizit mit <c> erfasst werden, sollen am Zeilenende und am Zeilenanfang keine Leerzeichen angegeben werden. Es gilt das Prinzip: Eine Zeile fängt nie mit einem Leerzeichen an und endet auch nie mit einem Leerzeichen.

Zeilennummerierung Die Nummer im Wert des Attributs @n bezeichnet die Zeilennummer in der natürlichen Zeilenabfolge des jeweiligen Textbereichs. Die Nummer ist als solche signifikant und bestimmt die Position jeder Zeile in einem Textbereich (also in der Zeilensequenz innerhalb eines Textbereichs). Sofern Zeilen nicht in <facsimile> explizit deklariert sind, werden sie in der Verarbeitung des TEI-Dokuments für die ›Quellenansicht‹jeweils pro Textbereich nach dem nummerischen Wert von @n geordnet. Die Zeilennummerierung sollte also der tatsächlichen Abfolge der Zeilen innerhalb eines Textbereichs in der Quelle entsprechen und diese wiedergeben. Allerdings kommt es dabei nicht auf den absolten Zahlenwert an, sondern allein auf die nummeriche Abfolge. Das bedeutet praktisch, dass die Zeilenzählung nicht zwingend in jedem Inhaltsbereich neu bei Eins anfangen muss. Eine größere Zahl bedeutet eine spätere Position in einer Zeilensequenz. Die nummerischen Werte in @n sind nicht auf Ganzzahlen beschränkt. Unter Umständen, etwa bei Interlinearzeilen, kann es sinnvoll sein, mit einer sekundären Nummerierung zwischen als primär geltenden Zeilen zu arbeiten. In solchen Fällen können Dezimalzahlen mit Punkt als Dezimaltrennzeichen verwendet werden. Eine Zeile mit der Nummer 1.1 würde sich zwischen den Zeilen 1 und 2 befinden. Der relative Abstand einer Dezimalzahl von benachbarten Ganzzahlen (1,1 ist nummerisch näher an 1 als an 2) spielt dabei keine Rolle – allein die Position in der Zeilensequenz ist von Bedeutung.¹²⁾

Ein grundlegendes Prinzip ist, dass die Abfolge der <lb>-Elemente mit ihren den Quellenbefund wiedergebenden Zeilennummern in einem semantisch-logisch strukturierten TEI-Dokument nicht der Zeilenabfolge in der Quelle entsprechen muss. Die ›semantisch-logische Kodierung‹, die in ›heiEDITIONS‹ und auch sonst in der TEI-Community meist die primäre Kodierung ist und im Wesentlichen ebenfalls der Arbeitskodierung entspricht, gibt eine Expression in der Anordnung wieder, in der diese sinnvoll gelesen werden soll. Diese sinngemäße Leseanordnung weicht gelegentlich von der visuellen Anordnung in der Quelle ab. Meist sind Abweichungen in der Anordung am Wechsel zwischen Textbereichen festzumachen, etwa wenn der Textlauf von einer Spalte in eine Marginalie wechselt und danach wieder in der Spalte fortgesetzt wird. Gelegentlich kann aber auch innerhalb eines Textbereichs die visuelle Abfolge von der sinnvoll zu lesenden Abfolge abweichen. Zeilenüberläufe und quer zur Zeilenanordnung verlaufende parallele Textströme (s. u. Zeilenüberläufe und quer zu Zeilen verlaufende Textströme) sind die typischsten Phänomene dieser Art.

Grundsätzlich hindert einen Herausgeber nichts daran, die sinngemäße Leseabfolge des Textes völlig frei festzulegen und dabei Abweichungen von der visuellen Abfolge der Zeilen in der Quelle in Kauf zu nehmen. Das folgende Code-Beispiel führt einen solchen Vorgang vor:

Im vorangehenden Beispiel legt der Herausgeber fest (ohne hier auf mögliche Gründe für diese Entscheidung einzugehen), dass der Text auf Zeile 3 der Quelle als Vers 2 zu lesen ist. Die ›Leseansicht‹ von ›heiEDITIONS‹ wird diese vom Herausgeber festgelegte Reihenfolge, die in der Dokumentreihenfolge der semantisch-logischen Kodierung ihren Ausdruck findet, respektieren. Die ›Quellenansicht‹ hingegen, die den visuellen Befund der Quelle reproduziert, wird den Text entsprechend der Nummerierung an <lb> Zeile für Zeile so ausgeben, wie es dem Befund in der Quelle entspricht.

Entscheidend für diese vom Herausgeber festzulegende Leseabfolge ist die Dokumentreihenfolge der Arbeitskodierung, also die Reihenfolge im geordneten Baum des XML-Dokuments bzw. die Zeichenreihenfolge der Datei. Keine wesentliche Rolle spielt dabei hingegen eine etwaige Nummerierung der Sinneinheiten, z. B. der Verse (<l>) im letzten Code-Beispiel. Die explizite Nummerierung von Sinneinheiten mit @n kann ganz anderen Zwecken dienen als der Festlegung der Leseanordnung (etwa projektspezifisch der Korrelation mit einer älteren Ausgabe). Wenn der Herausgeber die Versnummerierung mit @n mit einer anderen Bedeutung als der Leseanordnung belegt, könnte das letzte Beispiel auch wie folgt aussehen, ohne dass sich an der Lesereihenfolge etwas ändern würde:

Worttrennung

@breakDie Zeilengrenzen entsprechen bekanntlich nicht immer den Wortgrenzen. Mit @break stellt die TEI ein einfaches Mittel zur Verfügung, mit dem ausgedrückt werden kann, ob ein Zeilenanfang gleichzeitig auch mit dem Anfang eines Tokens zusammenfällt, also ob die Zeilengrenze gleichzeitig auch eine Tokengrenze ist. Mit <lb break="no"> kann ausgedrückt werden, dass es sich um keine Tokengrenze handelt, dass der betroffene Zeilenanfang also mitten in einem Wort liegt.

Im vorangehenden Beispiel steht jede Zeilenanfang-Markierung auf einer eigenen Zeile, auch Zeilenanfänge, die sich mitten im Wort befinden und mit <lb break="no"> gekennzeichnet sind. Wie bereits mehrfach erwähnt, gelten Leerzeichen vor und nach einem Zeilenanfang als insignifikant – das gilt auch mitten im Wort. Die in der Quelle vorhandenen Trennstriche sind in diesem Beispiel nicht explizit erfasst (zur expliziten Erfassung von Trennstrichen und ähnlichen Trennzeichen s. TODO).

Selbstverständlich besteht in nicht explizit und vollständig tokenisierten Texten wie beim vorangehenden Beispiel keine Sicherheit, dass Leerzeichen mitten in der Zeile immer zuverlässig die linguistisch korrekte Wortgrenze markieren. Der Aussagewert von @break beschränkt sich nur auf Wortgrenzen am Zeilenende bzw. Zeilenanfang.

In tokenisierten Texten, in denen jedes Wort mit <w> markiert ist (zur Tokenisierung s. TODO), muss an <lb>-Elementen innerhalb eines Wortes @break nicht händisch gesetzt werden. Wenn es fehlt, wird es während der Verarbeitung ergänzt.

Zeilensegmente

Zwischen den visuellen Gliederungsebenen der Zeilen und der Zeichen bzw. Glyphen kann bei Bedarf zusätzlich die Ebene der Zeilensegmente angesetzt werden.¹³⁾

hc:LineSegment ( ›Zeilensegment‹ ): Eine geordnete, gerichtete und visuell kohärente Sequenz von Glyphen und ggf. anderen Elementen innerhalb einer Zeile.

Grundsätzlich kann jede Zeile beliebig in Zeilensegmente unterteilt werden. Ähnlich wie bei Zeilenanfängen wird in der Arbeitskodierung und in der semantisch-logischen Kodierung nur der Anfang eines Zeilensegments punktuell gekennzeichnet, und zwar mit <milestone ana="hc:LineSegmentBeginning">.

hc:LineSegmentBeginning ( ›Zeilensegmentanfang‹ ): Punktuell gedachter Anfang eines Zeilensegments.

Abb. 15: Eine Zeile mit drei Zeilensegmenten.

Der Text einer Zeile mit der in der vorangehenden Abbildung skizzierten Struktur würde (etwa innerhalb eines Absatzes) wie folgt kodiert:

Wenn dem jeweils ersten Zeilensegment in einer Zeile keine weiteren Informationen beigegeben werden sollen, kann auf die explizite Deklaration des entsprechenden Zeilensegmentanfangs verzichtet werden:

Zeilensegmente können verwendet werden, um Zeilenteile mit Informationen über ihre Ausrichtung und Abstände innerhalb der Zeile zu versehen (vergleichbar mit Tabulatoren im Desktop-Publishing); zu dieser Verwendung vgl. weiter unten Ausrichtung und Abstände. Sie dienen außerdem dazu, die Rückkehr eines Textstroms in eine Zeile zu erfassen, wenn der Textstrom zuvor die Zeile verlassen hat, typischerweise um vorübergehend in einer Marginalie fortgesetzt zu werden. In solchen Fällen findet ein zweifacher Wechsel des Textbereichs statt (zwischen einer Hauptspalte und einem Randbereich und danach zwischen dem Randbereich und der ursprünglichen Hauptspalte). Ein weiterer Einsatzbereich von Zeilensegmenten ist die Erfassung von Zeilenüberläufen.

@hei:belongsToLine Bei der Verwendung von Zeilensegmenten für die beiden zuletzt genannten Zwecke kann es erforderlich sein, bei Zeilensegmenten (mit Ausnahme des jeweils ersten Zeilensegments, dessen Anfang praktisch mit dem Zeilenbeginn zusammenfällt) ihre jeweilige Zugehörigkeit zu einer Zeile explizit anzugeben, und zwar immer dann, wenn das Zeilensegment einer anderen Zeile als derjenigen angehört, deren Anfang mit dem nächsten vorausgehenden <lb> markiert ist. Diese Aufgabe übernimmt das Attribut @hei:belongsToLine. Dieses Attribut mit dem Datentyp teidata.text erwartet Werte, die mit der Zeilennummerangabe in @n am zugehörigen <lb> übereinstimmen müssen, normalerweise also einfach die Nummer der zugehörigen Zeile.¹⁴⁾ Näheres und Beispiele sind den folgenden Abschnitten zu entnehmen.

Ausrichtung und Abstände

Eine Zeile ist ein visueller Gegenstand, der normalerweise in einen größeren visuellen Kontext (einer Inhaltsfläche und eines Inhaltsbereichs) eingebettet ist und zu anderen visuellen Objekten in einer Beziehung steht. In ›heiEDITIONS‹ wird angenommen, dass Zeilen in der Regel in einem Textbereich eine geordnete und gerichtete Sequenz bilden (wobei es natürlich auch Textbereiche mit einer einzigen Zeile geben kann) und dass diese Zeilensequenz den Textbereich konstituiert.

›heiEDITIONS‹ unterstützt bei Zeilen und Zeilensegmenten grundsätzlich die Erfassung zweier Arten visueller Bezüge:

• visuelle Bezüge von Zeilen oder Zeilensegmenten untereinander, jeweils zum nächsten vorausgehenden oder nachfolgenden Geschwistergegenstand
• visuelle Bezüge von Zeilen oder Zeilensegmenten zu ihrem Elterngegenstand (Inhaltsbereich oder Zeile), also zu den Rändern ihres direkt übergeordneten Containers

Die im folgenden beschriebenen Mechanismen sind unterschiedlich mächtig und dementsprechend auch unterschiedlich komplex. Sie dienen in erster Linie der Beschreibung der visuellen Strukturen der Quelle, nicht etwa als Formatierungsanweisungen für editorische Sekundärtexte. Die Visualisierung der ›Quellenansicht‹ von ›heiEDITIONS‹ unterstützt die hier beschriebenen Konstrukte nur eingeschränkt durch direkte visuelle Nachbildung.

Einrückungen & Ausrückungen Häufig zu erfassende Phänomene bei der visuellen Erscheinung von Zeilen sind auf horizontaler Achse Einrückungen und Ausrückungen sowie auf vertikaler Achse Abstände nach oben und unten.¹⁵⁾ Zur einfachen Dokumentation von Einrückungen und Ausrückungen können an <lb> bzw. <milestone ana="hc:LineSegmentBeginning"> jeweils mit dem Attribut @rendition diese Angaben gemacht werden:

hc:LeftIndent ( ›links eingerückt‹ ): Links eingerückter textueller visueller Gegenstand, in der Regel eine Zeile, ggf. auch bezogen auf die zu einem Absatz u. Ä. gehörenden Zeilen oder ein sonstige Zeilengruppe als Block. Die Einrückung oder der Einzug besteht in der Belassung eines Freiraums auf der linken Seite einer Zeile, sodass der Zeileninhalt entsprechend verschoben wird.

hc:RightIndent ( ›rechts eingerückt‹ ): Rechts eingerückter textueller visueller Gegenstand, in der Regel eine Zeile, ggf. auch bezogen auf die zu einem Absatz u. Ä. gehörenden Zeilen oder eine sonstige Zeilengruppe als Block. Die Einrückung oder der Einzug besteht in der Belassung eines Freiraums auf der rechten Seite einer Zeile, sodass der Zeileninhalt entsprechend verschoben wird.

hc:LeftOutdent ( ›links ausgerückt‹ ): Textueller visueller Gegenstand, der über den regulären linken Rand eines Inhaltsbereichs hinausragt, in der Regel eine Zeile in einem Textbereich.

hc:RightOutdent ( ›rechts ausgerückt‹ ): Textueller visueller Gegenstand, der über den regulären rechten Rand eines Inhaltsbereichs hinausragt, in der Regel eine Zeile in einem Textbereich oder ein Zeilensegment in einer Zeile.

Die Zuweisung der aufgeführten Typen zu einer Zeile oder einem Zeilensegment drückt nur aus, dass eine Einrückung oder Ausrückung vorliegt, nicht etwa wie groß diese ist. Für die genauere Erfassung der Ausdehnung einer Einrückung oder Ausrückung s. weiter unten (TODO).

vertikale Absetzung Zur Erfassung der vertikalen Absetzung bzw. von vertikalen Freiräumen oberhalb oder unterhalb einer Zeile können an <lb> mit dem Attribut @rendition diese Angaben gemacht werden:

hc:OffsetAbove ( ›mit Abstand nach oben; von oben abgesetzt‹ ): Visueller Gegenstand, in der Regel eine Zeile, ein Textblock (etwa einem Absatz als semantisch-logische Einheit entsprechend) oder seltener ein Layoutbereich, der mit einem Abstand nach oben erscheint bzw. von oben abgesetzt ist, sodass über dem Gegenstand ein gewisser vertikaler Freiraum erkennbar ist.

hc:OffsetBelow ( ›mit Abstand nach unten‹ ): Visueller Gegenstand, in der Regel eine Zeile, ein Textblock (etwa einem Absatz als semantisch-logische Einheit entsprechend) oder seltener ein Layoutbereich, der mit einem Abstand nach unten erscheint, sodass unter dem Gegenstand ein gewisser vertikaler Freiraum erkennbar ist.

Wie bei den zuvor beschriebenen einfachen Angaben für Einrückungen und Ausrückungen sind auch diese Mittel zur Angabe vertikaler Absetzung nur für einfache ›Pauschalangaben‹ bestimmt, also für Projekte und Fälle, in denen die Erfassung der Größe der Absetzung irrelevant ist. Für die genauere Erfassung der Ausdehnung vertikaler Absetzungen s. weiter unten (TODO).

Ausrichtung Des weiteren besteht häufig der Bedarf, bei Zeilen die Gesamtausrichtung ihrer Inhalte zu erfassen, also die Information, ob die Inhalte – normalerweise der textuelle Inhalt – der Zeile linksbündig, rechtsbündig oder zentriert erscheinen. Dafür kann an <lb> mit dem Attribut @rendition eine der folgenden drei Angaben gemacht werden:

hc:FlushLeft ( ›linksbündig‹ ): Visueller Gegenstand, typischerweise eine Zeile oder ggf. Tabellenzelle, dessen textueller Inhalt am linken Rand des Gegenstands ausgerichtet ist. Die Linksausrichtung wird normalerweise implizit angenommen.

hc:FlushRight ( ›rechtsbündig‹ ): Visueller Gegenstand, typischerweise eine Zeile oder ggf. Tabellenzelle, dessen textueller Inhalt am rechten Rand des Gegenstands ausgerichtet ist.

hc:Centered ( ›zentriert‹ ): Visueller Gegenstand, typischerweise eine Zeile oder ggf. Tabellenzelle, dessen textueller Inhalt horizontal mittig ausgerichtet ist.

Die Angaben › hc:FlushLeft ‹, › hc:FlushRight ‹ und › hc:Centered ‹ beziehen sich jeweils ›global‹ auf sämtliche Inhalte einer Zeile (bzw. anders betrachtet auf die ganze Zeile als Einheit).

Selbstausrichtung Wenn es erforderlich ist, die Ausrichtung zu Segmenten innerhalb einer Zeile anzugeben, etwa bei tabulatorbedingten Strukturen innerhalb einer Zeile oder bei Zeilenüberhängen (s. u.), können an <milestone ana="hc:LineSegmentBeginning"> mit @rendition die folgenden Angaben gemacht werden:

hc:SelfAlignmentLeft ( ›links ausgerichtet‹ ): Visueller Gegenstand, der in einem ihm übergeordneten visuellen Container (einem Layoutbereich oder einer Zeile) mit seinem linken Rand bündig mit dem linken Rand des Containers erscheint.

hc:SelfAlignmentRight ( ›rechts ausgerichtet‹ ): Visueller Gegenstand, der in einem ihm übergeordneten visuellen Container (einem Layoutbereich oder einer Zeile) mit seinem rechten Rand bündig mit dem rechten Rand des Containers erscheint.

hc:SelfAlignmentCentered ( ›mittig ausgerichtet‹ ): Visueller Gegenstand, der in einem ihm übergeordneten visuellen Container (einem Layoutbereich oder einer Zeile) mittig erscheint.

hc:SelfAlignmentRegularLeftMargin ( ›ausgerichtet am regulären linken Rand‹ ): Visueller Gegenstand – typischerweise ein Zeilensegment –, der links bündig mit dem regulären linken Rand des Inhaltsbereiches erscheint.

hc:SelfAlignmentRegularRightMargin ( ›ausgerichtet am regulären rechten Rand‹ ): Visueller Gegenstand – typischerweise ein Zeilensegment –, der rechts bündig mit dem regulären rechten Rand des Inhaltsbereiches erscheint.

TODOs: Beispiele für tabulatorähnliche Strukturen; Offset-Attribute für präzise Erfassung von Abständen; Verwendung des Elements <rendition> für die Bündelung von Layoutangaben an Zeilen und Zeilensegmenten.

Zeilensegmente beim Wechsel des Textstroms zwischen Textbereichen

TODO

Zeilenüberläufe und quer zu Zeilen verlaufende Textströme

Ein Zeilenüberlauf liegt vor, wenn der textuelle Inhalt, der ursprünglich für eine Zeile vorgesehen worden wäre, nicht vollständig auf diese Zeile passt, sodass der ›überschüssige‹ Text andernorts auf eine Weise untergebracht wird, die sich von einer regulären Fortsetzung des Textes auf der nächsten Zeile unterscheidet. Die Abweichung von einer regulären Fortsetzung lässt sich in der Regel mindestens daran erkennen, dass der fortgesetzte Text nicht am normalen visuellen Anfang der nächsten Zeile begonnen wird, wie es im Vergleich mit dem visuellen Kontext erwartbar wäre. Zeilenüberlauf kommt insbesondere dann vor, wenn Sinneinheiten wie Verse oder Listeneinträge normalerweise regelmäßig jeweils auf eigene Zeilen gesetzt werden, also wenn der Zeilenumbruch im Wesentlichen die Grenzen der Sinneinheiten nachbilden soll.

Die außerordentliche Unterbringung des überschüssigen Textes kann oberhalb und unterhalb einer regulären Zeile erfolgen, und zwar grundsätzlich (mindestens) auf viererlei Weise:

• Fortsetzung in einer regulär im Layout vorgesehenen nächsten freien Zeile, aber ausgerichtet am regulären Ende der Zeile (in diesem Fall handelt es sich immer um eine Zeile darunter)
• Fortsetzung in einer regulär im Layout vorgesehenen nächsten freien Zeile, in einem freigelassenen Abstand vom sonstigen regulären Zeilenbeginn (auch in diesem Fall handelt es sich immer um eine Zeile darunter)
• Fortsetzung in einer zwischen die regulär im Layout vorgesehenen Zeilen nachträglich eingeschobenen Zwischenzeile (oberhalb oder unterhalb)
• Fortsetzung in einem Segment einer regulär im Layout vorgesehenen Zeile (oberhalb oder unterhalb), die gleichzeitig weiterhin für ihren regulär vorgesehenen Inhalt in Anspruch genommen wird

Die nachfolgende Abbildung veranschaulicht zunächst einen Fall, bei dem nicht von einem Zeilenüberlauf die Rede sein kann, da die Fortsetzung des überschüssigen Textes trotz der etwaigen ursprünglichen Absicht, den Text in einer einzigen Zeile unterzubringen, dennoch regulär in der nächsten Zeile erfolgt:

Abb. 16: Kein Zeilenüberlauf.

Die folgende Abbildung verdeutlicht die Situation, in der überschüssiger Text in der nächsten regulären Zeile darunter fortgesetzt wird, aber rechtsbündig:

Abb. 17: Zeilenüberlauf rechtsbündig in der nächsten regulären Zeile.

Um den Zeilenüberlauf als solchen zu markieren, wird das <lb> der Zeile, die den überschüssigen Text aufnimmt, an @ana als › hc:RunOverBelow ‹ gekennzeichnet. Die rechtsbündige Ausrichtung des Zeileninhalts wird an @rendition mit › hc:FlushRight ‹ angegeben:

Grundsätzlich sind für die Kennzeichnung von Zeilenüberläufen diese beiden Typen vorgesehen, die mit dem Attribut @ana an <lb> und <milestone ana="hc:LineSegmentBeginning"> angegeben werden können:

hc:RunOverAbove ( ›Zeilenüberlauf oben‹ ):

hc:RunOverBelow ( ›Zeilenüberlauf unten‹ ):

Wenn in der nächsten regulären Zeile, die den überschüssigen Text als Zeilenüberlauf aufnimmt, der Zeilenüberlauf als solcher visuell durch eine Absetzung oder Einrückung kenntlich gemacht wird, verfährt man ähnlich wie im vorausgehenden Fall, nur wird am entsprechenden <lb> statt der rechtbündigen Ausrichtung die Einrückung angegeben:

Abb. 18: Zeilenüberlauf, markiert durch Einrückung in der nächsten regulären Zeile.

Wenn der Text des Zeilenüberlaufs zwischen den regulären Zeilen platziert wird, damit der folgende Textabschnitt auf der nächsten regulären Zeile fortgesetzt werden kann, gilt die zusätzliche Zeile zwischen den Zeilen ebenfalls als eine eigenständige Zeile, und zwar als Zeile des Typs › hc:InterlinearLine ‹. Bei dieser Zeile sollte durch das Attribut @n sichergestellt werden, dass sie richtig eingeordnet werden kann (vgl. oben Grundsätzliches zur Zeilenerfassung). Im Übrigen folgt die Kodierung aber den bereits erläuterten Prinzipien:

Abb. 19: Zeilenüberlauf in einer rechtsbündig ausgerichteten Interlinearzeile.

Schließlich kommt der Fall vor, dass der Zeilenüberlauf in einem Segment einer anderen, häufig der nächsten vorausgehenden oder nachfolgenden regulären Zeile untergebracht wird, ohne dass eine solche Zeile für den Zeilenüberlauf ganz freigegeben würde – vielmehr wird eine solche Zeile gemäß der regulär vorgesehenen Verteilung des Inhalts genutzt, bei bereits zuvor geschriebenen Zeilen darüber natürlich ohne Rücksicht auf das Zeilensegment mit dem Zeilenüberlauf, bei Zeilen darunter mit mehr oder weniger Rücksicht.

Grundsätzlich muss hierbei strikt das Prinzip beherzigt werden, dass die Textabfolge in der Arbeitskodierung (und der semantisch-logischen Kodierung) immer die sinnvoll zu lesende Textabfolge sein muss. Der Text wird also so erfasst, wie er zu lesen ist. Der visuelle Wechsel des Textstroms in Teile anderer Zeilen als der direkt zuvor mit einem <lb> begonnenen erfolgt mithilfe des oben unter Zeilensegmente eingeführten Zeilensegment-Konstrukts. Hierbei muss zwingend das Attribut @hei:belongsToLine benutzt werden, denn das Zeilensegment mit dem Zeilenüberlauf befindet sich in diesen Fällen immer in einer anderen Zeile als der, die mit dem nächsten vorausgehenden <lb> deklariert wurde.

Abb. 20: Zeilenüberlauf in einem Segment der folgenden regulären Zeile.

Wie aus dem vorausgehenden Code-Beispiel ersichtlich ist, wird in diesem Fall nicht ein <lb>, sondern das <milestone ana="hc:LineSegmentBeginning"> an @ana mit der Typangabe › hc:RunOverBelow ‹ gekennzeichnet. Der Grund dafür ist, dass in diesem Fall nicht eine Zeile als Ganzes, sondern ein Zeilensegment den Zeilenüberlauf darstellt.

Das Attribut @n an <milestone ana="hc:LineSegmentBeginning"> gibt die Nummer des Zeilensegments in der Zeile an, die den Zeilenüberlauf aufnimmt. Implizit versteht es sich, dass davor in der betroffenen Zeile ein Zeilensegment mit der Nummer 1 steht, dessen Anfang nicht explizit deklariert werden muss bzw. bereits durch das <lb> hinreichend markiert ist.¹⁶⁾

In der folgenden Abbildung sind die beiden Segmente von Zeile 2 des letzten Beispiels zur Verdeutlichung unterschiedlich eingefärbt und beschriftet:

Abb. 21: Zeilenüberlauf in einem Segment der folgenden regulären Zeile, mit eingefärbten Zeilensegmenten.

Im folgenden realen Beispiel befindet sich der Zeilenüberlauf in einem Zeilensegment zwei Zeilen höher. Das Beispiel veranschaulicht gleichzeitig den Umgang mit einem Zeilenüberlauf, dessen Anfang mitten in einem Wort liegt. Hierbei wird – wie auch sonst bei <lb> – das Attribut @break verwendet.

Abb. 22: Zeilenüberlauf in einem Zeilensegment zwei Zeilen höher (↪ Heidelberg, Universitätsbibliothek, Cod. Pal. germ. 367, fol. 3v).

In tokenisierter Variante und mit Erfassung von Metamarken ergibt sich beim selben Beispiel der folgende Code, in dem @break weggelassen wurde kann, da sich aus der expliziten Tokenisierung die Information ergibt, dass der Anfang des Zeilenüberlaufs mitten im Wort liegt:

Manchmal ist ein Zeilenüberlauf für die Unterbringung des überschüssigen Textes nicht ausreichend. Bei dem folgenden Beispiel liegt ein zweifacher Zeilenüberlauf in jeweils einem Segment von zwei Zeilen oberhalb der Zeile vor, in welcher der Text des ›überlaufenden‹ Verses anfängt. Übrigens setzt diese Handschrift Verse nicht regulär auf eigene Zeilen ab. Das Code-Beispiel ist tokenisiert.

Abb. 23: Doppelter Zeilenüberlauf (↪ Kassel, Universitätsbibliothek, Landesbibliothek und Murhardsche Bibliothek der Stadt Kassel, 2° Ms. philol. 28[3, fol. 1r).

Bezüglich der Leerzeichensetzung ist übrigens anzumerken, dass vor und nach einem <milestone ana="hc:LineSegmentBeginning"> ähnlich wie bei <lb> grundsätzlich keine Leerzeichen als signifikant gelten. Wo sinnvoll (an Wortgrenzen), werden für die Visualisierung in der Leseansicht visuelle Abstände maschinell erzeugt, sofern das gesetzte Attribut @break keine Zusammenschreibung nahelegt. Jeweils am Ende von V. 339 und 340 ist daher kein Leerzeichen (explizit mit <c>) zu setzen, da auf das Versende jeweils (aus Sicht der visuellen Anordnung, in diesem Fall nicht der Dokumentabfolge entsprechend) der Anfang eines Zeilensegments folgt (und nicht das Zeilenende). Am Ende von V. 341 ist hingegen ein explizit gesetztes Leerzeichen erforderlich, weil mitten in der Zeile zwei Verse aufeinandertreffen (s. dazu unten Mehrere semantisch-logische Blöcke in einer Zeile).

Oben wurde bereits an einem künstlichen Beispiel das Szenario veranschaulicht, in dem ein Zeilenüberlauf in eine eigene rechtsbündig ausgerichtete Zeile gesetzt wird. Das folgende Beispiel zeigt einen realen Fall:

Abb. 24: Zeilenüberlauf in der folgenden Zeile, die rechtsbündig ausgerichtet ist (↪ Nürnberg, Germanisches Nationalmuseum, Hs. 86 035, fol. 17r).

Im vorangehenden Beispiel wird › hc:FlushRight ‹ an <lb> angegeben, weil damit die Ausrichtung des gesamten Zeileninhalts bzw. der ganzen Zeile beschrieben werden soll. Wenn hingegen bei einem Zeilensegment dessen Ausrichtung angegeben werden soll, kommt (bei einer Ausrichtung am rechten Zeilenrand) › hc:SelfAlignmentRight ‹ zum Einsatz, wie oben unter Ausrichtung und Abstände beschrieben:

Abb. 25: Zeilenüberlauf in einem rechts ausgerichteten Segment der folgenden regulären Zeile (↪ Nürnberg, Germanisches Nationalmuseum, Hs. 86 035, fol. 17r).

Besonders in gotischen Handschriften gibt es zuweilen, typischerweise in Verbindung mit Überschriften, Fälle, in denen zwei Textströme quer zur eigentlichen Zeilenstruktur jeweils Teile derselben Zeilen für sich in Anspruch nehmen. Diese Phänomene scheinen etwas planmäßiger zu sein als spontane Zeilenüberläufe, die Abgrenzung mag aber im Einzelfall schwierig sein. Die Erfassung anhand des Zeilensegmentmechanismus ist identisch wie bei ›echten‹ Zeilenüberläufen, nach Ermessen des Herausgebers kann aber auf die Angabe von › hc:RunOverAbove ‹ bzw. › hc:RunOverBelow ‹ (und damit auf eine Bewertung als Zeilenüberlauf) verzichtet werden. Das folgende reale Beispiel veranschaulicht einen solchen Fall. Die Stelle befindet sich an der Grenze zweier Kapitel, wobei die Überschrift des neuen Kapitels neben dem letzten Verspaar des vorangegangenen Kapitels ›mitläuft‹:

Abb. 26: Textströme des Verstextes und der Überschrift quer zur Zeilenstruktur jeweils auf Zeilenteile verteilt (↪ Toruń, Universitätsbibliothek, Rps 54/III, fol. 8r).

Mehrere semantisch-logische Blöcke in einer Zeile

TODO