- 1 For an overview, see Pierazzo 2015, ch. 7.4 “Looking for New Models: the Critical Apparatus” (154–5 (...)
1Critical editions involve long, demanding and often lonely work. Whatever the school of textual criticism to which the editor belongs, the editorial work process involves a close examination of the various witnesses of the text in question, and their meticulous collation to record variants and errors for each relevant witness. The critical apparatus, which documents and supports the work produced by the editor, is the core of any critical edition and is what makes it a scholarly object. With the development of digital critical editions, a lot of attention has been devoted to the new possibilities offered by the digital medium to overcome the structuring but frustrating limits of the printed page.1
- 2 I am leaving aside here the rich field of automatic collation and computationally assisted stemmato (...)
2Yet very few tools have been designed to facilitate the work of the editor during the production phase, while the edition is still in the making.2 By its very nature, building a critical apparatus is a difficult and error-prone task, especially as the number of witnesses grows. As a scholarly editor of medieval texts, I especially wished to be aided in three areas:
Detection of human errors in the apparatus: it is quite easy for the editor to forget to record the reading of a manuscript for a particular locus, or to make a typo in the witness siglum while recording it, which will result in a loss of information. In a print edition, or even in a digital edition prepared with text-processing software, such errors are extremely difficult to spot and correct since they require a human reader to closely double-check every apparatus entry. The careful encoding of a critical edition, however, offers the possibility of automatic notification of such errors, among other advantages.
Displaying the work-in-progress edition: in the early stages of a critical edition, it is quite common to be undecided yet regarding the manuscript (if any) on which you are going to base your edition, so the possibility of easily displaying the different versions of the text according to various witnesses, and in different states, is quite helpful. Regular tools designed for the display of critical editions in their final stage can be helpful; however, a work-in-progress edition may have characteristics which make those tools difficult or impossible to use.
Using different styles of TEI encoding: even if an editor is planning to produce a text encoded with lemmata (<lem> elements), it is quite common to encode only “neutral” readings (<rdg> elements) while the work is still in progress, choosing which <rdg> element will become a <lem> only at a later stage, when all or enough witnesses have been collated and examined. An early-stage edition may therefore comprise apparatus entries containing either a lemma and one or more readings, or only readings – a state that can be confusing to some display tools.
3While looking for such aid in existing tools, I surveyed the most likely candidates.3 Three major TEI display tools have been evaluated using three criteria: their ability to detect human errors in the apparatus; their ability to display the text according to a particular manuscript; and their ability to display the critical text in a traditional fashion. I have not considered tools designed for the display of a single witness or documentary edition, since the needs of those types of edition are different.
4None of the tools provided automatic detection of errors, while the style of display offered differed:
The TEI Stylesheets4 offer a simple display for critical editions, but do not offer a way to display a single manuscript.
TEI Boilerplate,5 for all its other qualities, is not suitable for critical editions: it displays both lemma (if any) and readings one after the other, without giving any information on the witness where they appear.
- 6 Last modified January 21, 2016, http://v-machine.org
- 7 In a negative apparatus, the lemma does not have a @wit attribute, and each witness not appearing i (...)
The Versioning Machine6 does not display a critical text, but is especially designed to display a text in parallel versions according to its various witnesses. It suffers from a minor shortcoming, though: it only works with a positive apparatus, where even lemmata have a list of witnesses attached. If an edition is encoded with a negative apparatus,7 the witnesses whose siglum does not appear in an apparatus element are considered to bear no text at all at this place, instead of bearing the same text as the lemma for this entry.
5It goes without saying that since those tools are open source, they could of course be customized or modified to address the needs listed above. I have only considered off-the-shelf features, available to any scholar without programming skills or even advanced digital skills.
Figure 1. Comparative features of TEI XML display tools.
6After this survey, I started writing my own scripts in order to support my editorial work, as a set of separate tools. It quickly occurred to me that those scripts could easily be grouped together in a “toolbox” that, with a little bit of packaging, could be of help not only to me but to many other editors. By focusing on the processing and display of the critical apparatus, it was possible to find common features useful to most TEI critical editions, therefore going beyond a project-specific tool. I opted for a design that would be as user-friendly as possible, not requiring users to know any XSLT or CSS, nor even to download and configure anything.
7I chose to focus on editions encoded using the Parallel Segmentation method,8 since it seems by far the more widely used, especially by editors working with a traditional XML editor, and since the double end-point attachment method9 is difficult to implement when encoding “manually” without the help of a specially-designed tool.
8The next section describes the tool that I created.
9The TEI Critical Apparatus Toolbox is an online application for the quick and easy visualization and processing of TEI XML critical editions. It is not meant to be a publication tool: the Critical Apparatus Toolbox specifically targets the needs of editors during the preparation of their ongoing work, allowing them to perform quality controls on their TEI files and to display their work-in-progress text either in the style of a “traditional” critical edition, and/or in parallel versions corresponding to each witness.
10The requirements are very basic: no account, download, installation, or configuration is needed. The users are simply invited to upload the TEI XML file of a critical edition through a web browser. The only requirement is that this edition must be encoded using the Parallel Segmentation method. As long as this method is used, any style can be used in the file: positive or negative apparatus, use of <lem>, use of <rdg> only, or a mix of different styles – which is common in work-in-progress editions, when some lemmata have already been chosen while other apparatus entries still contain only readings, waiting for a choice by the editor.
11Tools designed to publish and display critical editions are usually very efficient for finished editions, but they may not be well adapted to ongoing work. Proposing a visualization for such encoding is not easy, because there might not be an identifiable critical text (yet), and the styles can be mixed in the apparatus. The Critical Apparatus Toolbox will display each style (lemma and reading[s], or readings only) differently:
In each case, the content of <lem> and <rdg> are highlighted, with a white background.
When an <app> element contains a <lem> and one or more <rdg>s, there is an easily identifiable critical text: only the content of the <lem> will be displayed in the text, and the readings will appear in a pop-up note. To see the note, the users simply need to click the upward-pointing arrow sign (↑) following the content of the lemma. Example:
Example 1. Encoding of an omission in a negative style of apparatus, in an edition considering six witnesses (P2, P3, P1, G, R2, and T).
<rdg wit="#G #P1 #T"/>
Figure 2. Displaying this code in the Critical Apparatus Toolbox.
Figure 3. Displaying this code: pop-up note after clicking on the ↑ sign.
When an <app> element has only <rdg> children, there is no identifiable critical text. It is therefore impossible for the application to decide which reading should be the critical text, and which other(s) should be variants only mentioned in a note. In this case, the content of each <rdg> is displayed, by order of appearance in the <app>. To make the text more readable, curly brackets open and close each series of <rdg>s belonging in the same <app> element. To make the presence of empty readings clearer, they are materialized with a minus sign (-), which was deemed more neutral in this case than using the notion of “omission.” Example:
Example 2. Encoding of the various readings in a positive style of apparatus, in an edition considering four witnesses (F, K1, K2, and V).
<rdg wit="#K1 #K2"/>
<rdg wit="#F #V">vel</rdg>
Figure 4. Displaying this code in the Critical Apparatus Toolbox.
The use of reading groups is also supported: the content of each <rdgGrp> element is displayed between bold double parentheses. If the <rdgGrp> contains a <lem>, its text is underlined. Example:
Example 3. Encoding groups of readings in a positive style of apparatus, in an edition considering four witnesses (F, K1, K2, and V).
Figure 5. Displaying this code in the Critical Apparatus Toolbox.
12This traditional critical edition view also offers the option to show or hide page breaks, if they have been encoded with the <pb> tag. If the user chooses to display all page breaks, the page or folio numbers appear in blue, between square brackets, and inline for better readability of the text (especially when the page breaks of multiple witnesses have been recorded). Alternatively, it is possible to display page breaks only for a particular witness (relying on the value of the @edRef attribute, which must refer to the siglum of the witness). In this case, it is assumed that the page breaks of this witness are of particular interest to the user, and they are displayed in a more prominent fashion, as blocks with a thin blue line representing each break.
13So far the Critical Apparatus Toolbox is not very different from other TEI display tools, except perhaps that it can handle a great variety of encoding styles within the Parallel Segmentation method. But its most distinctive feature is the ability to perform automated controls of the encoding.
14The preparation of a critical edition involves many sessions of meticulous proofreading, especially to check the accuracy of the apparatus. If the Critical Apparatus Toolbox cannot replace the careful eye of the editor, it offers an efficient way to control the consistency of the encoding by detecting small inevitable mistakes, like a typo in the list of sigla or the failure to record the reading of a particular witness in an apparatus entry.
15To perform those controls, the Critical Apparatus Toolbox will scan the <teiHeader> and <front> sections of the TEI file for a <listWit>, and find all the sigla of the witnesses. Then, it will compare this list to the manuscripts appearing in the @wit attribute of <lem> and <rdg> elements. The nature of the controls will depend on the type of apparatus used in the edition.
16In a positive apparatus, the reading of each witness considered for the edition is explicitly mentioned in each <app>: even lemmata have a @wit attribute, listing all the witnesses bearing this text. This type of apparatus may be more verbose, but it is a useful practice at least during the preparation of the edition (whether or not this will be the style used in the final version of the edition) because it forces the editor to be more accurate and makes verifications easier. It is the type of apparatus that allows for the most efficient consistency checks.
17The Critical Apparatus Toolbox can:
Highlight apparatus entries that do not use all witnesses: the content of the incomplete <app> elements which do not explicitly give a text for each witness listed in the <listWit> will be highlighted in red. Example:
Example 4. Encoding of readings in a positive style of apparatus, in an edition considering four witnesses (F, K1, K2, and V), offering no reading for V.
Nos quoque <app>
</app> ut servo
Figure 6. Displaying this code in the Critical Apparatus Toolbox.
Highlight apparatus entries that do not use a specific witness: in the previous feature, if any witness is missing, the entry will be highlighted. In some cases, for instance an incomplete collation for one of the witnesses, this could generate a great deal of unwanted information. With this function, the user can choose to highlight only the <app> elements that do not explicitly give a text for a specific witness that they select. Each witness is assigned a different highlight color (there are twenty different colors available).
Highlight apparatus entries where no witness at all is mentioned: not giving any @wit for a <lem> or <rdg> – or an empty @wit – may be a choice from the encoder, but it may also result from a mistake. With this function, the editor can easily map and control those entries.
Highlight apparatus entries where a witness is mentioned more than once: a careless mistake or a typo may cause the same witness to appear more than once in the @wit of the <lem> and <rdg> children of the same apparatus entry. This results in a confusing situation, where the application cannot determine which reading actually belongs in the witness, that must be corrected by the editor.
18It is worth noting that the application is capable of dealing with lacunae encoded with <lacunaStart> and <lacunaEnd>. When one of the witnesses is lacunary, the apparatus entries appearing between the <lacunaStart> and <lacunaEnd> tags marking up this lacuna will of course not give any reading for this witness, but the application will not consider that the lacunary witness is erroneously missing, and will not highlight those entries if the user checks incomplete <app> elements. Conversely, if an apparatus entry gives a text for this witness within the lacuna, the application will consider that the witness is mentioned more than once and highlight this entry accordingly.
19In a negative apparatus, only witnesses with a reading differing from the lemma are explicitly mentioned, the <lem> element usually having no @wit. Witnesses whose siglum does not appear in the @wit of a <rdg> are assumed to bear the same text as the lemma. This type of apparatus is slightly quicker to encode, since there is no need to list all witnesses, but on the other end it gives fewer opportunities for automated verification: it is impossible to be sure that the editor added the reading of each witness, since unmentioned manuscripts are assumed by default to correspond to the lemma.
20In this case, the Critical Apparatus Toolbox can nevertheless highlight apparatus entries that mention a particular witness. Practically, this will highlight only apparatus entries where a witness’s reading differs from the lemma. Example:
Example 5. Encoding a variant in a negative style of apparatus.
dolores corporis <app>
Figure 7. Displaying this code in the Critical Apparatus Toolbox, when highlighting all apparatus entries mentioning witness R2.
21The Critical Apparatus Toolbox can also highlight apparatus entries that contain a <lem>, or that contain only <rdg> elements.
22As an alternative to the traditional critical edition view, users can display their edition in parallel versions corresponding to the text. After uploading the TEI XML file, the user is asked to choose the sigla of the witnesses they want to see displayed, from a list automatically built from the <listWit> found in the document. The user also has the option to display the critical text alongside the text according to individual witnesses.
23The parallel versions view is available for a positive as well as a negative apparatus. In the case of a negative apparatus, the application will reconstruct the text of each witness by using the text of the lemma when a reading is not explicitly given for the witness.
24After submitting the choice of witnesses, the parallel versions will be displayed in columns. The look and feel of those parallel versions is similar to the traditional critical edition view, with the difference that for each apparatus entry, the text displayed is that of the current witness. The text of the lemma and of the other manuscripts is still presented, but only in an apparatus note.
25A color-code helps the user to situate each witness in relation to the critical text:
when the current witness has the same reading as the lemma, the text of the apparatus entry is highlighted in white;
when this witness has a different reading from the lemma, the text is highlighted in orange;
when there is no lemma for an apparatus entry, the text of the witness is highlighted in yellow;
when an apparatus entry does not give any intelligible reading for this witness, question marks highlighted in red are displayed. This means there is probably something wrong with the way this apparatus entry is encoded.
- 10 I have chosen to concentrate here on the presentation of the general framework, rather than getting (...)
- 11 This feature has been available since TEI P5 v. 2.9.0, released on October 9, 2015. See TEI P5 vers (...)
- 12 Magdalena Turska created this prototype as part of her work as an Experienced Researcher Fellow of (...)
- 13 Accessed December 4, 2016, http://www.digitalmanuscripts.eu
- 14 The first of these events took place at Queen Mary University London in June 2015, with the compute (...)
29The beginning of the development of the Critical Apparatus Toolbox was a lonely endeavor, but the project has since benefited from the collaboration of Magdalena Turska12 who wrote a prototype for the integration of the Toolbox into an oXygen framework. Decisive help was also found via a collaboration with the Erasmus SP+ DEMM program (Digital Edition of Medieval Manuscripts).13 For the three years beginning in June 2015 DEMM is holding an annual hackathon event where the Critical Apparatus Toolbox is the base application that small, mixed teams of textual scholars and computer scientists try to enhance to meet their particular needs.14 These events will play an important role in the future developments of the Toolbox, since they confront us directly with the real-life experience and needs of editors.
30During the first hackathon, the students and computer scientists were divided into four groups working on three themes: one worked on features linked to the representation of named entities, two others on various ways of representing the variance of an edited text (from various states of transcription showing either abbreviated or expanded words to parallel versions of a text with potentially different branches), and the last concentrated on the relationship between the edited text and images. These themes could serve as general directions for enhancing the Critical Apparatus Toolbox:
offering visualization options for named entities, from a simple index to more elaborate links to maps, when possible;
taking into account the visualization of transcription features like abbreviations/expanded words;
allowing the display of parallel branches of a tradition, beyond the mere display of parallel witnesses;
adding some options to link the text to its representation, or to images generally. This poses the problem of access to the images: in the current state of the Toolbox, users upload their TEI XML edition but not the other files potentially linked to it, like images.
32The printed page is one of the many possible outputs for a critical edition, even if it is only a scaled-down version of the proper digital edition. In many cases, a printed output is not only a desirable option, but a necessity: think, for instance, of the PhD students preparing a critical edition who have to turn in a printed version of their work. Many of them turn to LaTeX instead of TEI, therefore losing the benefits of semantic encoding just to be able to print their dissertation in the required fashion.
33It is of course extremely difficult, if not impossible, to propose a generic model for such diverse objects as TEI XML critical editions. Yet, a useful compromise can be found by concentrating only on the critical apparatus layout, and also by offering the user some simple interactive customization options (for instance, page size, page and line numbering, and content of the apparatus notes) to deliver as useful an output as possible.
- 17 The reledmac package, maintained by Maïeul Rouquette, replaces the established ledmac and eledmac p (...)
34I am preparing a generic TEI-to-LaTeX and TEI-to-PDF conversion feature that will be implemented in the Critical Apparatus Toolbox. I chose LaTeX as an intermediary format because it offers all the desired options, thanks to the reledmac package especially designed for typesetting critical editions.17 It is better suited to the specific needs of critical editions than XSL:FO. Another advantage of an intermediary file is that it leaves users the opportunity to edit the LaTeX code to obtain a better PDF result, which they might prefer over a modification of the XSLT templates, depending on their skillset.
35This feature, still a work-in-progress but well advanced, lets the user customize many parameters of the output through a graphical interface, without requiring any knowledge of LaTeX. When users need heavy customization of the default settings, they can easily override the templates transforming the TEI into LaTeX (although this requires some understanding of XSLT and LaTeX). The result of the transformation is a .zip file, containing a .tex file (which users can edit manually if they wish), the result of the transformation of this .tex file into PDF, and the log file of the transformation process. The end result should be a ready-to-print file following the state-of-the-art rules (such as various levels of footnotes, or references to lines). The following image is a sample page from a PDF file produced directly from a TEI critical edition using this TEI-to-Print feature.
Figure 8. From TEI to PDF: an example produced with the default settings.
The TEI-to-Print feature should be publicly available in early 2017.
36In a survey conducted in September-October 2010, respondents stated that the main obstacle they had to overcome was the lack of user-friendly tools (Burghart and Rehbein 2012). It seems that, a little more than five years after that survey, the general landscape of the TEI has evolved toward a better recognition of the importance of providing the users with tools that require as little technical knowledge as possible to let textual scholars reap the fruits of their encoding. One can hope that initiatives such as TEI Simple,18 which offers a TEI schema for a specific type of documents and needs, and the TEI Processing Model, will help integrate TEI encoding seamlessly into the workflow of textual scholars.19
37The Critical Apparatus Toolbox belongs in this growing galaxy of lightweight, user-oriented tools. With features demonstrating the immediate benefits of TEI encoding, it is a good tool for TEI training and workshops. But its main purpose remains to facilitate the work of textual scholars, a complex task given the widely diverse habits of different schools, and even of different people. Our first results demonstrate that despite the diversity, some level of common ground can be found to provide generic services.