Intellectual and practical scope

Regardless of their purpose and method, scholars preparing critical editions (whether “Lachmannian”, “Bedierist” or focused on the study of textual tradition) often have to register, summarize and account for textual variations across several manuscripts and citations. To date, two approaches have been prevalent. The first one involves entering variations in a collation table, either in a notebook or a spreadsheet, and manually redacting the critical text and the critical apparatuses with a word processor or in a TeX file. The second approach involves using specialized softwareAmong others: TUSTEP (Universität Tübingen 1966–2020), Classical Text Editor (CTE, Hagel 1997–2021) and ChrysoCollate (Moureau 2021). that provides a unified interface and various auxiliary tools in order to support the editing process from transcribing to exporting the definitive files.

Such all-in-one applications have undeniable advantages. However, apart from TUSTEP (Universität Tübingen 1966–2020), which includes a general-purpose text editor and a full scripting language,See Christian Griesinger’s review in RIDE 11. most applications comprise a predefined set of features that the user can hardly extend and that complicate exchanging data with other software — at best, users can export their work for further processing with another software, whose output cannot be reimported and reworked without losing information.CTE works around this limitation by letting the user insert arbitrary TEI-XML tags in the text. However, to be exportable to TEI-XML, the apparatus has to be redacted in a machine-readable way, which is generally incompatible with the requirements of a print edition: for instance, following the manual, expressions indicating nested variant locations such as deus dixit] dominus (christus B) dicit ABC will not be recognized. The practical consequence is that users must choose between print and TEI output. For instance, Pinche (2021) relies on the annotation of places, personal names and punctuation marks in the edited text in a detailed and structured way. Other examples involve linguistic tagging or describing the shape of letters and abbreviations. This limitation requires performing such tasks after establishing the critical text, which is not always optimal. A workflow based on a TEI-XML encoded file (as described in Andrews 2009, 34–74) is highly suited to addressing such needs.

When using the TEI (Text Encoding Initiative) encoding standard (TEI Consortium 2021)Especially the modules devoted to the manuscript description, the representation of primary sources and the critical apparatus., which addresses a wide range of needs and provides extension and specialization mechanisms, scholars are virtually unlimited in determining the data structure of their edition file. This is the case because XML-TEI files only contain structured information. As such, they are not meant to be consulted directly by readers but processed by an external programme to produce, for instance, word processor files (to be sent to a publisher), electronic editions (displayed in a web browser), or even work files (e. g. tables containing all variant readings). XSLT (Kay 2017), a language designed to perform transformations on XML files with the help of stylesheets, is often used to that end (for an example, see Vaughan 2021). Separating the recording of variants and the redaction of apparatus entries, which is delegated to further processing (in contrast, notably, to CTE, Hagel 1997–2021), also ensures a homogeneous syntax in the critical apparatus (see code example 1) and permits its adaptation to the publisher’s requirements by modifying the transformation stylesheet. On the one hand, this requires time and programming skills, but on the other it enables recording a lot of information in a single XML file, only part of which will be used and preserved in every output.

<TEI xmlns="http://www.tei-c.org/ns/1.0"><teiHeader> [...] <bibl source="https://www.augustinus.it/latino/cdd/cdd_17.htm"/> [...]</teiHeader> <text> [...] <body> <p xml:lang="la">Et quia in prophetia vox eius agnoscitur: <seg xml:id="cit1">Non <app> <lem wit="#A" cert="high">derelinques</lem> <rdg wit="#B #C" type="grammatical">derelinquas</rdg> </app> animam meam in inferno</seg>, <seg xml:id="cit2"><app> <lem wit="#A #C" cert="high">eumdem</lem> <rdg wit="#B" cause="haplography">eum</rdg> </app> deduxit ad inferos et reduxit</seg>.</p> </body> <standOff type="references"> <spanGrp type="biblicalReferences"> <span target="#cit1"> <ref type="literal" cRef="Ps 15:10"/> <ref type="allusive" cRef="Ac 2:27"/> </span> <span target="#cit2"> <ref type="allusive" cRef="Ac 2:31"/> </span> </spanGrp> </standOff> </text></TEI> Edition file with some annotations and the identification of biblical references. Note that the references have been separated from the edited text to avoid overloading.

