Es ist eine Sache, nach einem Blick in die Transkriptionen und vor allem auch in die Bilder des Manuskriptes die »harmonischen« Gesetze für die Bildung der Glyphenfolgen in einem »Wort« zu erkennen. Eine solche Einsicht wirkt jedoch um einiges überzeugender, wenn man sie mit ein paar Zahlen belegen kann.

Um mich dieser Aufgabe zu widmen, habe ich ein Python-Skript geschrieben, dass meiner Voynich-Datenbank eine neue Tabelle hinzufügt. Das Skript für die harmonische Analyse der „Wörter“ im Manuskripte stelle ich hier wie üblich zum freien Download.

Nach der Anpassung der Zugangsdaten für die Datenbank und dem Start des Skriptes wird die neue Tabelle voy_harmony in der Datenbank erzeugt. Diese besteht nur aus zwei Spalten, nämlich

• harm_word INTEGER
  Die ID des Wortes, für das die Verstöße gegen die Harmonieregeln gezählt wurden
• harm_failcount INTEGER
  Die Anzahl der Verstöße gegen die harmonischen Regeln für dieses Wort

Das Skript zählt alle Verstöße gegen die harmonischen Regeln, außer, wenn sie in einigen Fällen die letzte Glyphe eines Wortes betreffen. Eine solche Zählung findet für jedes Wort statt, dass ausschließlich aus lesbaren Zeichen besteht. Jeder Weirdo wird – mit Ausnahme seines Auftretens an letzter Position im Wort – als Verstoß gegen die harmonischen Regeln gezählt.

Mit Hilfe dieser Tabelle lassen sich natürlich ausführliche Analysen machen. Um mich von der Gültigkeit der harmonischen Regeln für einen Großteil des Manuskriptes zu überzeugen, habe ich einmal eine kleine Zählung über alle Wörter aus allen Transkriptionen gemacht:

SELECT  COUNT(*) AS words,
        SUM(count) AS frequency,
        harm_failcount AS unharmonicals
FROM    voy_word
JOIN    voy_harmony ON word_id = harm_word
GROUP   BY unharmonicals;

Das Ergebnis dieser Zählung ist erstaunlich, zumal in diese Zählung auch alle »Wörter« derjenigen Seiten eingegangen sind, die eine besondere Häufung von Weirdos und ungewöhnlich geformten »Wörtern« zeigen.

+-------+-----------+---------------+
| words | frequency | unharmonicals |
+-------+-----------+---------------+
|  8384 |    111003 |             0 |
|  2329 |      7779 |             1 |
|   704 |      1836 |             2 |
|   116 |       194 |             3 |
|    14 |        15 |             4 |
|     1 |         1 |             5 |
+-------+-----------+---------------+
6 rows in set (0.91 sec)

Wenn man die verschieden geformten »Wörter« betrachtet, ohne ihre Häufigkeit in Rechnung zu stellen, denn sind 27,4 Prozent des gesamten »Wortschatzes« (der gewiss auch viele Fehler der Transkriptoren und der frühen Restauratoren enthält) »unharmonisch« geformt. Bezieht man jedoch die Häufigkeit dieser Wörter in Betracht, so erweisen sich nur 8,1 Prozent der »Wörter« des gesamten »Textes« im Manuskript als »unharmonisch«.

Die »harmonischen« Regeln erzwingen durch ihre starre Struktur eine recht hohe Redundanz des Textes. Die »unharmonischen« Wörter haben also einen höheren Gehalt an Information, sie tragen vielleicht auch eine (oder sogar: die) Bedeutung.

Was als nächster Schritt sehr interessant wäre, das wäre eine Analyse, ob die »unharmonischen« Wörter gehäuft an bestimmten Stellen des Manuskriptes (Position des »Wortes« in der Zeile, Position der Zeile auf der Seite, bestimmte Abschnitte im Manuskripte) auftreten, oder ob sich sich gleichmäßig über den gesamten Text verteilen. Eine solche Analyse werde ich in den nächsten Wochen einmal angehen.

