1.1 Intention of This Article

In the last three decades there has been enormous progress in philosophical reflection, processing methodology and technical implementation of digital text modelling. Most efforts take place in the realm of Digital Humanities or Digital Scholarship and shed new light also on older and fundamental questions about the nature of text and the life-cycles of documents. “We cannot help but realise the great number of domains that inform our understanding of the book.” (Siemens, Dobson, et al. 2011) The main task in these realms is to transfer historical texts and documents from a physical medium into the digital sphere, for the benefits of automated administration, access and processing. (Siemens, Dobson, et al. 2011; Pierazzo 2015)

This article starts from the opposite standpoint: Nowadays, even the most simple act of creating a fresh text document with some digital text-processing system is also always an act of “text modelling”. Due to the nature of digital technology, even writing a simple “SMS” is indeed the creation of a text model. In contrast to the process in Digital Humanities, this kind of modelling is done unknowingly and without theoretical reflection.

But not only medieval texts, but also contemporary products like cooking recipes, hiking descriptions, usage instructions, poems, novels and scientific texts (like this article) should benefit from automated processing (automated search, indexing, versioning, comparison, evaluation, translation, extraction, montage, etc.) and not at least from Computer-Aided Reading (CAR). This term includes all the enhanced or even radical new ways of exploring a text using digital technology, as browsing and searching, referring and indexing, annotating and highlighting, collapsing and expanding, scrolling and animating, etc., – see Section 4.2 below, and Siemens, Dobson, et al. (2011) for a detailed discussion.

To minimise the necessary effort of adapting a text model to this processing pipeline, its nature and structure must be considered. Therefore the attitude of using the computer merely as a somehow more comfortable typewriter must be replaced by the consciousness of creating a text model, which stands at the beginning of an unlimited processing network. This is the first intention of this article.

For computer-based processing different text processing systems have been developed, by academic or commercial providers. Whenever a text is created not as the traditional two-dimensional visual representation on paper, but as a data object managed by a particular computer program, then the pre-wired ways of the program’s operation, its underlying data categories and their possible relations determine the structure of the created data object. Compared to the pencil on the paper we lose freedom, substantially! To clarify what price we have to pay is the second intention of this article.

Both, the naive users and the skilled specialists from Digital Humanities, often must fall back to the standard tools (from industry or academics) with their pitfalls and idiosyncrasies. These come in play esp. when trying to transfer a particular text from one of these formats into another. To analyse in advance the differences of the possible model structures and the expectable translation problems is the third main goal of this article.

For these goals, we analyse eight digital text formats (LAT_EX, Lout, DocBook, TEI, HTML, OD-T, d2d_gp, XML) plus the two non-digital Manuscript and Typescript for comparison, see Section 1.5.

Concerning the three goals (automated processing, flexibility of modeling and ease of transfer) our results are mostly descriptive about the data models and resulting restrictions. When a particular system allows widely varying ways of usage, the text may become prescriptive, recommending one way of usage over the other.

1.2 Structure of This Article

The rest of this section clarifies the basic notions and principles for the further discussion.

The next section discusses global properties of the different tools, which apply to a text as a whole or to the general treatment of text data.

Section 3 analyses the treatment of the different text components as defined at the start of that section and visible in the headlines of the subsections.

Section 4 treats dynamic/temporal aspects of text modelling.

Section 5 finally collects all found differences into survey tables.

1.3 Fundamental Definitions

“In most all things that exist at the intersection of several domains, domain-specific cultures have potential to collide, in useful ways as well as others.” (Siemens, Dobson, et al. 2011) This article operates on the borderlines of computer technology, informatics, general humanities, linguistics, philosophy, etc. To collide in a useful way (and not in others!-) it seems necessary to first clarify the nomenclature, because the central words needed in the following are used in these different domains with different meaning, and maybe even in some of them alone. We have to define “text”, “rendering”, “model/modelling”, “text modelling framework”, “substance”, “accidentals” and “identity”. Notabene, the following definitions shall only serve the following concrete discussion, – naturally we do neither intend nor expect to give finite answers to highly controversial questions in the various domains.

“The answer to the question what a text is depends on the context, methods and purpose of our investigation.” (Huitfeldt 1994, pg.235, our emphasis) In the following discussion, the word text is used for an intentional object in the sense of Husserl (Jacob 2019). Thus our “text” is nearly identical with the “document” defined as an “abstract object” by Renear and Wickett (2009, 2010) and to the definition used by Ingarden (1960) in his aesthetic analyses.

As an intentional object it is a merely mental, psycho-internal symbol which is completely empty: It has no properties at all except definedness and self-identity. It must be (explicitly) related to some outer material objects as its representations, for becoming communicable. Such a material object is called rendering in the following. It corresponds to what Huitfeldt, Vitali, and Peroni (2012) call “manifestation of the (same) document” and Buzzetti (2009) calls “image” (“the text does not have a material nature”; “’the text is only [and] always an image”) and what Pierazzo (2015) calls “document”. Further our “text” and “rendering” correspond to what FRBR calls “work” and “manifestation” (IFLA Study Group on the Functional Requirements for Bibliographic Records 1998). Physical objects like coloured lines on a piece of paper, waves of sound when hearing a lecture or bits and bytes stored in a computer system are different renderings of the same abstract text object.

A model is a special kind of rendering, as it is structured. Its information contents are segregated into distinct pieces, called (model) elements. Each such element is assigned one particular type. Each type prescribes the possible relations of its instances to the instances of the same or other types.

The definition of all types and their possible relations is called a meta-model. Every meta-model defines an infinite set of all possible adherent models. Every software tool and every text format definition comes with its own and specific meta-model. This article thus compares different meta-models.

With these definitions, the dots of ink on a sheet of paper are possibly the rendering of a text, but not a model. (But of course the contents of the text can describe a model, as in our Figure 1.)

Figure 1

Tree-Free and Tree-Bound Modelling Of the Same Character Segment.

What humans do when reading the text from such a piece of paper is creating an inner, mental model: Pixels of colour are translated into elements of types “headline”, “caption”, “footnote” and their respective relations. These types of (technical) elements which are well-known to the author and the elements of which are handled explicitly are also called text components in the following, esp. in Section 3.

The same holds with computer data: A JPEG file with a photograph of the paper and its dots of ink is a computer based rendering but not a model. Pierazzo (2015, pg.33) calls this “only digitized”, in contrast to “digitalised”. Contrarily, the computer based text processing programs discussed in this article work on structured data, means: on models. Each of them comes with its specific meta-model and is therefore called a text modelling framework (TMF).

The very first step when using a TMF (the transfer of a given text into this TMF, or the creation from scratch of a new text) already has significant impact on the structure of the model, because this has to adhere to the TMF’s meta-model: A mosaic of the Mona Lisa will appear differently when the available tessera are of three colours and rectangular or of 273 colours and hexagonal.

In this concern, very different software products like the (abstract) encoding specifications TEI/XML and the (concrete) layout processor LAT_EX stand indeed on the very same level: They both try to catch the substance of a text into a model, – a first and already transforming step, independent of all further processing and intention. Only this step and its target meta-model are subject of this article.

By the way: This notion of “model” must not be mixed up with the various ways for catching the contents of a text, i.e. modelling all the persons, things and facts mentioned in the text into a network of model elements, possibly represented as digital data. This is the subject of the very different variants of “Computer Assisted Qualitative Data Analysis Software (CAQDAS)”, creating something we could call “contents topology”. This is totally disjoint from the “text models” meant in this article, which refer to the text as such, as a mere object of language or writing. Here the model element types are “caption”, “headline” and “footnote”, forming a mere “technical topology”, as indicated in this article’s title.

Internally a postscript/PDF file is also a model. But its element types are again totally different, namely “fonts”, “subroutines”, “graphic contexts”, “coordinates”, etc. In relation to text this is only a rendering, not a model.

Being an intentional object, the relation from the inner mental symbol to an external rendering is always established explicitly, by an intentional act. This relation is personal and explicit, and whether a particular material object is related to the abstract text identity as its rendering is always a matter of personal opinion and taste. A frequent counter-example are statements like “Not, this was not the Moonlight Sonata, because the first movement was much too fast.”(Ingarden 1962, pg.126)

In our context, this intentional act becomes relevant when transferring a given model of a text from one rendering into a different meta-model: Every aspect which is considered substantial must be preserved, and everything considered accidental can be omitted, or even: must be omitted, because it is not supported in the target meta-model.

Based on this dichotomy also a notion of identity can be constructed: Two renderings realise “the same” text, i.e. the texts realised by them “are identical”, when the substantial aspects have the same value in both renderings. So the identity of a text is established by its substance, while substance and accidentals are both required for human reading and writing.

But there are no a priori or general rules to classify a particular aspect as substantial or as accidental. “The choice of what to include is a crucial one, and depends mainly on the purpose of the edition [/rendering]”. (Pierazzo 2015, pg.39)

In most cases it will be understood that the concrete optical appearance (e.g. the fonts and font size selected by the publisher) belongs to the accidentals, not to the substantials of the text and does not establish a different identity, see Section 1.7 below.

Contrarily, it is substantial that a part of a sentence is printed in an “emphasised” way, independently how this emphasis is realized (by bold type, underline, colour change or sim.) or that a sequence of words is printed “as a section title”. In modern terminology: The physical mark-up is translated into some semantic mark-up before two texts are compared for identity.

Furthermore, for many classes of texts it is agreed upon that line breaks and page breaks are not part of the substance. But there are classes which do respect line breaks, like poems and theatre plays in verses. It may be even considered of significance whether a poem appearing in a novel is separated by the preceding flow text by zero(0), one(1) or two(2) blank lines.