However, while users might appreciate being able to write custom programmes to address specific needs, they benefit from performing common tasks with existing general-purpose tools. Unfortunately, few applications are directed towards critical editing based on XML-TEI and mostly provide interfaces for visualizing achieved editions.The most prominent ones are Edition Visualization Technology (EVT) and the Versioning Machine (Schreibman et al. 2016). TEI Publisher (2016–2021) has a broader scope. What distinguishes the TEI-CAT is that it provides a set of tools for work in progress. Moreover, contrary to publication software, the two main tools in this toolbox deal almost exclusively with textual variation, which most editors will likely encode in the same way,Only parallel segmentation is supported for linking the critical text with the variations. However, the other methods provided by the TEI are less broadly used. and simply ignore more project-specific features. Overall, then, the TEI-CAT truly contributes to developing common tools for common tasks.

Development of the TEI-CAT tools

The TEI-CAT (originally called TEI Critical Edition Toolbox) was opened for testing in June 2014. https://web.archive.org/web/20210816160022/https://tei-c.org/2014/06/10/tei-critical-edition-toolbox/ It has been programmed almost entirely by Marjorie Burghart, a medieval Latin philologist, who felt that the existing tools for interacting with XML-TEI editions lacked either sufficient support for the TEI “Critical Apparatus” module or features required to work on ongoing projects (e. g. automatic error detection). To overcome this shortcoming, Burghart decided to make available the scripts that she had written for herself (Burghart 2019). This initiative has been part of her broader commitment to making XML-TEI based solutions for critical editing more widely known and accessible. As a member of the TEI Consortium’s Critical Apparatus Workgroup, she has also contributed to improving standards. She has also helped create an online course and a free ebook on encoding critical editions with the TEI (Burghart, Cummings, and Pierazzo 2017).

Originally, the TEI-CAT consisted of two interfaces, which still exist today. Besides conforming to XML and TEI specifications, Check your encoding also helps screen apparatus entries for e. g. the absence of a required witness or the mention of two readings for the same witness. Display parallel versions exhibits the critical text and the texts of selected witnesses, thus facilitating the verification of collation against every manuscript and the examination of variants. Both interfaces insert anchors in the displayed text that make the individual apparatus entries accessible. What follows refers to these interfaces as the core tools of the TEI-CAT, not only because they were released first, but also because they match the needs of all editors using TEI.

The TEI-CAT has benefited from scholars and students collaborating on its development during two hackathons and a training week in 2015 and 2016. Some new features have been worked on at that time (Burghart 2019). Whereas these have never been released, Burghart has published three additional tools. (1) A tool for generating TEI <zone> elements from an image was added in 2017, designed by Chris Sparks (Sparks 2017). Two others followed in 2018: (2) an interface for generating a traditional print edition from an XML-TEI file; (3) a tool for displaying statistics about the XML elements used. In September 2021, a new version of Annotate an image was released (Sparks and Vaňková 2017–2019). As this timeline suggests, and as Burghart has confirmed, project changes result mainly from user suggestions, contributions and requests.

Architecture and infrastructure

Processing of an XML-TEI file by the TEI-CAT (core tools)

Processing of an XML-TEI or an image file by the TEI-CAT (additional tools)

Generally speaking (see fig. 1 and fig. 2), the XML-TEI file uploaded by the user is processed by an XSLT processor using the appropriate stylesheets. The generated HTML files are rendered by the browser with the help of the CSS and JavaScript files retrieved from the server. However, two tools depart from this path to some extent. Relying exclusively on a JavaScript program called TEI Zoner, Annotate an image does not involve any server-side processing: the programme is executed directly in the user’s web browser. As for Print an edition, the XSLT processor generates a TeX file, taking into account user options. This TeX file is then processed on the server by a LaTeX engine, which outputs a PDF and a log file. Finally, all three files are bundled into a ZIP archive, which is shipped to the user. The choice of LaTeX is motivated by the fact that, being based on TeX, it produces PDF files of very good typographic quality. It can also be used together with reledmac, a package specifically designed for printing critical editions (Rouquette 2011–2021; reviewed in Dunning 2020, who also provides a general introduction to LaTeX).The ekdosis package has since been released (Alessi 2020–2021). Finally, it enables the user to manually adjust the automatically generated TeX file and to process it with a local LaTeX installation.