So nützlich es auch ist, die Transkriptionen in einer relationalen Datenbank zu haben, so sehr wünscht man sich doch manchmal, dass diese als gewöhnlicher Text vorliegen. Um ein bequemes Extrahieren von Transkriptionen aus der Datenbank zu ermöglichen, habe ich noch ein kleines Python-Skript geschrieben. Dieses Skript steht hier zum freien Download, und wer sich immer mit diesem Manuskript plagt, der darf es gern benutzen oder für seine speziellen Bedürfnisse anpassen.

Download-Link: Ein Python-Skript zum Extrahieren von Transkriptionen aus der Datenbank

Wer das Skript benutzen will, muss die Zugangsdaten für seine Datenbank im Quelltext angeben. Dieser Teil des Quelltextes dürfte sich auch für jene selbst erklären, die sich mit Python sonst schwer tun. Deshalb habe ich keine andere Methode zur Konfiguration vorgesehen.

Die Verwendung ist relativ einfach. Es handelt sich um ein Skript für die Kommandozeile, mit Optionen kann gesteuert werden, welcher Anteil aus welcher Transkription extrahiert werden soll.

Übersicht über die Optionen

Bei allen Optionen muss die korrekte Groß-/Kleinschreibung beachtet werden.

-h
Ausgabe einer kurzen Hilfe zu den Optionen, die eine gute Gedächtnisstütze sein kann.

-O DATEINAME
Umleitung der Ausgabe in eine Datei. Das können allerdings auch fast alle Betriebssysteme.

-t TRANSCODE
Auswahl der gewünschten Transkription durch den ihr zugeordneten Code, der aus einem Buchstaben besteht. Wenn diese Angabe nicht gemacht wird, wird die Transkription von Takeshi Takahashi verwendet.

-H HANDCODE
Auswahl der Handschrift nach dem Schema von Currier. Definierte Codes sind 1, 2, 3, 4, 5, X und Y. Es können mehrere Codes angegeben werden, etwa 345. Wenn diese Angabe nicht gemacht wird, werden Seiten unabhängig von dieser Information extrahiert.

-l LANGCODE
Auswahl der Currier-Sprache. Definierte Codes sind A und B. Es kann auch AB angegeben werden, um nur jene Bereiche zu extrahieren, denen sich eine Currier-Sprache zuordnen lässt. Wenn diese Angabe nicht gemacht wird, werden Seiten unabhängig von dieser Information extrahiert.

-i ILLUCODE
Auswahl von Seiten nach ihrer Illustration. Definierte Codes sind T für reinen Text, H für Pflanzenkunde, A für astronomische Seiten, Z für den Tierkreis, B für biologische Seiten, C für Kosmologie, P für pharmazeutische Seiten und S für den abschließenden Teil. Auch hier können mehrere Codes angegeben werden. Wenn diese Angabe nicht gemacht wird, werden alle Seiten unabhängig von ihrer Illustration extrahiert.

-r BEREICH
Auswahl von Seiten nach ihrer Seitennummer. Die Bereiche können sehr flexibel angegeben werden, weitere Informationen weiter unten. Wenn diese Angabe nicht gemacht wird, dann wird aus dem gesamten Manuskript extrahiert.

-a ALPHABET
Auswahl eines Transkriptions-Alphabetes für die Ausgabe. Definiert sind EVA, Frogguy, FSG, Currier und Bennett. Wenn diese Angabe nicht gemacht wird, findet EVA Verwendung.

-T
Ausgabe aller definierten Transkriptionscodes mit Angaben zum Umfang der Transkription.

-v
Anzeige der Programmversion.

Zur Angabe von Seitenbereichen

In den Angaben der Seitenbereiche mit -r sind keine Leerzeichen gestattet.

Ein Seitenbereich kann eine Einzelseite sein, etwa f10r. Diese wird direkt angegeben.