In the documentation texts of the different TMFs discussed in this article, those of TEI are the only ones which explicitly discuss the problem of text identity, substance and accidentals. A standard publication says e.g. “[…] one aspect of a fundamental encoding issue: that of selectivity. An encoding makes explicit only those textual features of importance to the encoder.” (Burnard and Sperberg-McQueen 2012), and another: “These broad definitions of textual aspects are not necessarily exhaustive and can be expanded and tailored to cover particular research aims and textual phenomena. Indeed, potentially there are infinite ways of making, describing and interpreting models of texts.” (TEI-Consortium 2013, sec.3.4) (In these two quotes, “encodings” and “models” seem to be used exchangeably.)

1.4 Analytical Tools From Mathematics and Compiler Construction

This article tries to systematise our experiences with modern, scientific and fictional texts and with their automated processing, from the standpoint of compiler construction. This is a discipline in informatics which originally has dealt with very special texts, namely those written in programming languages. But it also has developed a formal perspective on text in general, as a necessary pre-requisite for algorithmic processing. So any language becomes a kind of “computer language” as soon as it is processable by an algorithm. As a consequence, some fundamental principles of compiler construction can be taken over when talking about digital text processing in general.

One of the most fundamental and beneficial principles in software design is compositionality. This means that features or behaviours can be applied in arbitrary chains, where each step can get as its input the output of (a) any kind of preceding step, and (b) needs to know nothing about its application context.

Of course there are particular settings where compositionality cannot hold. But then it must be restricted explicitly, and this can be a hard criterion for the kind of text model. E.g., the restriction “Text in title lines may not contain footnotes.” is apparently true in most “plain” texts, but not when the footnotes are annotations by the editors in a historic-critical edition. For more details see Section 2.6 below.

Another every-day principle is the distinction between a foreground representation (also called external representation), which lives in one particular rendering of the model, versus the middleground information, which is the model in the narrow sense. E.g., in many computer languages an external object can be referred to from a source file by a qualified name, which is a chain of identifiers, joined by colons or similar punctuation. Alternatively, only the very last of these identifiers must be written, if its containing “module” has been “imported” before. Both are different front-end phenomena, but the information content (for further processing) is totally identical. Similar techniques happen in natural language texts quite frequently, but in most cases are not made explicit, – see Section 3.5 for important cases.

Related principles are separation of concerns (SoC) and minimality. The former means that fundamentally different aspects of things of one particular kind should not be mangled into one syntactic form, but should be modelled by one different syntactic element each. This allows to re-use these front-end forms to model the same aspect of “things of total different kinds”, and leads to minimality of different syntactic forms. This requirement is often violated, see Section 2.5.

1.5 Compared Text Modelling Frameworks (TMFs)

In the following sections these TMFs are compared:

• Manuscript

  Text written by hand.

• Typescript

  Text written using a typewriter.

• LAT_EX

  The well-known type setting system by Leslie Lamport, based on the T_EX system by Donald Knuth. (Lamport 1986; Goossens and Mittelbach 2004)

• Lout

  A compiler front-end to generate postscript output, by Jeffrey H. Kingston. (Kingston 1992, 2000b, 2000a, 2013)

• DocBook

  An XML-based (originally SGML-based) framework for technical documentation, esp. for computing technology, chief designer is Norman Walsh. (Walsh 2010; DocBook-Team 2014)

• TEI

  “Text Encoding Initiative”, a project for standardizing the encoding of arbitrary texts, but esp. in humanities. We speak about the latest version “P5”, which is not longer based on SGML, but on XML (Jannidis 1997; Branden, Terras, and Vanhoutte 2008; TEI-Consortium 2016, 2013).

• HTML

  “Hypertext Mark-Up Language” is the original document encoding of the world wide web, started by Tim Berners-Lee. Looking at the contemporary state of the art, we mean “XHTML 1.0”, and “Cascading Style Sheets CSS 2.0” will be taken into account whenever relevant for structural features.(W3C HTML Working Group 2002; W3C HTML Working Group 2011)

• OD-T

  “Open Document - Text” means all parts of the Open Document OASIS standard which are relevant for text documents. (Durusau and Brauer 2011)

• d2d_gp

  “Direct Document Denotation – General Purpose Module”, an front-end for writing down XML encoded documents with least possible formal noise, in the flow of creative authoring, by the authors. (Lepper, Trancón y Widemann, and Wieland 2001; Trancón y Widemann and Lepper 2010)

• XML

  Sometimes a feature applies to all XML-based frameworks, i.e. DocBook, TEI, HTML, OD-T, d2d_gp, and potentially others. (Bray, Paoli, et al. 2006; Boyer 2001)

Since we claim the change to “text modelling instead of type writing” as unavoidable and beneficiary, we do not speak about the very first solutions like roff and T_EX, because they realise only the visual aspects. Nevertheless they are worth mentioning, – without the experiences they brought, none of the TMFs listed above is thinkable.

Also postscript (Adobe Systems 1999) and PDF (Geschke and Warnock 2006) are no primary subject of analysis in the following, because, as explained above, they serve as mere rendering targets and not as meta-models. Nevertheless some of their technical properties will become relevant when discussing particular tool chains.

What severely limits the values of comparisons is the fact that all these systems are more or less parametrisable, extendable and adaptable. E.g. LAT_EX is a Turing complete programming language, – every thinkable modification can be implemented. With others of these frameworks, the variability is more restricted, or maybe very hard to define formally, but always given to a certain extent.

Therefore the following comparisons are deliberately restricted to the off-the-shelf, unmodified state. Comparing them thus gives an impression of the different basic philosophies, – but to realistically judge the costs necessary e.g. for translating between these models, the costs of adaption and parametrisation of the target meta-model can be significant. Nevertheless, in few cases when some particular parametrisation is especially easy or even required, this will be mentioned in the comparison results.

1.6 Substance and Identity, Revisited

Now that the collection of TMFs under consideration has been defined, this is how they treat the above-mentioned question for substance and identity of their text models:

1.7 Exclusion of Optical Appearance

The “substance of a text model” defined in the preceding sections seems sufficient for all kinds of texts, scientific or fictional. But indeed it imposes a severe restriction, which can turn out unacceptable in other contexts: The optical appearance of the text is excluded from the model’s substance; the concrete graphical layout only serves as a means for representation, as a carrier for the meant contents; it is accidental, not substantial.

This is inadequate for many products of fine arts, starting with ancient stone engravings, designed in equal rights as text message and as graphical ornament, ranging over many kinds of medieval manuscripts, up to the Concrete Poetry and Dadaistic poems of the early twentieth century: In her standard textbook, Pierazzo (2015)[pg.51] quotes a “calligramme” graphic by Apollinaire. In all these examples the concrete graphical appearance is part of the meant substance, not only a necessity for transportation.

A more recent example, fitting into the discussion of digital TMFs, are the poems of Mauricio Rosenmann, which use the T_EX typesetting system for rendering words and sentences according to aesthetic considerations. Font style, size and position of the characters being substantial part of the message (Rosenmann 1995, 1996).

This wider definition of a text model is not covered in the this article, but nearly all categories described in the following sections could be enhanced accordingly.

2.1 Multi-Layers and Multi-Authors Texts

A text often is a homogeneous object we look at simply for reading and grasping some contents. But this is only the simple case. Indeed, a text can be a multi-layer object: an original text can serve as the basis on which later altering operations have been performed. To represent this layering is obviously something different than to model only its results; the former has obviously at least one (≥1) dimension more.

So the text of a poem by Hölderlin (to take an extreme example) is for the readers in their rocking chair one consistent speech they want to listen to and meditate about. But for the philologist it is a stack of corrections, alternatives, strike-throughs and rub-outs, reflecting a fascinating process of word finding.

Already a simple critical edition of some text T1 of some author A is indeed an aggregation of two(2) very different texts, when applying the preceding definitions and considering authorship: First the inner text, the edited work by A forms a text. There is a second text T2 written by the editor(s) E (E1, E2, …), which completely fills the appendices. Additionally there are at least the annotation marks, interspersed into the main body but pointing into the appendix, which are part of T2 but physically rendered in the flow of T1.

T2 is a text on its own, but is only readable together with T1. So for the reader the two texts presented are T1 alone and T1+T2 together. T1+T2 is an achievement of the editors; of T2 they are also the authors.

T1 and T2 are called substantial layers, because the questions for substance and equality must be answered separately for both. In a similar way, different layers of typescript, first manual corrections, second layer of corrections, etc., form different substantial layers.

When the editor inserts reconstructed text into the flow text of the main body, the definition becomes ambiguous: The reader probably will receive it as “one particular version of the text T1 by A”, but with the same right it may be said that the completed sentence does only appear in T1+T2.

In case that page break indications of some earlier reference edition are interspersed in the rendering of T1, then these are part of T2, not of “the substance of T1”.

Similar: in many cultures the print versions of laws, or of books of the Bible, contain “interspersed local headlines” before each single paragraphs. These shall serve for quick orientation and are not part of T1 but of T2. Since this is well-known, they can come without further mark-up.

Summarising all these aspects, it seems clear that there cannot be a general a priori definition of substance and accidentals of anything called “text”. Instead, the notion of text and its identity must always be discussed explicitly and anew for each modelling project. Otherwise later automated processing will yield unexpected results.

2.2 Meant Model vs. Written Source Text (SrcTS)

A basic property of a TMF is called Source Text Strategy (SrcTS). It means that there are two different substantial layers of text: first there is (A) a source text, which is a “physical object”, which is stored in a file system and which can be printed, read and edited like a program source text. The author operates on this text. A very different thing is (B) the intended text model, which is described/constructed by evaluating (A) according to the rules of the TMF. (Actually, SrcTS is a property of nearly all digital TMFs discussed here, except OD-T.)

Indeed, both layers of text are text formats in their own rights. The source can be regarded a kind of rendering on its own, namely an especially ugly one. It happens frequently that a reviewer’s comment about a submission to a mathematical conference contains a fragment like

which uses the non-rendered LAT_EX source text for communication.