Usually, all tools return their output after some seconds. They can even handle rather long and complex editions,Such as this file. provided that not too many witnesses are selected at a time. The printing tool may take longer, depending on the time needed by LaTeX to compile the PDF file.

Methodology

Given that the core tools share a similar interface and common features (e. g. the generation of the critical text), I review them together. To that end, I have used the test file provided by Marjorie Burghart,Available at http://teicat.huma-num.fr/pseudo-edition-test-file.xml. A copy of the version available at the time of writing is included in the ZIP folder mentioned below. which documents part of the behaviour of the core tools. However, being a sample file rather than a comprehensive test input, it does not address some usual textual phenomena (e. g. blank spaces, duplication of words, transposition of whole segments). The same could be said of a handful of frequent encoding features such as the presence of XML elements (e. g. <abbr>) in a <lem> element. To supplement it, I have written a set of additional tests.

All the test files, along with a list of the tested features and the detailed results, can be retrieved from Zenodo. I am very grateful to Marjorie Burghart, to whom I sent this folder, for kindly pointing out some errors in my test files. Please note that, as the result of possible work on TEI-CAT, the situation described below may change in the near future. For each set of tools, I first comment on the interface and then synthesize the outcome of my tests.

Core tools: Checking and visualizing ongoing editions

The interface is simple, intuitive and well-described on the help page. The user uploads the XML-TEI file. Then, in Display parallel versions, he or she selects the texts to be compared (the critical text and/or one or more witnesses). Texts are displayed side by side (see fig. 3). Every variation is marked by an anchor, which can be clicked to display the corresponding apparatus entry. Editorial notes (in <note> elements) are rendered as well. In the witness text, passages containing variant readings are highlighted in different colours according to the relationship between the displayed text and the lemma.

Hence, Display parallel versions addresses the needs of any editor working with several manuscripts. Indeed, it is easier to check transcription accuracy from a continuous text than from the XML-TEI file or even from a collation table. Variant highlighting provides a general idea of the differences between manuscripts before studying them in greater detail and helps study their peculiarities.

In Check your encoding, only the critical text appears, exactly as in Display parallel versions. The user can dynamically select which encoding anomalies or broader features should be highlighted. Especially appreciated is the ability to highlight those apparatus entries in which some witnesses are missing or recorded twice: these anomalies appear quite frequently, often due to a siglum having been mistyped. Other most common mistakes are tracked too, such as forgetting to define the critical text in a variant location.

Parallel display with an apparatus entry showing up.

Some verses of poetry in the parallel view.

Text of a witness in light and dark mode (using Advanced Night Mode add-on in Pale Moon).

Some small but significant improvements could be made to the interface, which is otherwise rather appealing and readable. Texts are not aligned in parallel display (see fig. 3 shows). The interface could be made a little more interactive, especially by enabling the user to change column width (fig. 4 illustrates why). The white background used to highlight those places where the displayed text is identical with the lemma becomes invisible when dark mode is activated (see fig. 5): replacing it with a lightly coloured background would resolve the issue.

The interface could provide additional information. For instance, according to the help page, “in the toolbox, you will have the option of showing or hiding the page breaks, either all of them, or for a particular witness.” However, the required checkboxes only appear in Check your encoding. In Display parallel versions, page breaks in manuscripts are currently recorded in the HTML file produced by the TEI-CAT as spans with class .msPb but are not displayed. Furthermore, the <said> element, which delimits direct or reported speech, is currently not supported. Since identifying such passages often relies on the editor’s interpretation, highlighting them at least in the critical text would help review the choices that have been made in these respects.

How the TEI-CAT core tools handle a missing witness in a given variant location.