Es kann sich um Seiten im Bereich von einer Startseite bis zu einer Endseite handeln. Dann werden die beiden Seiten durch einen Doppelpunkt getrennt. Um die Seiten von f20v bis f22r zu extrahieren, muss der Bereich f20v:f22r angegeben werden.

Es kann sich um Seiten vom Anfang bis zu einer bestimmten Seite handeln. Dann wird der Endseite ein Doppelpunkt vorangestellt. Um die Seiten bis f10r zu erhalten, muss der Bereich :f10r angegeben werden. Von von einer Seite beginned bis zum Ende des Manuskriptes zu extrahieren, wird der Doppelpunkt nachgestellt.

Das f zum Beginn der Seitennummer kann weggelassen werden. Statt f2r:f4r kann auch einfach 2r:4r geschrieben werden. Es ist im Kontext dieser Option immer klar, was gemeint ist, das »f« für »Folio« ist semantisch überflüssig.

Verschiedene Seitenbereiche können mit + kombiniert werden. Wer die Seiten von 1r bis 5v und von 30r bis 45v erhalten möchte, kann die Angabe 1r:5v+30r:45v machen. Überlappungen sind dabei kein Problem, es wird stets der größtmögliche Seitenbereich ausgewählt. Dieser kann durch die weiteren Optionen gefiltert werden.

Beispiele

Zunächst ein ganz einfaches Beispiel. Um die pflanzenkundlichen Seiten in der Currier-Sprache B zu erhalten, wird das folgende Kommando benutzt:

python voynich.py -i H -l B

Dieses Kommando kann etwas abgekürzt werden, indem die Leerzeichen zwischen den Optionen und ihren Parametern weggelassen werden.

python voynich.py -iH -lB

Mit der Angabe eines zusätzlichen Seitenbereiches können etwa nur die Seiten ab f48r erhalten werden.

python voynich.py -iH -lB -r48r:

Installation für die bequeme Anwendung

Wenn man dieses Skript häufiger verwendet, wird man es wohl über seinen normalen Suchpfad für Kommandos zugänglich machen. In Unix-artigen Systemen kann es direkt ausführbar gemacht werden und sollte auf Anhieb laufen, die beim Tippen etwas lästige Dateinamenserweiterung ».py« kann einfach entfernt werden.

Kurzlizenz

Jeder Mensch, der am Voynich-Manuskript forscht, darf mit diesem Skript machen, was er will. Wenn jemand nützliche Erweiterungen programmiert, wäre es nett, wenn diese erweiterte Version ebenso frei zur Verfügung gestellt würde.

Ich habe mir in den letzten Tagen das »Vergnügen« gegönnt, die Transkriptionen aus Jorge Stolfis Interlinear-Archiv in ein etwas anderes Format zu bringen. Das Ergebnis ist eine weit gehend normalisierte SQL-Datenbank, die des Wortzählers Herz erfreuen kann. Einen SQL-Dump dieser Datenbank stelle ich hier zum Download zur Verfügung.

Download-Link: SQL-Dump der Transkriptionsdatenbank

Wer sich die Datenbank anschaut, wird bemerken, dass sie nicht in der dritten Normalform steht. Einige Denormalisierungen habe ich eingefügt, um gewisse Analysen mit größerer Leichtigkeit und Performance ausführen zu können – zum Beispiel enthält jede Zeile die an sich überflüssige Angabe, aus wie vielen Wörtern sie besteht, damit ich Zeilen gleicher Wortlänge untersuchen kann, ohne einen Subselect verwenden zu müssen.

Um eine Verwendung dieser Datenbank mit »kleinen« Systemen wie mSQL zu vereinfachen, wurde auf explizite referenzielle Integrität verzichtet. Da sich dieser Datenbestand nicht verändert (im besten Fall kommt einmal eine neue Transkription hinzu), sollte dies kein Problem darstellen. Erstellt habe ich die Datenbank in MySQL, der Dump ist kompatibel zu ANSI-SQL und sollte so in jedem RDBMS verwendbar sein. Wer ebenfalls eine MySQL verwendet, wird wohl eher einen speziellen Dump für MySQL bevorzugen, auch dieser steht hier zum Download zur Verfügung.