In many TMFs, the difference between both text layers can vary with the context: source text sections which are marked as “verbatim” (or “source” or “screenshot”, etc.) will transfer their whitespace and newline characters from source text into the text model and thus into the rendered output. But in text sections of most other kinds these characters belong to the source text only and are not part of the model. The same difference can be found between “physical whitespace” in the source, and that which is wrapped in a <text:s> element in OD-T a kind of “non-ignorable whitespace”, (Durusau and Brauer 2011, sec.6.1.3) or in a <xslt:text> element in XSL-T.

The mere existence of a source text does not help when searching for the real substance of a text. This can only be found in the mathematical model, not in the concrete front-end grammar of the input language. Here again the fundamental difference between foreground-representation and middleground model rules, as mentioned above. Some framework languages are even Turing complete, i.e. full-fledged programming languages, and there is no way of calculating the equality of two sources (=the identity of the encoded models) without their complete evaluation.

But frequent practice does help to narrow down substance considerably, as the source is often stored in two disjoint sets of text files. One contains the “style sheet” sources, which are provided by the publisher and thus accidental. The other contains the “contribution”. All definitions therein are more likely to be substantial. (This practice is ruled by the principles of SoC and reusability, see Section 2.5.) Any re-definitions in the latter of rendering rules from the former are also candidates for substance. These considerations apply to SrcTS TMFs, i.e. compiler style text models.

A further step of formalisation perform the TMFs with an XML encoded source text. These are DocBook, TEI, HTML and d2d_gp. This allows to apply standard tools and fine granular access control, see e.g. Section 4.4 below. (OD-T has also an XML based representation, which is normally not edited directly, but which can also serve as starting point for automated processing.)

An important consequence of SrcTS, that all kinds of meta-information (like “Fixmes”, “todo lists”, comments on open issues and possible variants, notes about the calendric dates of changes and updates) can be reified and managed in the same document as the definition of the intended text model, namely as source language level comments. This can be esp. useful for multiple authors’ co-operation, and has the additional effect that automated retrieval by version control systems, automated comparing, searching and replacing (diff, grep, sed, etc.) apply to these meta-info seamlessly in the same way as to the text model itself.

2.3 Source Model Coupling (SrcMC)

In meta-models which are based on SrcTS, most definitions of the semantics of input structures follow the principle of source model coupling (SrcMC). This means that the sequential order of the sub-expressions in a compound expression in the source text directly specifies the sequential order of the sub-elements in the model.

This is trivial and understood for the words in a sentence, the sentences is a paragraph, etc. But it is not always convenient for cells of a table (see Section 3.3.2), for footnote text (see Section 3.7), for defining index positions (see Section 3.5), etc.

For example, LAT_EX supports two flavours for footnotes: mostly the complete source text of a footnote is written “in place” after that portion of main text which shall be decorated with the footnote mark. So source text and model are coupled (= footnote-SrcMC).

A long footnote text in the middle of a sentence lowers the readability of the source text, so LAT_EX allows as an alterative to write two(2) separate expressions in the source: a short position indication in place, in the middle of the sentence, and the footnote text separately, some lines later. The meanings are exactly the same with both methods. So again the source text does not help to decide the equality of the intended model substance.

2.4 Compound Source Strategy (CmpSS)

Supporting the Compound Source Strategy (CmpSS) means that one single source file can contain segments of very different text description languages: each of these will be translated by different dedicated compilers, and the results will be combined to make up the final document rendering.

The advantage of the compound source strategy is, that all information is kept in one single source file (or a sequence of source files, organised according to the user’s need), without fragmentations due to mere technical necessities. This kind of integrity can also be aimed in conventional settings, with different files, by collecting them in one single disk directory, or one single zip archive, etc. But then still losses of single physical files may happen, or some confusion of file versions, and the integrity of the “text as such” will be lost.

(By the way: CmpSS can be seen as a successor of the ancient “object linking and embedding (OLE)” technology by microsoft. The fundamental difference is that there binary objects have been linked, and only dedicated computer software could perform the embedding and processing, while our notion of CmpSS means concatenating human readable source texts.)

A second advantage is, that all search, replace and spell check operations are applied on the whole text model, seamlessly and consistently, when applied to the one single source file. For instance, the replacement of one name by another will happen in figures, song lyrics, graphics and in the main text consistently.

2.5 Separation of Concerns (SoC), Minimality, Reusability

A pre-requisite for reusability of styles, layout methods and structure definitions is separation of concerns (SoC). (It is also a pre-requisite for compositionality, because for re-combining aspects you first have to separate them !-)

SoC means that different aspects of the text model and its renderings are realised by different data structures, notated in different parts of the source text, or even in different disk files.

Most TMFs support this strategy. Nevertheless, many implementations of tools and applications counteract the intended effect. E.g., OD-T separates the rendering information for segments of character data from their contents, and allows one “rendering style” to be applied to a multitude of text segments by named references. The number of styles should be minimised and styles should be re-used in a sensible way using the inheritance mechanism provided. But the wide-spread open source implementation “libreOffice” (3.5:build-413) applied to such a sensibly designed text model, does expand these definitions before writing them out and thus creates a new style object for each single character segment. This turns the feature of separate, re-used and named style definitions from a means for clarification into a means of confusion.

A special instance of SoC is the separation of semantic mark-up and optical appearance. As follows from our basic definitions of text, see Section 1.3 above, this is indispensable.

2.6 Compositionality

As mentioned in the beginning (see Section 1.4) compositionality is one of the most beneficent principles in software design. It basically means two properties, or one property seen from two sides, namely (a) to allow the free combination of all types of components, as described so far, and (b) to treat each component according to its type in a uniform way, independent of its enclosing context. Compositional behaviour should always be the default case: the human user as well as the author of the program code do profit heavily.

Contrarily, a particular TMF may impose explicit restrictions on compositionality. Some of them are sensible, commonly accepted and beneficent, e.g. in favour of the user’s orientation: Many TMFs have a structure like “paragraph”, which cannot directly be used recursively (a paragraph cannot contain paragraphs), but indirectly (a paragraph can contain tables, which again can contain paragraphs). So the user can make their mental model always as a “simple one-dimensional chain of paragraphs”, with complicated structure above and below. More restrictions are wide-spread, e.g. footnote text cannot contain footnote marks. All these restrictions must be made explicit, when discussing the text structure, and must be sensible w.r.t. the goals of modelling.

In many TMFs there is a quite different group of restrictions which come only from technical implementation problems, or from bad design of the standard, and are not related to the modelling problem as such. In most such cases other design goals like separation of concerns and minimality are also violated.

Without restrictions on compositionality, lists can contain lists and tables and paragraphs; tables can contain lists and tables and paragraphs; paragraphs, whether in lists or tables or both or neither, can contain annotation marks; annotation text can contain tables and lists and lists of tables, etc.

So far no problem should arise, only some questions. E.g., where is the footnote text placed if the footnote label is in a table entry? At the bottom of the table or the bottom of the page? And what about annotations in a float caption?

A systematic solution is to assign to each annotation kind two lists of component types and kinds, the innermost component from the first (/second) list which contains the annotation mark defines the reset scope (/rendering position).

In most cases a title text needs to contain entity references and formulas, sometimes also highlightings. But does it need citation keys? Or footnote marks? And how will conflicts of the clashing rendering rules will be resolved?

In most cases title text will explicitly exclude two dimensional components like lists, tables and diagrams. But possibly float captions may have richer contents than section titles have.

In most cases annotation text (e.g. footnote text) may contain everything like a normal main text paragraph. But annotation marks are limited, as discussed in Section 3.7.

W.r.t. entity references and annotation marks a new aspect comes into play, namely the multiple rendering of one source text segment (what can be called multiplication of source text): A section title or float caption text appears in the rendered text document in the component it belongs to (the section title paragraph, etc.), and additionally in a central index, (“ToC” or “List of Figures”). Anchors, citations, entity references may only be “operative” (rendered as a link target or added to a register) in the first case, not in the second.

In any case, the adequate means for a mathematical model of these restrictions are restrictions on the transitive closure of the containment relation. Please note that this is a rather high-level device, even pure relational algebra does not suffice. It must be formulated additionally to the grammar rules of “content models”; most attempts to integrate it therein are highly impractical and hardly maintainable. E.g. the original SGML design has a mechanism for forbidding particular (direct or indirect) nestings. Obviously due to lack of practicability this has been dropped in the definition of XML.

2.7 Tree Structure and Free and Bound Segments

Historically starting with SGML, all technical text meta-models listed in the previous section and treated in this article, except manuscript and typescript, are based on a structure with the mathematical definition of a tree-shaped graph with directed and ordered vertices. In most implementations this graph is technically reified as a so-called Document Object Model (DOM). The nodes of that graph are either so-called elements or character data nodes. A text is modelled as one(1) top element; each element has an ordered final sequence of child nodes and a set of string values, indexed by string values, as its attributes. The element graph is free of cycles. Nowadays this structure is omnipresent in XML encoded text objects. But since this is a natural encoding of expressions (in the mathematical sense), also other formats like LAT_EX and Lout basically adhere to a tree structure.

Of course this tree form appears a natural and direct solution for many aspects of text, e.g. the hierarchical structure of an article with chapters, sections, appendices on top, paragraphs below, and words, whitespace, symbols and icons as leaf nodes.

But indeed the tree form is not an adequate model for text as such, not for all of its aspects. E.g., many of the TMFs can model a selected text segment (=a contiguous sequence of characters, subject of a recent text change or of an annotation) only by wrapping it into one(1) element, i.e. making it the contents of one(1) node of the tree structure, see the dedicated elements of type <sc> = “select contents” in the lower part of Figure 1. This is called tree-bound (text) segment in the following.

But many practical use cases are not covered by this structure: the manuscript TMF has no problem to highlight arbitrary text segments with a text marker, starting in the midst of one paragraph and covering also parts of its follower.

In a tree like base structure, this can be modelled only by two(2) elements, one representing the start and the other the end of the text segment. These two elements have themselves empty content and are related to each other by some identifier value, see the empty elements <ss/> = “start segment” and <es/> = “end segment” in the lower part of Figure 1. This pair is called a tree-free (text) segment in the following. (The most important application of this principle will be discussed below in Section 3.4.)