As advertised, the core tools effectively support either positive or negative apparatus entries: fig. 6 illustrates what kind of heuristics the stylesheet uses to handle ambiguous cases. However, it would seem more logical to determine the convention followed at the file level rather than for every apparatus entry. In files encoded with a positive apparatus, this would permit highlighting passages where the critical text is not attested in any manuscript and thus results from the editor’s reconstruction. However, Check your encoding partly offsets this shortcoming by highlighting those variant locations where the readings of selected witnesses are missing.

Regarding the recognition of textual features, only two cases documented in the sample file provided by the author are poorly handled. Variants inside a group (<rdgGrp> element) are marked as illegible in the corresponding witness texts. When a given witness is attributed to both the lemma and a variant reading in the same passage, its text in parallel display reproduces that of the lemma instead of indicating an error.

Conversely, the core tools fail the majority of the supplementary tests. This comes as no surprise, since these tests mostly concern features not stated as supported by the documentation, namely, the help page and Burghart’s test file. Supported undocumented features include the correct display of right-to-left alphabets, XML elements inside a <lem>, additions, transposed text segments (although the apparatus yields strange results), scribal abbreviations in the lemma or outside a variant location. Unsupported or buggy features include the indication of blank spaces, duplication of expressions or, among possible mistakes, the use of a witness in contexts where this should remain unmentioned (e. g. in a lacuna). However, these shortcomings do not prevent using these tools, since at least the displayed text is generally correct or understandable.

Additional tools: Annotating an image and generating a traditional PDF edition

The basic version of Annotate an image lets the user swiftly and easily draw zones on an image and export their coordinates in TEI format. However, it always displays the image in full size, which can be problematic with high-quality reproductions. Nor can the zone be adjusted once drawn. The basic version has been superseded by the new version, which enables scaling images, as well as moving and deleting zones individually. The added features allow categorizing and annotating zones. The help message is very clear and comprehensive. Although I have not used this tool in real projects, it would seem very helpful for those wishing to include annotations linked to manuscript images in their XML-TEI file (e. g. to publish an electronic edition displaying interactive images alongside the text).

At first sight, Print an edition looks very attractive. Besides relieving editors of the burden of programming a very complex XSLT stylesheet, the TEI-to-LaTeX transformation provides numerous options for page layout, the formatting of the critical apparatus, the indices, etc. It supports a two-level apparatus containing variant readings and sources. Taken together, the sample file and the indications in the customization interface provide much information about the supported encoding. Those needing further customization can download and modify the XSLT stylesheet (used to process the XML file). This, of course, requires understanding both XSLT and LaTeX, especially reledmac.

However, it supports neither variant locations nested in variant readings nor explicitly encoded duplications nor transposed spans of text (i. e. neither iter. nor transp. can be generated in the critical apparatus: the entire contents of each reading is written out instead). Besides, very long chunks of complicated and sometimes duplicated code make the default XSLT stylesheet difficult to read and modify. Nevertheless, users dissatisfied with the output can use the generated LaTeX file as a basis and modify it by hand. Even those who wish to implement their own stylesheets may benefit from studying Burghart’s sheet.

Although perhaps beyond the scope of a single-person project, Print an edition might serve to more broadly reflect on how to most practically express traditional paper-based editions in form of an XML-TEI model, ideally embodied in a constraining RNG schema. A consensual, well-designed set of conventions with explicit theoretical, albeit traditional foundations, would be suitable for many projects, and would prevent their authors from reinventing the wheel. Such a specification could also be appropriated by other editing and publishing software in the field of textual criticism providing XML-TEI output (Pierazzo 2019; this approach is exemplified by Camps 2016).

Admittedly, programming a more feature-rich and yet reliable set of stylesheets would be a fairly complex and difficult endeavour. However, some design decisions could make this somewhat easier. First, a comprehensive test suite would permit tracking the progress made in supporting the designed model and ensure that no modification introduces bugs. Secondly, the respective responsibilities of the XSLT stylesheet and of LaTeX macros could be better defined. Currently, for a PDF output similar to fig. 7, XSLT generates the type of code as shown in example 2, which mixes structural commands (e. g. \edtext or \pstart ... \pend) and formatting instructions (e. g. \vspace).