Download-Link: SQL-Dump der Transkriptionsdatenbank für MySQL

Die gesamte Datenbank ist in englischer Sprache kommentiert. Die einzelnen »Wörter« sind in allen gängigen Transkriptionssystemen abgelegt, damit eine Anwendung nach jedem beliebigen System arbeiten kann. Natürlich wurden die anderen Systeme von einem Programm erzeugt, und ich kann nicht ausschließen, dass mir dabei ein Fehler unterlaufen ist, da ich selbst vorwiegend in EVA »lese« und analysiere, wenn ich mich nicht direkt mit Bildern des Manuskriptes beschäftige.

Die Datenbank enthält nur fünf Tabellen, die hier kurz in deutscher Sprache erläutert werden.

Tabelle voy_page

Informationen zu einer Seite.

• page_id INTEGER
  Primärschlüssel für die Seite
• fnumber VARCHAR(8)
  Alternativer Schlüssel, die »F-Number« der Seite ohne führendes »f«
• illustration_type CHAR(1)
  Angabe des Typs der Illustration, entweder »T«, »H«, »A«, »Z«, »B«, »C«, »P« oder »S«
  Dieses Feld ist für MySQL als ENUM definiert
• quire CHAR(1)
  Das Bündel, in dem die Seite liegt
• page_in_quire CHAR(1)
  Die Position, welche die Seite im Bündel einnimmt
• currier_lang CHAR(1)
  Angabe der Currier-Sprache, entweder »A« oder »B«
  Dieses Feld ist für MySQL als ENUM definiert
• currier_hand CHAR(1)
  Angabe der Handschrift nach Currier, entweder »1″, »2″, »3″, »4″, »5″, »X« oder »Y«
  Dieses Feld ist für MySQL als ENUM definiert
• has_non_voynich CHAR(1)
  Angabe, ob die Seite Text enthält, der nicht im Schriftsystem des Manuskriptes verfasst wurde, entweder »Y« oder »N«
  Dieses Feld ist für MySQL als ENUM definiert
• has_key_like CHAR(1)
  Angabe, ob schlüsselartige Texte auf der Seite stehen, entweder »Y« oder »N«
  Dieses Feld ist für MySQL als ENUM definiert
• has_extraneous CHAR(1)
  Angabe, ob die Seite zusätzliche Schrift enthält, entweder »Y« oder »N«
  Dieses Feld ist für MySQL als ENUM definiert
• description TEXT
  Aus den Kommentaren extrahierte Seitenbeschreibung

Tabelle voy_trans

Informationen zu einer Transkription.

• trans_code CHAR(1)
  Transkriptionscode aus dem Interlinear-Archiv
• second_code CHAR(1)
  Code für die zweite Lesart einer Transkription aus dem Interlinear-Archiv
• sortkey CHAR(2)
  Ein Sortierungsschlüssel, um die verschiedenen Transkriptionen in Anwendungen in nicht-alphabetischer Reihenfolge präsentieren zu können. (Bei mir stehen Currier und Takeshi Takahashi an den ersten Stellen, und das hat einen guten Grund. Takahashi ist vollständig, und Currier war recht gründlich.)
• name VARCHAR(64)
  Ein Anzeigename für die Transkription
• description TEXT
  Weitere Angaben zur Transkription

Tabelle voy_line

Eine Transkription besteht aus transkribierten Zeilen aus Seiten, diese werden hier zugeordnet.

• line_id INTEGER
  Primärschlüssel, wird aufsteigend vergeben und kann somit als Ordnungselement für die Reihenfolge der Zeilen dienen.
• line_trans INTEGER
  (Halber) Fremdschlüssel. Verweist auf voy_trans, entweder Feld trans_code oder Feld second_code
• line_page INTEGER
  Fremdschlüssel. Verweist auf voy_page, Feld page_id