These tree-free segments by elements can be positioned independently from the tree structure; nevertheless their element types must be foreseen explicitly in the document type definition of each element type they shall be contained in. One main technical disadvantage is that their correct pairing is not implied by the syntactic document type, as it is with tree-bound text segments, but is a semantic property, requiring explicit validation.

Even more important is that tree-free segments are not only independent from the tree structure, but also from each other: they need not be nested properly but can overlap arbitrarily, like different text marker applications in a manuscript. (“For many encoding projects, […] the problem of overlapping hierarchies is a serious drawback” says Pierazzo (2015, pg.120).)

Only TEI dedicates a whole chapter of its specification to the problem of tree-free structures (TEI-Consortium 2016, sec.20).

3.1 Explicit Hierarchical Structure and Sections

For the purpose of the next subsections, a text can be seen as a flow of characters and mark-up, both abstracted from their concrete appearances (Huitfeldt 1994). Line breaks, page breaks and extra vertical space are possibly included in the mark-up, and additional vertical separators (“asterism”, “volute”) can be modelled as special characters or as mark-up.

When reading a traditional paper rendering in textual order, a two-stage parsing process is executed by the perceiving human mind: first the mark-up separates the text into physical paragraphs. These are sequences of contiguous characters (plus maybe mark-up), separated by changes of appearance, line breaks or/and vertical distances.

In a second step, some of these physical paragraphs are identified as section title paragraphs, each of a particular section title kind. This can be caused by mark-up, or by the character data containing some key words, or by a combination of both. All text following this section title is perceived as a section. Translated literally from Latin, this means that such a title “cuts” the text into parts. The section title kind is transferred to the section as its section kind. The constructed mental model implies that such a section “contains” all the following text up to the next section title of the same kind, which ends this section and starts the next. So the text is regarded a sequence of sections.

A most simple section parsing process (MSSPP) provisionally describes the operation of a reader’s mind when constructing the mental model of the text when consuming it in textual order. MSSPP supports nested application of this mechanisms and works as follows, in the way of LL(1) parsing:

All recognised section kinds are stored on a mental LIFO stack (= a “Last In First Out” storage). As soon as a section title is reached with the same kind as one already somewhere on the stack, all sections up to and including this stack level are regarded closed and the stack is shortened accordingly. Then the new section kind is pushed on the stack and the sectioning process applied recursively. Thus an explicit hierarchical structure is layed over the text body; each section title and its section appear on a particular level of this hierarchy. The result is a mental model of the text as an hierarchically organised tree structure.

Possibly the section text contains physical paragraphs between the section title and the title of the first subsection. These we call pre-paragraphs. Due to the traditional reading (=”parsing”) process, there cannot be any “post-paragraphs” following the last subsection, because only the beginnings, not the endings of these are visibly rendered.

Additionally this hierarchical structure can be made more explicit:

1. There can be a naming scheme which assigns a word like “Part”, “Chapter”, “Section”, “Paragraph” as a kind name of a section kind, and which will be used when referring to some text position, see Section 3.9.

2. There can be a numbering scheme. This assigns an individual sequence number to all subsections of a particular section. The concatenation of the sequence numbers of all containing sections, in top-down order, yields a numeric coordinate for each section.

The older fashion is to use different number systems for different section kinds, yielding coordinates like “A I 1 a α”; the modern approach is just to use decimal numbers, yielding “1.1.1.1.1”. Both have their merits.

(The fact that this nesting of sections and subsections obviously, even necessarily forms a tree-shaped graph misled the inventors of SGML/XML et alii, to model all levels of a text as a tree, which is of course in no way adequate and causes severe problems nowadays when trying to specify and implement sensible processing algorithms !-)

The section title paragraph contains a title text, which serves as a name and/or as a description of the section’s contents. The title text may be the empty string.

Typically, in the text contents of the title paragraph, the kind name and the section’s sequence number or the complete numeric coordinate may precede the title, together with some constant decoration or separation stuff. In case of an empty title text, one of these must appear. Different combinations are possible, like “1.1.1.1 Introduction” or “Subsection 1: Introduction” or “1 – Introduction”.

Normally these rendering rules are constant throughout the whole text for one particular section kind/section title kind.

A common practice is that the sequence number (or the complete coordinate) appears only for all sections higher than a particular hierarchical level.

(Again, substantiality is critical, and basically three strategies are applicable: (a) The fundamental rules for the rendering of the section kinds are substantial and encoded, and only the title text (as the only varying data) is encoded explicitly with each section; (b) additionally the number is made explicit, but only as an abstract mathematical value, its rendering is defined by the data from (a); (c) the complete concrete contents of each title paragraph is considered substantial and is encoded.)

The following text is an example for the parsing of a three level sectioning with minimal means, namely line feeds as only mark-up, just to constitute the physical paragraphs, and explicit numbering and naming for identifying the paragraph kind and section title kind:

Chapter 1

1:

First Letter

Dear Friend!

Here in Transsylvania …

Normally the sequence numbers of sections of all kinds are positive, start with one(1) and grow upward by one(1). But this may be different for every section kind individually: While counting down or jumping non-monotonously is quite uncommon, a zero-based counting scheme may be sensible. Furthermore, when modeling legacy texts, some sections may have been lost and gaps in the numbering are substantial.

Normally the counter for all sections of kind sK is reset when the immediately containing section is closed. But it is also possible to bind this reset to the closing of a particular kind sR somewhere higher in the hierarchy, or to suppress it completely. This we call numbering reset scope. (E.g. it is common that “Chapters” are not reset when a new “Part” starts.)

In most texts the intended explicit hierarchy adheres to some of the following properties:

All texts fulfil property eh-1, by definition.

Algorithm MSSPP ensures eh-1. But it is too restricted: every individual section can contain only sections of one particular kind. Each section title kind starts either a “sibling” or an “aunt” of the current section, if it is already contained somewhere in the current state of the stack. Otherwise it starts a “child” on a further stacking level. The case that a new section title starts a “sibling” with a different kind can only be recognised by additional and explicit rules, mentioning particular title kinds.

Most contemporary scientific papers fulfil eh-3 and eh-4 for all section kinds, by intention. This implies eh-1, eh-2 and eh-7 for all section kinds and establishes a one-to-one map between section kinds and levels of hierarchy. The structure of the hierarchy may vary only by partly omitting the lower levels. Fulfilling additionally eh-8 is often estimated good style.

Adding eh-5 for all kinds but that on the leaf position makes that the hierarchy has the same depth at every leaf. This is a property often emerging by chance.

The combination of eh-3 and eh-4 may be weakened by the possibility to “cut out” one particular level in the middle of the hierarchy. This technique can be found together with the heterogeneous number coordinates in older books, e.g. that Part A consists directly of chapters A.1, A.2, but part B has an intermediate grouping level B.i.1, B.i.2, …, B.ii.1, B.ii.2, etc. For this, MSSPP suffices.

Adding eh-6 to eh-3 and eh-4 yields the (in-)famous dialectical structure of Hegel’s “Enzyklopädie der philosophischen Wissenschaften”.

Many contemporary scientific text books fulfil eh-3 and eh-4 for all section kinds, with one very specific and limited exception, namely that each section of kind “Chapter” begins e.g. with a section of kind “Survey” and ends with a section of kind “Exercises”, both not included in the numbering scheme which covers the “normal” subsections in between. So eh-3 is replaced by eh-2 for kind “Chapter”, and enhanced by eh-5 and eh-6 w.r.t. “Chapter” vs. “Survey” or “Exercises”. (This is a phenomenon of heterogeneity, similar to the existence of pre-paragraphs, and could be modelled more adequate by a grammar based approach, like the implicit hierarchies discussed in Section 3.2.)

Usually, the explicit hierarchical structure is represented in a Table of Contents (ToC). This is a formatted piece of text in which every section of a particular range of hierarchy levels is represented by one or more text lines. Like in the title paragraph, different aspects of each sections can appear in different forms:

1. the numbering, either (a1) only the sequence number or (a2) the complete coordinate;

2. the section kind, either (b1) explicitly by the kind name, or (b2) implicitly by optical appearance, or (b3) by both;

3. the title text;

4. some navigation means to the start of the section’s rendering, mostly a page number.

The selection and way of presentation of these pieces of informations can be defined individually for every section kind. In any case, the hierarchical structure must always be visible, at least by some mark-up like font size, indentation or leader lines.

(It is again subject to definition whether all these arrangements are substantial or accidental, as discussed in Section 1.3.)

Instead of the title text, each section may be assigned a ToCTitle to appear in the ToC, and additionally a running title to be printed in the page header or footer in some paper rendering. These alternatives are sometimes required for optical reasons, when the title text is too long.

There may be more than one Table Of Contents, e.g. (a) one survey omitting lower levels of the hierarchy, (b) one overall and detailed, (c) one for each part, placed at its beginning, (d) one for all appendices, before the first, etc. Each of these tables shows a different subset of sections, filtered by horizontal and/or vertical position.

3.2 Implicit Structure and Paragraphs

The physical paragraphs which are not title paragraphs make up the “contents” of the sections. They are simply called paragraphs in the following. A sequence of paragraphs is either the only contents of a section at leaf position, or forms the pre-paragraphs preceding its first subsection.

Each paragraph has a (paragraph) kind, which is recognisable by mark-up or by some leading character data or by both. Many texts will only have one single kind of paragraphs, the contents of which is flow text, making up the contents of the section. Frequently found other kinds of paragraphs are: Motto, Quotation, Survey, Comprehension, Deviation, Source Code Example, Screenshot, Music Notation.

There is a further level of hierarchy below paragraph, namely line display of embedded mathematical/chemical formulas, or embedded music notation, etc., framed by line breaks. Sometimes such a combination is not clearly distinguishable from a sequence of separate paragraphs. But it is clearly no such sequence when the line display is part of a sentence, e.g. when first demonstrating

1+2=3