\pstart Libero justo laoreet sit amet. In \edtext{pellentesque}{\lemma{pellentesque} \Afootnote{pellemque \emph{T}, pelles\emph{P}}} massa placerat duis.\pend \vspace{0.1cm}\pstart Vel elit scelerisque mauris pellentesque pulvinarpellentesque habitant. Velit egestas dui id ornare arcu odiout sem. \edtext{Venenatis urna cursus eget nunc scelerisqueviverra. Eu volutpat odio facilisis mauris sit amet massavitae.}{\lemma{}\Bfootnote[nosep]{Augustin, \emph{En. in Ps.},37, 3 (PL 36, 397; CCSL, 38, 384)}}\pend \vspace{0.1cm} Sample LaTeX code generated by tei2latex (slightly modified).Paragraphs are surrounded by \pstart and \pend. The critical text in variant locations constitutes the first argument of \edtext. The second argument is composed of the lemma, followed by the literal text of the apparatus entry (\Afootnote). \vspace introduces a gap before the next paragraph. \Bfootnote contains an entry in the apparatus fontium.

This could be made more manageable by using high-level structural commands (see code example 3):The code examples are merely illustrative.

\edparagraph{Libero justo laoreet sit amet. In\variantLocation{pellentesque}{}{\variant{pellemque}{T}\variant{pelles}{P}} massa placerat duis.}\edparagraph{Vel elit scelerisque mauris pellentesque pulvinarpellentesque habitant. Velit egestas dui id ornare arcu odiout sem. \citing{Venenatis urna cursus eget nunc scelerisqueviverra. Eu volutpat odio facilisis mauris sit amet massavitae.}{\reference{Augustin, \emph{En. in Ps.}, 37, 3 (PL 36,397; CCSL, 38, 384)}}} Rewriting code as shown in example 2 so that it focuses on structural units.Paragraphs are now set as arguments of \edparagraph, whose definition in Code example 4 includes both the \pstart ... \pend pair and \vspace. The apparatuses are more clearly distinguished by the use of \variantLocation and \citing. Instead of formatting the critical apparatus directly, the variants are indicated by \variant, which takes the variant reading and the list of the corresponding witnesses as arguments. Italics and commas are defined in Code example 4. Note that, in this example, the second argument of \variantLocation is empty: Code example 4 shows that it needs to be set only if the lemma in the apparatus differs from the main text.

These commands could be defined in a separate package file as shown in example 4.

\usepackage{reledmac}\usepackage{etoolbox}\newcommand{\edparagraph}[1]{\pstart #1 \pend\vspace{0.1cm}}\newif\ifExistsPrecedingVariation\newif\ifExistsPrecedingRef\newcommand{\variantLocation}[3]{% \ExistsPrecedingVariationfalse \edtext{#1}{% \lemma{% \ifstrequal{#2}{}{#1}{#2}% }% \Afootnote{#3}% }%}\newcommand{\variant}[2]{% \ifExistsPrecedingVariation{, }\fi #1 \emph{#2}% \ExistsPrecedingVariationtrue%}\newcommand{\citing}[2]{% \ExistsPrecedingReffalse \edtext{#1}{% \lemma{}% \Bfootnote[nosep]{#2}% }%}\newcommand{\reference}[1]{% \ifExistsPrecedingRef{, }\fi% #1% \ExistsPrecedingReftrue%} Definition of the commands used in Code 3.The new commands used in Code example 3 are translated into their reledmac equivalents, albeit with some tweaks: for instance, in each critical apparatus entry, a comma and a space are inserted before all variant readings but the first. Using this kind of definition guarantees that all apparatus entries are formatted according to the same rules, which can then be modified uniformly.

Conceivably, such a LaTeX package could provide some customization options. These could be set in a file generated by the XSLT processor and imported by the main LaTeX file. This would make the XSLT stylesheet more manageable, since it would have to deal only with structure, not with formatting. Later, this would also make it easier to introduce support for ekdosis (Alessi 2020–2021). On the XSLT side, this would only require some additions, to reflect new features, with most of the implementation being done in the package. Needless to say, these are prospective considerations, not actual requirements for TEI-CAT.