• locator VARCHAR(20)
  Roh übernommener Angabe zur Zeile, enthält schwach dokumentierte Angaben zur scheinbaren textuellen Einheit, in der diese Zeile auftritt. In dieser ersten Version habe ich das noch nicht in eine sinnvolle Struktur übertragen.
• wordcount INTEGER
  Anzahl der Wörter in der transkribierten Zeile (wobei schwache Leerzeichen als Leerzeichen gezählt werden)

Tabelle voy_word

Die Wörter aus den Transkriptionen. Jedes eindeutig auftretende Wort ist in dieser Tabelle enthalten. Um die Verarbeitung zu vereinfachen, wurde jedes Wort in allen gängigen Transkriptionsalphabeten aufgenommen.

Darüber hinaus ist ein experimentelles Feature in diese Tabelle aufgenommen. Es existiert ein Feld fuzzy, das leicht verwechselbare oder ähnliche Glypen und Glyphenfolgen auf gleiche Zeichen abbildet, um eine bequeme Suche nach ähnlichen »Wörtern« zu ermöglichen. Dieses Verfahren habe ich mir innerhalb einer halben Stunde und nach eher flüchtigem Blick auf einige Bilder des Manuskriptes ausgedacht, es ist weit von einer brauchbaren Metrik für die Ähnlichkeit von Glyphen entfernt. Vielleicht findet es aber doch jemand anders von Nutzen, deshalb habe ich es in diese Veröffentlichung aufgenommen.

• word_id INTEGER
  Generischer Primärschlüssel für das Wort
• readable CHAR(1)
  Angabe, ob das Wort vollständig lesbar ist oder ein unlesbares Zeichen enthält, »Y« oder »N«
  Für die MySQL ist dieses Feld als ENUM definiert
• eva VARCHAR (40)
  Transkription in EVA
• frogguy VARCHAR(60)
  Transkription in Frogguy
• currier VARCHAR(40)
  Transkription im Verfahren von Currier
• fsg VARCHAR(40)
  Transkription im Verfahren der First Study Group
• bennett VARCHAR(40)
  Transkription in Verfahren von Bennett
• fuzzy VARCHAR(40)
  Experimentelle Bearbeitung, um »ähnliche Wörter« auf gleiche Zeichenfolgen abzubilden
• count INTEGER
  Insgesamte Häufigkeit dieses »Wortes« in allen Transkriptionen, dies kann nützlich sein, wenn seltene »Wörter« in einer Analyse besonders hervorgehoben werden sollen.

Tabelle voy_lineword

Die Wörter werden in einer Reihenfolge zu einer Zeile zugeordnet.

• lword_id INTEGER
  Generischer Primärschlüssel
• lword_line INTEGER
  Fremdschlüssel, verweist auf voy_line, Feld line_id
• lword_word INTEGER
  Fremdschlüssel, verweist auf voy_word, Feld word_id
• position INTEGER
  Position des Wortes in der Zeile
• spacing VARCHAR(6)
  Angabe, wie das Leerzeichen zum vorhergehenden Wort zu bewerten ist. Entweder »first«, wenn es das erste Wort in einer Einheit ist, oder »normal«, wenn es sich um eine sichere Leerstelle handelt, oder »weak«, wenn es eine schwache Leerstelle ist oder »big«, wenn das Wort durch eine Illustration oder einen anderen großen Zwischenraum vom vorhergehenden Wort getrennt ist.
  Dieses Feld ist in MySQL als ENUM definiert

Zur Motivation meines Hacks

Die Verwendung einer relationalen Datenbank ermöglicht es, Analysen in SQL durchzuführen und sogar darüber hinaus, die Ergebnisse mit Hilfe eines Reporting-Tools darzustellen – letzteres ist zwar nicht meine Welt, aber es ist eine Möglichkeit, schnell eine übersichtliche Darstellung eines Ergebnisses zu erzeugen. Vielen heutigen Programmierern geht SQL wesentlich leichter von der Hand als awk und sed aus dem Weg der tausend Tools (damit ist Unix gemeint). Ich hoffe, dass ich mit dieser Veröffentlichung auch solche Menschen zu eigenen Untersuchungen und Experimenten anrege, die bislang von den Formaten der Transkriptionen abgeschreckt wurden.