and afterwards continuing the speech.

This distinction can be relevant because paragraphs must possibly be also numbered for text navigation, implicitly, see Section 3.9. Nevertheless also explicit numbering can be applied to the lowest levels of hierarchy, as it is usual e.g. in the bible or in printed laws. Then the discussion of the numbering scheme for sections from Section 3.1 applies accordingly.

Also Definitions, Lemmata, Theorems, Theses, etc., esp. in mathematical texts, can be considered special kinds of paragraphs.

In general, the notion of paragraph is the fundamental organisational unit for line break calculation. In most MSF, the paragraph notion is not directly compositional, but only indirectly: Paragraphs may contain tables, which contain paragraphs, etc.

The sequence of paragraphs make up the contents of a section, and by the sequence of their kinds they constitute an implicit hierarchy, which is a kind of “down-side prolongation” of the explicit hierarchy of sections. This hierarchy is defined by rules which refer to the possible sequences of paragraph kinds, and which are most naturally expressed by grammar rules.

E.g., in a mathematical text a paragraph of kind “Theorem” will be presented with special graphic appearance, numbering, etc. It is common habit that immediately afterwards a sequence of paragraphs follows which contain a proof of that theorem, the last of which terminates with a “q.e.d.” symbol. Alternatively it may follow a single paragraph which explains why a proof is omitted.

Similar, after a paragraph of kind “Definition” there may follow some paragraphs of kind “Example”. Furthermore there are “Normal” paragraphs without any special role. These rules are most adequately modelled by a context free grammar over paragraph kinds, as shown in Figure 2.

Figure 2

A Possible Grammar Over Paragraph Kinds.

The nesting of recognised non-terminals, the “parse tree”, constitutes above-mentioned implicit hierarchy, extending most naturally the explicit hierarchy of sections. (Please note that these rules are valid, but mostly not “reified”, ie. they do not appear explictly in the DTD grammars which come with the commonly used TMF implementations.)

Again, the borders are not hard: The example with the “Exercises” section at the end of each “Chapter” can also be modelled by dedicated paragraph kinds, in the realm of the implicit structure. Perhaps even more naturally.

As to a section kind, an explicit paragraph kind name and a numbering scheme may be assigned to a particular paragraph kind. The kind name may appear printed in the rendering or be used only for constructing references.

The numbering has a numbering reset scope, as defined above: it can restart at each section, but in most cases some higher level section kind triggers the counter reset. So a complete numeric coordinate can be constructed by appending the individual number to the coordinate of the section of that level. The numbers can be calculated for paragraphs of all kinds separately, or for several kinds together. Most other considerations on numberings from Section 3.1 apply accordingly.

Sometimes inventory lists = indexes are included in a text or rendering, referring to all paragraphs of selected kinds like a Table of Contents refers to sections. The possible variants discussed above apply accordingly.

3.3 Two-Dimensional Constructs

3.3.2 Tables

Another two-dimensional component type are tables. Their construction and definition are non-trivial, as the complicated historic process of the “CALS table model” shows (Bingham 2000).

For a simple model, it is sufficient to encode each table entry by its contents plus a pair of coordinates which gives the starting row and column. Each entry extends to the next higher entry’s coordinates, as shown in the left diagram in Figure 3. The identity of the text model is not defined by the sequential order of these table entries as represented in the source text, but by their effective coordinates.

Figure 3

Table Cells De-Coupled From the Source Text Order.

In contrast, all bespoken TMFs except TEI do map the sequential order of the sources of the cells to the sequential order of the cells in the model: They follow source model coupling (SrcMC), as defined above in Section 2.3. This is (a) of course very convenient for simple cases, but (b) it is not a necessity (coordinates could be given explicitly) and (c) it restricts the expressiveness for more complex shapes of cell unions substantially: the cell structure in Figure 3(A) we call “L-shaped” = “table-L”. It cannot be described by pure table-SrcMC, – it requires explicit start coordinates. The cell structure (B) we call isolated table cells or “table-I”. It needs even more explicit input parameters, namely additional explicit end coordinates.

The rendering of the model becomes especially critical in case of speech synthesis, where the text has to be rendered line by line or column by column or somehow navigable. Whether layout information (e.g. relative column width values) is substantial or accidental is once more a critical question.

On model level, tables can also be constructed with more than two dimensions (>2). Most simple example it the tabbed stack of input forms, ubiquitous in many Graphical User Interfaces (GUIs). These have “two-and-a-half” dimensions, because the positions on the third axis (= z-axis) are less strongly related then columns and rows.

Furthermore, table entries can be arranged truly spatial, in a grid of cubes, and in dynamic digital rendering this grid can be presented with varying aspect angle and eye position, controlled by the reader. This is hard to render and seldom found on paper. We expect it to become more frequent with the development of Computer-Aided Reading (CAR).

Additionally, there may be a non-local property of tables which leads to an inter-cell alignment of text entries in all cells of the same column and different rows, controlled by some alignment character.

With the component types introduced so far, the principle of compositionality, see Section 2.6 above, begins to show its fundamental relevance: May lists contain tables? And tables lists? And table entries paragraphs, etc.?

There are more complicated flavours of tables, where the text entry is enriched by graphic elements, e.g. different styles of cell borders may carry some meaning, or free connecting lines between cells may indicate relations. This is on the half way to free diagrams.

Manuscript and Typescript: arbitrary (two-dimensional) tables can be constructed. In a limited way, two-dimensional pictures of three-dimensional tables can be drawn.

LAT_EX has two sophisticated basic table models, for text mode and for math mode, resp. Both follow table-SrcMC (Goossens and Mittelbach 2004, pg.239). In principle, both are fully compositional. Column width can be left for automated calculation, or set explicitly by the user (normally calculated from the text dimensions dynamically).

Multi-column entries are supported, but no arbitrarily shaped multi-row-and-column segments.

The separating insets and borders can be defined in a very flexible way.

Lout has an elaborate table model (realised as an additional package), supporting colspan, rowspan and allowing page breaks within tables. It follows table-SrcMC (Kingston 2013, pg.125).

DocBook imports two(2) different types of table definitions: from HTML and from CALS (Walsh 2010, sec.3.6.5).

The CALS table model is a historically important and rather elaborate one. (Bingham 2000; Walsh 1999) It supports source-model-DE-coupling, i.e. it allows to define table cells in any source order, it uses table-SrcMC only as its default mode. The CALS model supports one alignment character per entry, which refers to other entries in the same column.

TEI has a simple table model, following table-SrcMC. It additionally defines a versatile @role attribute for table cells. The documentation explicitly mentions the alternative to integrate an XML declaration of the CALS model (TEI-Consortium 2016, sec.14). (What is called “alignment” in TEI are heavy-weight means on a semantic level and not comparable to a simple alignment character (sec.16.4).)

HTML comes with a very a simple table model as its standard. It is restricted to table-SrcMC. Nowadays rendering information will be added using CSS (W3C HTML Working Group 2011). CSS 3.0 introduces an alignment character by text-align=”,” (W3C HTML Working Group 2011, sec.7.1).

OD-T: The table model is re-used in text as well as in spreadsheets. Basically it is free recursive. The denotation of tables follows table-SrcMC. Different flavours of table can be defined using the “<style>” mechanism (Durusau and Brauer 2011, sec.9).

d2d_gp The basic default model has an utmost simple table model. It follows table-SrcMC.

(Due to the principle of compositional and re-use, this model is meant to be replaced by a more elaborate one, according to the user’s needs.)

XML in general does know nothing about tables, because these live on the level of a concrete XML instance. But there are standardised XML encoded table models available (like XHMTL tables or CALS) which can be imported and used by any user defined architecture.

3.4 Segments of Character Data, Highlighting

It is frequently necessary to select a contiguous segment of text character data and render it in a special way, to indicate some substantial property of this segment. As explained above, there are two fundamentally different technical means: tree-bound and tree-free text segments, see above Section 2.7.

The model components highlighting/segmentation correspond directly to “mark-up” in the original sense of the word, which once meant to take a transparent marker pen and to draw lines freely in a text, crossing borders of sentences, paragraphs and sections. Also arbitrary overlaps with other mark-up segments are permitted, when using different colours, without the need of proper nesting.

This can only be modelled directly by a TMF which supports tree-free segments, including the additional consistency checks, as discussed above in Section 2.7. With tree-bound segments only, such a mark-up must be split into a sequence of element with a “continuous leaf front”, see Figure 1.

Seen from the application stand point, character data segments fall into very different use cases, with different granularity and complexity. Most of them are totally happy with tree-bound realisation.

First it may be distinguished whether the mark-up and its contents belong to the same or to different substantial layers:

Declaring a segment as “emphasised” or “very emphasised” can be done by an author, when constructing a first layer of a text, thus as part of the substance of this layer. (As discussed in Section 1.3, it is an open decision whether the optical appearance of this emphasis is substantial or accidental.)

But the emphasis can also be applied to that first layer T1 by an editor, and thus be part of the layer T2, as defined above, forming a multi-layer text, see Section 2.1.

Means for rendering are changing the font family or font variant, from upright to slanted, small caps or bold, different ways of underlining, framing, or even different colours for text or background, etc. In any case the substantiality of the rendering must be discussed. Anyhow, if the semantic definition of these segment types requires their compositionality (cf. Section 2.6), then this must be supported also by the chosen optical appearance, e.g. by translating to “underlined”, “bold” and “slanted”, which are freely compositional.

Segments can also be used to identify the contained text as an identifier of a specific kind, e.g. the name of a human or the title of an opus, but this will in many cases imply additional navigation means and thus be treated according to Section 3.5.

The most complex segmentations naturally come from linguistics, because there text T1 itself, as such, is the subject of analysis. The mark-up belongs to a level T2 of analysis, has very fine granularity and is tree-free. But also much less complex segments by an editor, e.g. change marks, will in many cases by tree-free.

But there are (a) other categories of segments which are always tree-bound, like personal names, and (b) applications which are accidentally properly nested, like an emphasis completely contained in an embedded foreign language text. For these, some frameworks which do support tree-free mark-up offer additionally a simplified implementation, which is again tree-bound and thus verifiable by the document type definition.

3.5 Entities, Definitions and References

Texts talk about things, these things have names, these names are employed to identify the things. These seemingly simple facts have been discussed by the earliest known philosophers up to most recent schools in scholarship, linguistics, informatics, brain research, etc., and dozens of very different theories have been elaborated. For the discussion of this article only few simple mathematical properties are needed, which can be derived from any theory and serve as a bridge to the merely technical requirements of the TMFs.

In general, it is necessary that the above-mentioned “names” must have the mathematical property of a function, which means un-ambiguity: a “thing we talk about” is a kind of concept as part of some mental model, and we call it entity. Un-ambiguity means that each name refers to only one(1) entity. Due to this, the name is said to be an identifier in the strict mathematical sense. In the context of a computing algorithm it is furthermore highly desirable that these identifiers are additionally injective, i.e. there is only one(1) such identifier for each entity.

There are two possible conflicts: For a human reader, the identifier should be made of words of a natural language. Basically there can be two strategies, “unified name space” or “separated name spaces”. With the first strategy, the natural language word refers to an entity unambiguously. There is only one “Beethoven” and one “C major”. With the second strategy, the identifier is a pair of the natural language name plus a realm indication. So there can be two different entities called “C major”, namely a “key” and a “chord”, which are two substantially very different things. And the name “Richard III” can denotate a theatre play, a dramatis persona and a historic person, – even all of them in one single sentence. In these cases, when in the foreground of a text a natural language name is used for several things from different realms, then the real identifier (in the mathematical sense) is indeed a tuple of that name plus a realm indication. The latter is present in the structural middle ground of the text model, but not necessarily shown in a rendering.

The second issue is injectivity in the opposite direction: In the front-end text the natural language names may vary, representing the same identifier. We speak of “Beethoven”, “Ludwig van Beethoven”, “der junge Ludwig” or “the creator of the late string quartettes”. So the external representation of an identifier is something different than the identifier as such, and this fact must be respected by storing, retrieving, sorting, comparing, etc.

A recent development are canonical identifiers for entities, stored in authority files. Paper versions had been developed before 1900, and the electronically accessible implementations during the last decades. Prominent examples are GND for the German language, LCSH in US, NDL in Japan, VIAF for international integration (Bennett, Hengel-Dittrich, et al. 2007). None of the TMFs supports this special kind of identifiers directly. The KBSET project for scholarly editing and annotation is based on LAT_EX and supports the annotation of each entity reference with a coupled pair of both human-readable identifier (=external representation) and canonical identifier (=model middleground) by automated data base look-up (Kittelmann and Wernhard 2016).

Basically there are different cases for using entities, identifiers and external representations:

1. First, the entity can be assumed to be well-known. Then only references appear in the text. Computer-Aided Reading may add further navigation paths in the text: From the reference to a particular entity one wants to navigate to the very first, the preceding, the next or the very last reference to the same entity.

2. In many texts, esp. in scientific texts, there are additionally formal definitions of the entities (indexed by the identifiers).

Such a definition can stand (b1) at the first reference to the entity in text order. This is the normal case for mathematical theorems, etc.

Or (b2) it can be contained in dedicated lists and sections, e.g. in a glossary contained in the appendices.

Or it can (b3) appear at some non-first reference in text order. Then the references before this definition are “forward references”. Normally these are only acceptable in “pre-material”, e.g. in a “foreword” or an “introduction”, to refer to some theorem later in the main text body.

In both cases we want Computer-Aided Reading also to navigate to that definition (which in case b1 coincides with the navigation to the very first reference).

Furthermore we often want a list of the text positions (encoded according to Section 3.9) of all references to a particular entity. These lists typically form an index. These references may be attributed additionally by some scalar value indicating “relevance”, or by the “kind” of the referring text (from the main flow text or from a figure or from a footnote?).

A very frequent setting is this: most index entries are of “normal relevance”; highly relevant paragraphs are marked by bold font page numbers, this includes the definitions; many references of minor interest are totally omitted: references into figures or diagrams are indicated by using an italic font.

All TMF follow “index-ScrMC”, i.e. “source model coupling” as defined above in Section 2.3: An index entry has to stand in the source text at exactly the place it is meant to target at. Only DocBook has a de-coupled version: The expression “<indexterm zone=id> e </indexterm>” relates the index entry e to the whole contents of the DOM’s tree node with the XML identifier id and can stand anywhere in the source text (Walsh 2010, sec.9.1.1).

A special instance of (b2) are citations and bibliographies. In case of scientific papers, there are often two different “definitions” of the identifiers, namely the entry in the bibliographic list (type (b2)) plus a discussion in a “related work” section (type (b3)). In a larger monography the places of citations can in turn be listed by an index.

The presence or absence of a definition also applies to the overall subject of the text as a whole: A biography on Beethoven will not contain a dedicated “definition” of its topic, – or the whole text can be regarded as such a “definition”. Contrarily, a mathematical monography on “lattices” will start with an explicit definition of a “lattice”.

Frequently the entities appearing in a text are assigned to certain entity categories: e.g. in a text on music history there will appear composers, works, tonal keys, instruments, etc. (These categories live in the text middleground and may fall together with the above mentioned realms in the text foreground.) Often these different categories have specific rules for optical appearance. Entities of the different categories may appear in different indexes, even in more than one.

What is not supported in any of the TMFs are hierarchical identifiers: The name “Jan-Nydahl-Schule” is the name and identifier of a pedagogic institution, but its first two components form the identifier of a historic person. Similar with “Richard-Wagner-Festspiele”. None of the known TMFs does support this systematically.

3.6 Formalised Contents, Icons

The contents of paragraphs are “flow text”. Flow text normally contains written representation of sentences in some human language. In most cases this language is the same for the whole text.

Additionally, in these sentences entity references may be embedded which are more formalised than the human language’s words, e.g. a text on chemistry talks about H₂O or a text on music about $C^{\stackrel{9b}{{}^7}}$ .

These formulas (from different disciplines) differ from normal text w.r.t. line and page breaking, graphic layout (see the “baseline skip” between the preceding lines), etc. Possibly they are two-dimensional. Additionally, a formula may serve as an identifier, with all the issues discussed in Section 3.5.

For longer and more complicated formulas, a rendering as a line display, (i.e. framed by line breaks) may become sensible, see Section 3.2. Again the border of substantiality may be critical.

A similar kind of embedding is to treat icons or small graphic pictures like words, embedding them into the flow of a sentence. In the last years this became common with “emoticons”, but there are very early examples like alchemical symbols, which can be treated as an domain specific expansion of the alphabet, with each character standing for a whole word. Nowadays this can be mapped to “user space” in the spare unicode planes, if it is not already standardised somewhere.

3.7 Annotations, Footnotes, Apparatus

In printed and edited media, Annotations are normally rendered by decorating a word or a sentence in the flow text. This decoration establishes the connection to one or more paragraphs of commentary text which is rendered elsewhere and semantically stands beside the flow of reading of the main text. We speak of annotation mark and annotation text.

The only TMF which supports a graphic indication of the relation between a note and its point of reference (by a straight line, or sim.) is DocBook with its “<calloutlist>”, intended for source code explanations.

(In manuscript and typescript there are also annotations of a very different kind: connected to the referred text by free line drawings or inter-linear handwriting, not meant as a separate comment but to be inserted into the flow of text. These annotations reflect the creation process and have been resolved by the editing process before printing. While being an important subject of research, see Section 4.3 below, they are of non-digital origin and therefore not discussed in this article. When creating a text with a TMF from scratch, instead source text level comments can be used, see Section 4.4 below.)

The combination of mark types and rendering positions constitute an annotation kind. The most frequent type of annotation marks are superscripted Arabic numbers; a numbering reset scope must be defined, as for any sequence number. But also lower case Latin characters and dedicated symbols can be used.

On the input side, nearly all TMFs follow SrcMC: The input syntax must appear at exactly the place where the annotation shall appear in the flow of text.

On the output side, typical places where to render the annotation text are (a) the bottom of the current page (the annotation kind is called “footnotes”), (b) the end of the current chapter (“endnotes”), (c) a dedicated section of the appendices (“apparatus” or “annotations” in a narrow sense). When commenting program source text etc., also (d) a side by side rendering of commented and commenting text is frequent, the relation between both given graphically, by connecting lines (see the “<calloutlist>” in DocBook).

It is common practice that annotation texts of one particular kind may contain annotation marks of a different kind. The resulting graph of applicability between all annotation kinds must be free of cycles. E.g., the main text bodies in the “Marx-Engels Gesamtausgabe” have a lot of footnotes by the original authors, marked by numbers, and the main text and these footnote texts can carry annotations into the appendix, by numbers in parentheses. Such an annotation text by the editors can grow to an essay on its own and again carry footnotes. So there are three (3) levels of annotation kinds, with application rules not allowing cycles.

3.8 Floats and Figures

Floats are components which are related to the overall flow of the text more loosely than the other components. They are (normally) referred to more than once, and always explicitly by referring to their numeric coordinate. As with theorems, the numbering scheme may combine a sequence number with the coordinate of some containing section, and must define the numbering reset scope.

The concrete position of a float in the (one-dimensional) source text does not contribute to its substance; floats are a good example for explicit source/model DE-coupling.

In all renderings, the position of the float w.r.t. the references in the main body text is determined by ergonomic considerations. In paper realisation, the rendering of a float should appear near the place of the first reference. In screen realisation, it may be sensible to show them in a separate window.

Each float is assigned a float kind, and a numbering scheme covers one or more selected kinds, as explained above in Section 3.2 for paragraph kinds.

Each float must have a title text called caption which describes its contents. A table of all floats of a particular kind is normally found at the beginning or end of the rendering, and gives for each its numeric coordinate, its caption and some navigation means. As with section titles, a shorter title text may be specified for these tables. These tables correspond to the ToCs.