Natürlich ist es nun auch recht bequem, sich sinnvolle Views zu erzeugen, mit denen die Analyse dieser vielleicht nun etwas überstrukturierten Daten vereinfacht werden kann. Ich habe bewusst keine Views aufgenommen, da doch sehr vom Kontext einer Untersuchung abhängt, was man für sinnvoll erachtet.

Ein Beispiel für die Anwendung

Bei einer flüchtigen Unterschung stellt sich heraus, dass die durchschnittliche Länge des zweiten Wortes einer Zeile auffällig ist. Diese durchschnittliche Länge kann man zum Beispiel mit folgendem Statement aus der Transkription von Takeshi Takahashi ermitteln:

SELECT AVG(LENGTH(eva))
FROM voy_lineword
JOIN voy_word ON word_id = lword_word
JOIN voy_line ON line_id = lword_line
WHERE line_trans = 'H'
AND position =2

Mein hier verwendeter Pentium III mit 450 MHz brauchte zur Verarbeitung dieser Abfrage 1,4 Sekunden und lieferte eine durchschnittliche Wortlänge von 5,0011. (Es ist ein wirklich lahmer Computer, den ich hier benutze. Auf einer zeitgemäßen Maschine sollte so ein Ergebnis wesentlich schneller erscheinen.)

Diese Abfrage lässt sich nun sehr einfach so umformulieren, dass eine andere Transkription verwendet wird, ohne dass hierzu ein besonderes Programm in einer Unix-Pipe verwendet werden muss.

Und das ist keineswegs alles, denn es ist auch mit einer kleinen Änderung möglich, alle durchschnittlichen Wortlängen für alle Position zu ermitteln, ich nehme hier aber nur die ersten 19 Positionen auf, um diese Beschreibung nicht mit unnötigen, rohen Daten zu fluten:

SELECT position, AVG(LENGTH(eva))
FROM voy_lineword
JOIN voy_word ON word_id = lword_word
JOIN voy_line ON line_id = lword_line
WHERE line_trans = 'H'
GROUP BY position
HAVING position < 20

Nachdem sich mein armer Computer 4,15 Sekunden von dieser Eingabe erholen musste, erfreute er mich mit dem folgenden Ergebnis (hier als rohe Ausgabe des MySQL-Monitors wiedergegeben):

+----------+------------------+
| position | avg(length(eva)) |
+----------+------------------+
|        1 |           5.4888 |
|        2 |           5.0011 |
|        3 |           5.1632 |
|        4 |           5.1163 |
|        5 |           5.0970 |
|        6 |           5.0959 |
|        7 |           5.0594 |
|        8 |           5.0211 |
|        9 |           4.8615 |
|       10 |           4.6762 |
|       11 |           4.4971 |
|       12 |           4.2664 |
|       13 |           4.2667 |
|       14 |           4.5282 |
|       15 |           5.0309 |
|       16 |           5.1548 |
|       17 |           5.0959 |
|       18 |           5.0286 |
|       19 |           4.9851 |
+----------+------------------+

Eine geplante Beispielanwendung

Ich werde wohl in den nächsten Wochen eine Beispielanwendung für diese Datenbank veröffentlichen. Es handelt sich um ein in Python geschriebenes CGI-Skript, das neben der bequemen Durchsicht der Transkription auch mit erweiterten Möglichkeiten wie einer Konkordanz und einer guten Suchfunktion dienen kann. Natürlich wird es auch über weit gehende Möglichkeiten zum Export von Transkriptionen oder Teilen daraus verfügen. Dass man so etwas nicht eben in einer Viertelstunde »runterhackt«, sollte einleuchten.

Wenn sich das etwas länger als ein »paar« Wochen hinzieht, bitte ich schon einmal um Entschuldigung.

Ich würde jedem Menschen, der sich für das Voynich-Manuskript zu interessieren beginnt die gleiche Empfehlung geben: Noch bevor man sich technisch damit beschäftigt, noch bevor man Transkriptionen auseinander nimmt, sollte man dieses Manuskript optisch auf sich wirken lassen, sollte man es sich anschauen.

Wer nicht gerade seinen Urlaub im kühlen Yale verbringt, ist dabei auf Bilder angewiesen. Zum Glück stellt die Beinecke-Bibliothek ausgezeichnetetes Bildmaterial im Internet zur Verfügung, aber es ist dort vorsätzlich schwierig gemacht worden, diese Bilder herunterzuladen. Wer sich für persönliche Analysen (zum Beispiel mit einer Software zur Bildbearbeitung) eine lokale Kopie dieses Materiales beschaffen will, kann dies nur über leidige Handarbeit tun, indem er die Bilder jeweils einzeln anzeigen lässt und auf seiner Platte speichert. Das ist ausgesprochen unbefriedigend, es handelt sich um eine Arbeit, die eigentlich der Computer tun sollte.

Deshalb habe ich mir die Mühe gemacht, einmal sämtliche URLs der Bilder mit einem kleinen Programm zu extrahieren, damit dieses Bildmaterial mit Hilfe eines Download-Managers heruntergeladen werden kann. Das Ergebnis dieser Mühen stelle ich hier zum freien Download.

Download-Link: Listen der Internet-Adressen aller Bilder des Voynich-Manuskriptes auf dem Server der Beinecke-Bibliothek

In dem Archiv befinden sich drei Dateien, mit denen man jeweils eine andere Aufbereitung des Bildmateriales erhalten kann.

1. small.txt
   Dies sind relativ kleine Grafiken, die zwar einen groben optischen Eindruck des Erscheinungsbildes geben, aber nicht für richtige Analysen geeignet sind. Der Download ist relativ schnell, da die Einzelbilder eine Größe von jeweils ca. 60 KB haben.
2. large.txt
   Dies sind größere Grafiken, die schon einen zutreffenden Eindruck vom Aussehen des Manuskriptes geben. Für erste Analysen können diese Bilder völlig ausreichend sein.
3. hires.txt
   Dies sind die hochauflösenden Grafiken im MrSid-Format. Diese Bilder sind von einer unglaublich guten Qualität, es lässt sich jede einzelne Pore im Pergament erkennen. Wer sich ernsthaft davon überzeugen möchte, dass das Manuskript mehrfach restauriert wurde oder wer stark verblichene Details mit Hilfe einer Bildbearbeitung sichtbar machen möchte, hat eigentlich keine andere Wahl als diesen Download.

Zur Verwendung

Die meisten Download-Manager bieten die Möglichkeit, eine Liste von URLs anzugeben – wie dies im Einzelnen geschieht, ist leider von Programm zu Programm verschieden. Ich benutze GNU Wget für solche Aufgaben. Wenn ich etwa die Bilder aus der Datei large.txt herunterladen und im Verzeichnis large ablegen will, benötige ich dafür nur den folgenden, recht übersichtlichen Aufruf:

wget -i large.txt -P large

Alles weitere geschieht von allein, während ich mich anderen Aufgaben zuwenden kann. So sollen Computer sein! (Leider sind sie nicht immer so.)

Wichtiger Hinweis

Bei den Bildern handelt es sich natürlich um urheberrechtlich geschütztes Material. Das ist auch der Grund, weshalb die Beinecke-Bibliothek den Download künstlich erschwert hat. Ich bitte darum, dass dieses Material nur zu persönlichen Zwecken und für gewisse Analysen, aber niemals für eine Zweitveröffentlichung im Internet verwendet wird. So etwas wäre einfach ein unfreundlicher, antisozialer Zug gegenüber einer Institution, die uns allen solches Material zur Verfügung gestellt hat.