3.9 References Into the Text

Frequently, a text wants to refer to (a) a different text as a whole. Or to (b) to a segment of text, or to (c) to some single point in the text flow, i.e. a text position. Cases (b) and (c) can refer to (b0/c0) the referring text itself, or (b1/c1) to a different text, as in case (a).

Case (a) is easily done via citations, a kind of entity, see Section 3.5. In the other cases additionally the human readable textual position description must be supplied, plus a computer readable technical position encoding, which allows e.g. an interactive viewer to jump to that location.

When referring to segments of characters (cases b0/b1), the difference between tree-free and tree-bound becomes relevant again, see Sections 2.7 and 3.4 above.

The textual position description can be synthesised from the technical position encoding as long as the segment corresponds to a text component which has a numeric coordinate plus a kind name. This yields texts like “section 2.3.1.4” or “Figure 7.1”. (For this synthesis, the natural language of the document must be known, which can be non-trivial in case of multi-lingual documents.)

Addressing a text component of some finer granularity, or addressing an exact position in the flow of text (cases c0/c1), can in most cases only be achieved by an additional “manual” counting of paragraphs and sentences, as in “last sentence of last paragraph in section 2.3.1.4”. As soon as this happens, the exact borders of paragraphs and sentences, else an informal property, suddenly become relevant. This can be non-trivial, especially for tree-free segments.

Referring to page numbers and page relative line numbers should normally be avoided, because it is specific for one particular paper rendering, which is in most cases not considered substantial, i.e. not part of the text model. (“This practice is not generally recommended [..] since the pagination of a particular printed text is unlikely to be of structural significance.” (TEI-Consortium 2016, sec.3.8.1))

A different case is when the page numbers of an important ancient printing T0 of the base text T1 are contained in the editors annotation layer of a modern edition T2, as the page numbers of the Bekker printing of Aristotle’s “Categories” (Kalvesmaki 2014) or the page numbers of the Rosenkranz edition of the “Kritik der reinen Vernunft”. In this case the historic page numbers of T0 are part of the model of T2 and rendered inline, as superscripts or sim.

Additionally, many historic text corpora are supplied with a canonical reference system, the human readable form of which has been standardised in the humanities: for the Bible, the Iliad, for the works of Aristotle and Shakespeare, etc. Kalvesmaki (2014) gives a survey how to integrate them into digital media.

Most TMFs allow to insert anchors at arbitrary positions in the text flow. While not always a textual position description can be synthesised, a digital rendering always allows to “jump” to the corresponding rendered position.

All anchor-relative numeric coordinates and thus all synthesised position description are automatically adjusted when a text evolves, e.g. when a section is inserted. Contrarily, all manually constructed location descriptions can become invalid, like “in the preceding section” or “see above[!] in section xxx”.

Pointing from T1 into the foreign document T2 would become much easier as soon as the anchor definitions of T2 would be considered substantial part of the model and thus “exported” and “visible from outside”. Currently no digital TMF supports this. Analysing the “.aux” file generated by LAT_EX is technically possible, but must be considered “a hack”: the stability of its contents is not guaranteed by the author of the model.

3.10 Compositionality and Page Breaks

The mapping of the (mostly linear) character order to the pages of a printed copy can be considered part of the text model or not, as discussed in Section 1.3 above. Page breaks are contained e.g. in the models of programmed instruction books, see Section 4.2. If not, the TMF must insert page breaks automatically whenever rendering a longer text for printing onto a sequence of paper sheets. This is controlled by style specific rendering rules, like “Avoid page breaks in the midst of a poem” or “Clear page before a chapter”.

Basically, the text model as such and the needs of the rendering process should be coupled as little as possible. But in practice this independence is not yet totally realised.

An important exception is e.g. the printing of LAT_EX-tables which stretch over more than one page: Dedicated variants must be chosen by including packages like supertabular aut sim., which allow printing but have other restrictions (Goossens and Mittelbach 2004, pg.256).

There are other examples of these interdependencies, e.g. when printing graphics which are embedded in HTML. All these cases can be seen as a violation of compositionality: the choice of the tabular implementation is not longer independent from its application context, here: printing to a particular paper size.

Future evolution of software systems must aim at eliminating these dependencies, thus further clarifying the difference between model and rendering, between substance and accidentals, and augmenting the reign of compositionality.

4.1 Dynamic Physical Appearance (DPA) of a Text

One of the most important new features of digital text processing, beside automated comparing, indexing and search, is the Dynamic Physical Appearance (DPA) of a text rendering, on general purpose computer displays. (This section analyses the mere technical aspect; the very different applications are discussed in the following sections.) One and the same text model can be presented in very different views, controlled directly or indirectly by some user, e.g. the reader or the author or the editor or some software system.

There are many different applications of this feature. In principle, simple scrolling on a computer screen, and searching and highlighting of found occurrences by a simple PDF viewer is already a dynamic appearance. More elaborate is the expand/collapse mechanism found on HTML input forms, or with program source text editors from some Integrated Development Environments (IDEs).

The possibility for these “physically dynamic” ways of presentation may (a) live totally outside of the text model, e.g. when a dynamic way of rendering is applicable to any contents, as long as it is encoded physically in the corresponding format.

Dynamic appearance (b) may be foreseen in the text model, as far as tool tips, captions, paragraphs and links of selected kinds are meant to pop up, collapse, expand, serve as jump targets, etc.

It may (c) be totally controlled by the model, i.e. part of it in the narrow sense, if the model controls its outer appearance by a kind of musical score, which applies a series of transformations according to a fixed sequence of durations, or a by a state machine which reacts on user clicks, or by a combination of both. This is often called animation.

This distinction partly goes parallel to the distinction between two different sources of activity: the trigger for change can come from (I) an input activity from the user, or (T) the elapse of a certain time interval, after some preceding trigger.

Furthermore, changes can happen (α) gradually or (β) step-wise.

The following use cases employ different combinations of these alternatives.

4.1.1 Dedicated Hardware for Dynamic Text

A relatively new medium for presenting text are single-line LED displays which scroll a text from right to left, so that long sentences are readable in segments. Public transport companies use these in case of incidents to inform their passengers, (The type of DPA is aαT when scrolling or aβT when switching.) This reading situation clearly shows that this way of presentation induces a new kind of reception, which should be taken into account by the authors, but hardly is.

The principle of dynamic text rendering is much older, namely from the nineteen-twenties. One source is the art of composing movie title sequences; another very different origin are the dynamically switched neon bulbs in illuminated advertising (“Time Square illumination”). Of course the latter were “hard-wired” and could only change between few variants. The contemporary version of this are the typical LED displays showing the state of a Späti door in Kreuzberg of type cβT, see Figure 4.

Figure 4

Score notation for an LED Display.

Manuscript and Typescript can appear in a dynamic way when physical layers are analysed by some X-ray process. This a common, but exceptional situation, since the dynamic appearance is not used to present different layers of the text model, but to construct (re-construct, explore, …) them. The type of DPA is bβI.

Dynamic appearance may be reached by scans/photographs of the original text. This is the basis of all techniques for movie title trailers in pre-digital times.

Nowadays scan data can be presented by digital processing in a dynamic way, as it is often done on websites which publish important historic documents.

But in visual arts much older methods to animate texts can be found:

Manuscript and Typescript are magnified and copied to transparent or semi-transparent material and then subject to changes of the illumination, which brings dynamic changes of visibility, thus contents, thus meaning. The type is bαI or bαT.

Similar are the simple on-off dynamics from programmed instruction books:

The answer to a question is printed in black but covered with a confusing maze of red letters, – under red light the answer becomes readable (Type bβI).

LAT_EX maps its output indirectly to “.dvi”, which is translated to postscript, or directly to PDF, in more recent implementations. Lout generates postscript or PDF directly.

Both these back-end formats, and thus the TMFs, are per se not capable of dynamic appearance. The more recent implementations which produce PDF directly allow to embed hyperlinks, which at least allows dynamic navigation.

Nevertheless, the famous NextStep operating system in the 1990s employed (a special dynamic extension of) postscript as the basis of its operating system GUI, which is doubtlessly a dynamic application (Adobe Systems 1993). The necessary animation could only be achieved by frequent (and efficient) re-generation of the displayed pages. In this sense, LAT_EX and Lout could also be employed dynamically.

LAT_EX s packages for slide shows (see Section 4.5 below) implement an expensive work-around and produce for each dynamic slide a whole series of static pages, each of duplicates the constant parts redundantly, and which are projected one after the other. (Type bβI).

TEI contains temporal information in transcriptions of speech (TEI-Consortium 2016, sec.8.3.6, 8.4.2, 16.5.2); with “performance text” it models simultaneous execution (sec.7.2, 16.5.1). So temporal information can be substantial part of the text model.

DocBook, TEI and d2d_gp do in no way specify or restrict the rendering back-end, so dynamic presentation is possible, but not supported as first-class resident.

HTML does support physically dynamic rendering by actively changing the underlying Document Object Model (DOM), via (a) the use of ECMA script (Type bβI and cβT) or (b) the temporal control structures from SMIL (Dailey 2010; W3C 2008) (Type cβT only). In combination with embedded SVG for graphics, which is typical for the application contexts described in the following, also type α = gradual changes, are possible.

OD-T supports animation elements according to SMIL (Durusau and Brauer 2011, sec.15), (W3C 2008). Again, SoC is violated since animation means are duplicated in different contexts by <presentation:animations>, <draw:anim> <anim:.., etc. They support interactive animations (type bI, via event handlers) as well as automated animations, controlled by duration values (type cT).

XML in general: SMIL is a generic concept for temporal changes, either smooth or stepwise, either interactively/user controlled or automated, and has been adopted to many different XML encoded model languages, including SVG. (W3C 2008; Dailey 2010)

4.2 Interactive Reading (IR)/Computer-Aided Reading (CAR)

According to our initial definitions (see Section 1.3), a reading person cannot change the identity of the text, but its rendering. This we call Interactive Reading (IR).

An interesting historic pre-digital variant were the printed but interactive books for programmed instruction on paper = programmed instruction books, developed in the Sixties of the last century. Here the next page to read is presented according to some input of the pupil in the preceding step. This can simply mean to select between several page numbers, but can even include the automated generation of a “new” text, in the sense of our definitions, reflecting the user’s input. (DPA type is bβI) Due to these books, Computer-Aided Reading (CAR) (which is always interactive) is only a proper subset of IR.

Nowadays, these teaching systems are of course computer based, use all types of DPAs as described in the preceding section, and thus allow a much finer granularity, a much larger number of variants and the integration of other media like sounds and movies.

A most simple case of IR/CAR is a tool tip text which appears on a screen when the user’s pointing device touches the area of the visual rendering of a particular text component, and vanishes after a time out or when leaving this area (type bβI or bβI+T). Normally the tool tip text gives further information about an entity (cf. Section 3.5) or about a clickable jump target.

The nowadays popular e-book reader could enhance the possibilities of reading: even in fine arts, an electronic index could be very helpful. E.g. for keeping track of the more than two-hundred characters in “War and Peace”. One of the author prefers reading paper versions, but often misses an accompanying electronic index or search function, e.g. to retrieve a particular situation in the “Recherche” or an aphorism on a particular topic by Nietzsche.

CAR becomes esp. important to present multi-layer text, and to present time related structures contained in the text model as such, as discussed in the next sections.

In general, CAR can be applied to present to all components described in the preceding sections in a more or less sensible way: collapse paragraphs of a certain kind, highlight entities and references, highlight table cells, columns and rows, etc. An implementation allowing this for arbitrary text models (of a particular meta-model) is of type aβI.

The authors have programmed an SVG based import graph, which makes invisible all edges but those connected to the node currently pointed to (Lepper and Trancón y Widemann 2010, section “Containment Graph”). So very dense graphs can be made useful for the reader for information retrieval; this is a rather special variant of IR of type aβI.

André and Pierazzo (2013) describe the project for an interactive presentation of pages of a notebook by Proust, which visualises the historical temporal process of writing and editing by the temporal process of presentation. Similar ways of rendering will certainly be applied more and more in future.

When not only links are clicked but also text is entered (as in programmed instruction), then the border from IR to “interactive writing” may be crossed. When users fill out an empty form T1 given in PDF, then according to our definitions in Section 2.1 they create a new document (T2+T1).

4.3 Historic Versions of the Same Text Document

Editors can model different temporal stages of a text T1 in course of their editing work, while creating the text T2. These temporal stages can be regarded as different versions of T1, or as substantially different and similar texts T1.1, T1.2, etc. Anyhow, the historic-temporal evolution of T1 is the real subject of the text T2, and T2 is the apparatus of a critical/genetic edition or even a larger linguistic study about T1. This can be even more complicated, since also different hypotheses on the temporal evolution of a text can be the real subject of T2: we get a “tree with three-coloured vertices”, representing evolution, inclusion and alternative theories.

Only TEI supports this explicitly, since it has been designed esp. for this use case, the encoding of historic text bodies. (As mentioned above, in all programmable systems like Lout and LAT_EX, the necessary means can be realised by additionally plugged-in code.)

IR has already been employed successfully to present the different versions and layers of a historic text object. (André and Pierazzo 2013)

4.4 Volatile Versions When Creating a Text Document

A somehow dual situation is given when the versions of creating a fresh document must be handled explicitly. The history of versions and the process of evolution is not part of the final model, as in the preceding section, but required for constructing it. But it may be considered part of a temporary text model. The related components will be removed from the text as soon as the final model is completed, but are needed during its construction phase. All related issues become esp. important in the frequent case of a multi-authors text.

Typical components are change bars, and the mark-up of text fragment elimination and replacement, as long as a technical manual or a legal text is on its way through committees.

In this context the Source Text Strategy (SrcTS) is very useful, see Section 2.2 above, esp. in combinations with automated processing: All TMFs which follow SrcTS allow (a) to insert comments into the source, which are not part of the model (i.e. of the final, intended model, the model under construction), (b) to apply text processing standard tools like diff, grep, sed to the source text, and (c) to use version control systems like RCS or its younger competitors for assigning and controlling responsibilities among the authors involved. For this, the support of the TMFs is rather limited, see details below.

The possibility to assign individual modification rights to different authors is implemented in PDF, but in none of the discussed TMFs. But XML in general does allow to implement it rather easily, when the act of “storing the model” would be defined on the level of DOM nodes, instead on the textual representation. To our knowledge, this mechanism has not yet been implemented in a generic way. It could be used immediately by all XML based TMFs (DocBook, TEI, HTML, OD-T, d2d_gp).

A slightly different case, but important in practice, is the addition of annotations on a separate, dedicated data layer, as it is implemented e.g. in the PDF framework. In this case a second text T2 is created, discussed above in Section 2.1 als multi-layered text. The author of T2 is the reader of the first text T1, and the structure of T2 is defined upon the structure of T1.

E.g., one of the authors defined a very efficient communication protocol between himself as composer and a contracted sheet music engraver: each issue was modelled by one PDF “annotation balloon” in the music score under creation, T1. The colours were assigned: one for each side for their initially entered comments, followed by a precisely defined state machine for the issues’ resolution process, reflected in colour changes.

4.5 Animated Text in Slides and Presentations

Animated text for slides is not supported directly by most TMFs, but by some sibling software. So microsoft offers the (in-)famous “power point” as part of their “office” package, a sibling to “ms word”, and OD-T has a zoo of <presentation:..> elements in parallel to its text model.

The beamer package (Tantau, Wright, and Miletić 2011) and some older predecessors (seminar, prosper, FoilTex, etc.) are plug-ins for LAT_EX.

Slides are “dynamic” by definition and in their ancient realisation, because they are a sequence of images presented to the public by projection, one after the other, ordered in time, following the tempo of a life speaker (DPA type bβI) or a prefabricated tape (bβT).

This can be (and historically has been) limited to a mere sequence of static picture contents. For our subject we have to ask for dynamic behaviour of the text contents of one single such slide.

Here we have different features:

In “Power Point”, everything can “fly in”, “fade out”, “crumble” or “explode” (DPA type cαT). But only by selecting from a fixed set of “effect generators”, which offer a fixed sets of parameters each, and basically operate on pixel graphics. There is no principle limit, but a practical, since the particular effect generators must be available.

The beamer LAT_EX package allows arbitrary change of text content, controlled by a concept of “phases”, e.g. replacing one text fragment by another. An instance of this is the semi-automated change of visual aspects, for fading-in of the items of a list one by one, etc. The temporal definitions have the granularity of stages (DPA type bβI); smooth moving, dynamic fading and exploding are not supported.

With all XML based formats, the combination of the extensions Scalable Vector Graphics (SVG) (W3C 2011) and the animation features of Synchronized Multimedia Integration Language (SMIL) (Dailey 2010; W3C 2008) can be used. These allow in principle all kinds of temporal behaviour: position, rotation, colour, transparency, font size, etc. of each text fragment can be changed gradually over some time interval, in arbitrary parameter value curves. (Generally DPA type bαT), but exchange of fonts can only happen stepwise, and exchange of text contents only by switching on and off the visibility of different text objects (both of type β). This approach follows Compound Source Strategy (CmpSS): Text stays text, even under graphic transformations, and thus can be subject to search and replacement.

The construction of these temporal structures is awesome, and misses “text quality” (in the sense of a “direct reification” of a mental model), because there is no simple direct relation between the intended time functions and the demanded expression syntax.

So we have three fundamental different strategies, with different pros and cons each:

1. Arbitrary and smooth image transformations, on all parameters, and even on pixel level, but only by predefined processors (“powerpoint”).

2. Non-smooth exchange of text components and of all text rendering parameters, without moves (LAT_EX).

3. Smooth image transformations, not arbitrarily on pixel level (no “blur” nor “crumble”), but on most text rendering parameters (colour, size, transparency, position and rotation) by SVG+SMIL.

The constructions of these transformations, in the current implementations, have again very different grades of flexibility:

1. No means for abstraction and automation, only interactively definable and stored in an opaque binary format (“powerpoint”).

2. Fully under program control, easily abstractable and convenient usage (LAT_EX).

3. Fully under program control and abstractable (ECMA script, DOM model, etc.), but counter-intuitive expression language, very hard to write down manually (SVG+SMIL).

Interestingly, the types of supported triggers are complementary:

4.6 Animated Text in Visual Arts

In visual arts the animated presentation of text has a history of nearly hundred years, starting with the graphics of movie title sequences, as mentioned above. A more abstract, more recent and explicitly artificial example has been the video “Sign o’ the Times” by Prince in 1987. (Nilsen 2004, pg.623, acc.to wikipedia)

As mentioned in the previous section, the combination of XML plus SVG plus SMIL has a very satisfying range of effects as its outcome, but cannot be denotated in an intuitive way. Therefore the authors wrote translation software based on their tscore time representing formalism, for easy denotation of temporal artistic text processes. The result has been published as a combination of source text, binary application, example score data, generated output, i.e. animated typographic art, and documentation (Lepper and Trancón y Widemann 2013a, 2013b).

Of course, the translation code is dedicated to one particular setting of input score format and intended output animation style. The programming language (here: Java) is the means for defining and realising the relation between these two. But this specific text needs only two to three pages, it is easily adopted to other intentions.

4.7 Online Information Systems

Even the “identity of a text itself” (as defined in the fundamental discussion above, see Section 1.3) can be variable. This is the case with online information systems: e.g. the current prices on a stock exchange are often presented on screen in tables, in one column the company’s name, in the next the figures changing in real time. But of course these figures could also appear in a flow text, changing also the wording of the sentences and the colour of the mark-up dynamically, replacing a bull icon by a bear.

In any case, these online information systems require to support dynamic appearance, as defined in Section 4.1.