Pre-printed parts: Letterheads and forms
Introduction
1Correspondence materials often contain pre-printed parts for which there are no sufficient or satisfying encoding recommendations in the TEI Guidelines. These pre-printed parts can be divided into two categories. First, there is the typical case of letterheads, usually with name and address of the sender, maybe including a company emblem, family crest or other kind of symbol. And second, there are pre-printed parts similar to printed forms, for example address fields with labels and dotted lines to fill in on postcards, envelopes, or letters.
2Both cases represent pre-printed parts but constitute semantically different phenomena. It is, therefore, necessary to make a basic distinction between these two cases regarding their encoding in TEI.
Case 1: Letterheads
Issue 1: Using <fw>
3 One suggested possibility to encode letterheads is using the element <fw>.[1] The TEI Guidelines define <fw> as follows:
<fw> (forme work) contains a running head (e.g. a header, footer), catchword, or similar material appearing on the current page.
https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-fw.html
4Next to running heads and footers, i.e. titles of chapters in printed books, this element is also intended for page numbers, catchwords, and "other material repeated from page to page, which falls outside the stream of the text".[2] The question is whether letterheads fall in these categories or whether this is an overexpansion of the definition and therefore a misuse of <fw>.
5A possible encoding using <fw> might look like this (example 1):
<fw type="letterhead" place="top-left">Maison de
Santé<lb/>de<lb/>Saint-Rémy<lb/>de Provence<lb/>Bouches-du-Rhône</fw>
6The element <fw> is quite flexible and allows names, places, and addresses to be marked up with <address>, <name>, <placeName> etc. to further specify the content of the letterhead. <figure> can also be included to capture images that are part of the letterhead (for this, see Case 1: Letterheads, issue 4). There is, however, the question whether <fw> being an inline element is problematic or not as letterheads in their layout are usually set apart from the rest of the text.
7The encoding of a combined letterhead and—as one might call it—letterfooter might look like this:[3]
<div>
<pb n="1"/>
<fw type="letterhead">[...]</fw>
<opener>[...]</opener>
<p>[...]</p>
<fw type="letterfooter">[...]</fw>
<pb n="2"/>
<fw type="letterhead">[...]</fw>
<p>[...]</p>
<closer>[...]</closer>
<fw type="letterfooter">[...]</fw>
</div>
8Here, you can see this structure in an example encoding of a letter from Johnny Cash to Saul Holiff, written in 1961:[4]
<div>
<pb n="1"/>
<fw type="letterhead">A Few Very Rural, Badly Phrased But Well Meant Words
From<lb/>Johnny Cash</fw>
<opener>
<address>
<addrLine>4259 Hayvenhurst Ave</addrLine>
<addrLine>[...]</addrLine>
</address>
<salute>Dear Mr. Volatile,</salute>
</opener>
<p>Thanks very much for the pictures. [...]</p>
<fw type="letterfooter">Singer - Song Writer - Guitar Picker - Cotton
Picker</fw>
<pb n="2"/>
<fw type="letterhead">A Few Very Rural, Badly Phrased But Well Meant Words
From<lb/>Johnny Cash</fw>
<p>Concerning the cities proposed, [...]</p>
<closer>
<salute>Gotta go. Thanks again for the pictures. If you need any help
from this end, let me know.</salute>
<signed>J.R.</signed>
</closer>
<fw type="letterfooter">Singer - Song Writer - Guitar Picker - Cotton
Picker</fw>
<pb n="3"/>
<fw type="letterhead">A Few Very Rural, Badly Phrased But Well Meant Words
From<lb/>Johnny Cash</fw>
<postscript>
<label>P.S.</label>
<p>Gordon went to Las Vegas over the weekend [...]</p>
<signed>J.R.</signed>
</postscript>
<fw type="letterfooter">Singer - Song Writer - Guitar Picker - Cotton
Picker</fw>
</div>
9While this encoding might be suitable for letterheads with names and addresses, it seems not so fitting for pre-printed parts with gaps to be filled in by the letter writer (for this, see Case 2: Pre-printed parts like forms, issue 2).
Issue 2: Using <opener> or <head>
10As letterheads are often positioned at the top or bottom of the paper, one might think about using the elements <opener> or <closer> with a type attribute that contains, for example, the value letterhead. While <opener> with rend="letterhead" and <closer> with rend="letterhead" before and after the actual <opener> and <closer> might seem like viable solutions, they represent in fact a tag abuse as letterheads are not covered by the definitions of these two elements.[5]
11The same is true for the element <head>[6] which, moreover, cannot capture letterheads at other places than the top of the page. As printed letterheads need not necessarily be on the top of the letter paper above the letter text, they can be positioned at the bottom, on the left or right side, or centered. Therefore, the encoding of letterheads should be independent of their position on the paper but solely based on their content.
Issue 3: Using <div>, <seg> or <ab>
12There is also the possibility of encoding printed letterheads not with an 'individual' element but in a more general way as divisions, segments, or even as anonymous blocks. The definitions of these elements <div>, <seg>, and <ab> do not exactly apply to letterheads but could be considered semantically close:
<div> (text division) contains a subdivision of the front, body, or back of a text.
(https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-div.html)
<seg> (arbitrary segment) represents any segmentation of text below the 'chunk' level.
(https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-seg.html)
<ab> (anonymous block) contains any arbitrary component-level unit of text, acting as an anonymous container for phrase or inter level elements analogous to, but without the semantic baggage of, a paragraph.
(https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-ab.html)
13The <div> element can be further specified with a type attribute containing "letterhead", "letterfooter", and "pre-printed-form" as possible values, or, in a similar manner, a type attribute containing a general value "pre-printed" accompanied by additional subtypes "letterhead", "letterfooter", or "pre-printed-form". Next to a type attribute, a rend attribute with a value like "pre-printed" also seems possible. However, these encodings pose problems as, for example, <div> and <ab> are not allowed before <opener> or after <closer>. Putting them after <opener> and before <closer>, respectively, is in many cases not a faithful encoding of the source. <seg> is an inline element and cannot be used outside <div> that again is not allowed before <opener> or after <closer>. It should, however, not be put inside <opener> or <closer>, respectively, as it cannot be considered a part of these.
14Another problem arises when dealing with letters several pages long and with a recurring (or even changing) letterhead on each page. An encoding like
<div type="letter">
<div type="letterhead"/>
<div type="letterbody"/>
</div>
15Finally, all three elements <div>, <seg>, and <ab> seem rather unspecific regarding the encoding of letterheads, and are probably too general.
Issue 4: Using <figure>
16As letterheads very often include an image or graphical element, and are "typically the result of a lay-out process in the design of the letter paper"[7], an encoding using <figure> with type="letterhead" comes to mind. The element <figure> can occur in many different places and can be used in varying depth. On the one hand, it can be used as an empty element for merely signalling the presence of a letterhead. On the other hand, it can contain a description (in <figDesc>), a digital image (in <graphic>), and/or a transcription of its text.
17A possible encoding using <figure> might look like this (example 2):
<div type="letter">
<figure type="letterhead">
<figDesc>The figure shows a drawing of Shakespeare's birthplace in
Stratford-upon-Avon, England.</figDesc>
<graphic url="fig1.jpg"/>
<head>Shakspeare's birth place</head>
<p>Published by E. Adams</p>
</figure>
<opener>Meine liebe Frau. [...]</opener>
<p>[...]</p>
</div>
18Its use is very flexible but the definition suggests that using <figure> like that is rather a tag abuse:
<figure> groups elements representing or containing graphic information such as an illustration, formula, or figure.
(https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-figure.html)
19Any text contained within <figure> is being understood as "commentary on the figure in the source"[8] which is not the case in each and every letterhead. Sometimes, there may be text accompanying and commenting the image, as in example 2. However, it usually is the case that text and image are on a parallel level to each other, or the image is an illustration of the text, not the text a commentary on the image. The image might also be just an additional, beautifying feature, like an ornamental decoration as in the letterhead in example 1. Therefore, the text of letterheads should not be subordinate to its image and be transcribed within <figure>. If there is no image at all, as in example 3, an encoding of the letterhead—although perhaps containing a graphical layout—with <figure> seems counterintuitive.
20<figure> is also not suitable for pre-printed parts with, for example, a place and a dotted line to fill in the date (see Case 2: Pre-printed parts like forms, issue 3).
21Even though <figure> is not suitable for complete letterheads, it can be used for just the image. It can be part of <fw> and a possible encoding of example 2 might look like this:
<div type="letter">
<fw type="letterhead">
<figure>
<figDesc>The figure shows a drawing of Shakespeare's birthplace in
Stratford-upon-Avon, England.</figDesc>
<graphic url="fig1.jpg"/>
<head>Shakspeare's birth place</head>
<p>Published by E. Adams</p>
</figure>
</fw>
<opener>Meine liebe Frau. [...]</opener>
<p>[...]</p>
</div>
Issue 5: Using <layoutDesc>
22A basic decision is whether the information of the existence of a letterhead and its content are needed in the transcription or whether abstracting these information and putting them in the meta data is sufficient. The latter may be more convenient for projects that consider the exact transcription of letterheads not semantically important, and for projects with large corpuses of letters with numerous letterheads.
23For including these information in the meta data, <layoutDesc> as part of <objectDesc> is a suitable place:
<layoutDesc> (layout description) collects the set of layout descriptions applicable to a manuscript or other object.
(https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-layoutDesc.html)
24A simple encoding example might look like this:
<objectDesc>
<layoutDesc>
<layout>A letterhead is printed at the top of the paper with the company's
name and address.</layout>
</layoutDesc>
</objectDesc>
25Additionally, it might be useful to link the information encoded in <layoutDesc> with the transcription of the letterhead in the <body>. For the letter to Vincent van Gogh in example 1, we recommend an encoding like this in the <teiHeader> as well as in <body>:
<objectDesc>
<layoutDesc>
<layout xml:id="lh">A letterhead is printed in the top left corner of the
paper with the hotel's name and address in which the sender was
staying.</layout>
</layoutDesc>
</objectDesc>
<!-- [...] -->
<div>
<fw type="letterhead" place="top-left" corresp="#lh">Maison de
Santé<lb/>de<lb/>Saint-Rémy<lb/>de Provence<lb/>Bouches-du-Rhône</fw>
</div>
26For the linking of the letterhead in the <body> part with the header, one cannot use @ref within <fw>, as this is not allowed according to the TEI Guidelines. It is also not allowed to use the <ref> element inside <div>. Therefore, the <ref> element needs to be put inside <fw> containing the transcription of the letterhead. The target attribute then points to the <layout> element in the header:
<div>
<fw type="letterhead" place="top-left">
<ref target="#lh">Maison de Santé<lb/>de<lb/>Saint-Rémy<lb/>de
Provence<lb/>Bouches-du-Rhône</ref>
</fw>
</div>
Using <supportDesc>
27If one understands the information on pre-printed letterheads on the paper as information about the supporting material on which the letter is written or typed, the element <supportDesc> (as part of <objectDesc>) might first look like a suitable place:
<supportDesc> (support description) groups elements describing the physical support for the written part of a manuscript or other object.
(https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-supportDesc.html)
28This is a handling of letterheads similar to, for example, watermarks. However, this rather relates to the actual material and its physical aspects[9] than to information printed on these materials. Therefore, <supportDesc> cannot be recommended for encoding letterheads.
Case 2: Pre-printed parts like forms
29Pre-printed parts are a recurring phenomenon in correspondence materials, and can be found on telegrams and postcards. A proper markup in order to distinguish pre-printed text from handwritten text may be helpful when it comes to research questions focusing, for example, on the relation of pre-printed and handwritten text in letters and how the first may influence the (genesis of) the latter.
Issue 1: Using <ab>
30On the textual level, one solution might be the use of the block element <ab>[10] in order to distinguish between pre-printed and non-pre-printed parts. <ab> then might use the attribute–value pair type="pre-printed" for pre-printed parts, type="typed" for text which is produced by a typewriter and type="handwritten" for handwritten text to make the distinction.
31An encoding of the field postcard in example 4 might look as follows (simplified, deletions by sender not encoded):
<ab type="pre-printed">Absender:</ab>
<ab type="handwritten">Vizewachtm. Marc</ab>
<ab type="handwritten">Galde<lb/>Fuchs</ab>
<ab type="pre-printed">Armeekorps<lb/>Division</ab>
<ab type="handwritten"><lb/><lb/>Ersatz</ab>
<ab type="pre-printed">Regiment No<lb/>Bataillon<lb/>Abteilung</ab>
<ab type="pre-printed">Kompagnie<lb/>Batterie<lb/>Eskadron<lb/>Kolonne</ab>
<ab type="pre-printed">Besondere Formationen: (Flieger, Funker usw.)</ab>
<ab type="handwritten">Schilling der 1. bayr. Feld-Art. Rgt. Leichte-Mun.
Kol.</ab>
32When encoded like this, we cannot see which handwritten addition belongs to which pre-printed part. One could solve this problem by an encoding like the following (with a different segmentation of the text used in order to group the associated parts):
<div>
<ab type="pre-printed">Absender:</ab>
<ab type="handwritten">Vizewachtm. Marc</ab>
</div>
<div>
<ab type="handwritten">Galde</ab>
<ab type="pre-printed">Armeekorps</ab>
</div>
<div>
<ab type="handwritten">Fuchs</ab>
<ab type="pre-printed">Division</ab>
</div>
<div>
<ab type="pre-printed">Regiment No</ab>
</div>
<div>
<ab type="handwritten">Ersatz</ab>
<ab type="pre-printed">Bataillon<lb/>Abteilung</ab>
</div>
<div>
<ab type="pre-printed">Kompagnie<lb/>Batterie<lb/>Eskadron<lb/>Kolonne</ab>
</div>
<div>
<ab type="pre-printed">Besondere Formationen: (Flieger, Funker usw.)</ab>
<ab type="handwritten">Schilling der 1. bayr. Feld-Art. Rgt. Leichte-Mun.
Kol.</ab>
</div>
33The attribute-value pairs mentioned above do not follow any conventions in TEI; the type attribute can be used in order to annotate completely different phenomena. Thus, this solution seems unspecific with regard to the various ways in which <ab> can be used.
34Cases might arise in which pre-printed parts express a date or a location and, therefore, belong in <opener>.[11] When using <ab> for the encoding of pre-printed, typed and handwritten parts, it could make sense to place these encodings within <opener>. Since <ab> is not allowed within <opener>, this is another reason not to use <ab>.
Issue 2: Using <fw>
35The forme work element might be fitting for letterheads with names and addresses, as has already been described in Case 1: Letterheads, issue 1. However, it seems not applicable for pre-printed parts like forms. First, documents like the field postcard in example 4 do not consist of a running head but the pre-printed text rather occurs on a single page and is, therefore, not a continuous feature. Thus, the definition of <fw> cannot be applied to this case. Second, the type attribute could be used to distinguish between pre-printed, handwritten or typed text, but, analogous to the case in Issue 1, there is no such usage convention of @type in TEI.
Issue 3: Using <figure>
36The use of <figure> for pre-printed parts has already been discussed letterheads (see Case 1: Letterheads, issue 4. There are two main reasons why <figure> should not be used for pre-printed text. First of all, such documents as in example 4 do not contain an illustration, formula, or figure in a narrow sense, so using <figure> is excluded due to its definition. Furthermore—as is the case in issue 1: Using <ab> and issue 2: Using <fw>—there is no convention in TEI of using the type attribute to express a distinction between handwritten (or typed) and pre-printed text.
Issue 4: Using <seg>
37The element <seg> marks arbitrary segments within a text. It is designed for the encoder to mark any segmentation of interest.[12] The attribute–value pairs described in Case 2, issue 1: Using <ab> could be applied to <seg>. Thus, a possible encoding of the field postcard might be done as follows (simplified, deletions by sender not encoded):
<ab>
<seg type="pre-printed">Absender:</seg>
<seg type="handwritten">Vizewachtm. Marc</seg>
<seg type="handwritten">Galde<lb/>Fuchs</seg>
<seg type="pre-printed">Armeekorps<lb/>Division</seg>
<seg type="handwritten"><lb/><lb/>Ersatz</seg>
<seg type="pre-printed">Regiment No<lb/>Bataillon<lb/>Abteilung</seg>
<seg type="pre-printed">Kompagnie<lb/>Batterie<lb/>Eskadron<lb/>Kolonne</seg>
<seg type="pre-printed">Besondere Formationen: (Flieger, Funker usw.)</seg>
<seg type="handwritten">Schilling der 1. bayr. Feld-Art. Rgt. Leichte-Mun.
Kol.</seg>
</ab>
38There is a clear advantage compared to the usage of <ab>: In the TEI description of <seg>, it is specifically stated that the encoder is free to define his or her own segments of text. But again, as in issue 1: using <ab>, there is no convention in TEI to use @type in order to categorize pre-printed, typed and handwritten text. In addition to that, <seg> is an inline element and therefore cannot be used in the same way as <ab>, for example. The necessity to enclose <seg> with a block element might be problematic.
Issue 5: Using <handShift>, and proposal of new element <formShift>
39Another possible solution is the use of <handShift>. This turns out to cause problems regarding the definition of <handShift> in the TEI Guidelines:
<handShift> marks the beginning of a sequence of text written in a new hand, or the beginning of a scribal stint.
(https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-handShift.html)
40As we do not only deal with the shift between different hands but between a hand and a pre-printed form or machine-written part and pre-printed form, the use of <handShift> does not cover all these possible shifts and is, therefore, not an option.
41This is why we propose a new element <formShift>. This new element could then be used at the point of transition from pre-printed text to non-pre-printed text and vice versa. To indicate these different shifts, we would recommend the attribute type with the predefined values handwritten (shift from pre-printed or typed to handwritten), typed (shift from handwritten or pre-printed to typed) and pre-printed (shift from handwritten or typed to pre-printed). Compared to the previous cases, we would have an element created specifically for the task of describing such shifts. The type attribute would then have the sole and specific function to indicate the shifts.
42The description of how the pre-printed parts look like could be encoded in <layoutDesc> as part of <objectDesc>: For example 4, the <layoutDesc> might look like this:
<objectDesc>
<layoutDesc>
<p>Turned 90 degrees to the left, there is pre-printed text combined with
dotted lines where handwritten entries were made.</p>
</layoutDesc>
</objectDesc>
43Here is a possible solution for example 4, using the suggested element <formShift> (simplified, deletions by sender not encoded):
<objectDesc>
<layoutDesc>
<p xml:id="pre-printed">Turned 90 degrees to the left, there is
pre-printed text combined with dotted lines where handwritten entries
were made.</p>
</layoutDesc>
</objectDesc>
<!-- [...] -->
<div corresp="#pre-printed">
<p>Absender: <formShift type="handwritten"/>Vizewachtm. Marc <lb/>Galde
<lb/>Fuchs <formShift type="pre-printed"/>Armeekorps <lb/>Division
<formShift type="handwritten"/>
<lb/>
<lb/>Ersatz <formShift type="pre-printed"/>Regiment No
<lb/>Bataillon<lb/>Abteilung <formShift type="handwritten"/>
<lb/>
<lb/>
<formShift type="pre-printed"/>Kompagnie <lb/>Batterie <lb/>Eskadron
<lb/>Kolonne </p>
<p> Besondere Formationen: (Flieger, Funker usw.) <formShift type="handwritten"/>Schilling der 1. bayr. Feld-Art. Rgt.
Leichte-Mun. Kol.</p>
</div>
44The attribute-value pair corresp="pre-printed" would indicate the linking between the pre-printed text and the description in the meta data.
Notes
- [1]For this and the discussion of encoding letterheads see the TEI-L Mailinglist: http://tei-l.970651.n3.nabble.com/correspondence-encoding-problems-letter-headings-td4029408.html.
- [2] Chapter 11.6 "Headers, Footers, and Similar Matter" of the TEI Guidelines.
- [3]Encoding example (slightly changed) taken from http://tei-l.970651.n3.nabble.com/correspondence-encoding-problems-letter-headings-td4029408.html.
- [4]Letter from Johnny Cash to Saul Holiff, 6 June 1961: https://exhibits.library.uvic.ca/spotlight/holiff/catalog/11-12904. Another example for writing paper with letterhead and footer is the letter from Eugene Belmont to Harry Ault, 2 July 1932: https://digitalcollections.lib.washington.edu/digital/collection/pioneerlife/id/8634/.
- [5]https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-opener.html, and https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-closer.html.
- [6]https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-head.html.
- [7]http://tei-l.970651.n3.nabble.com/correspondence-encoding-problems-letter-headings-td4029408.html.
- [8]https://tei-c.org/release/doc/tei-p5-doc/en/html/FT.html#FTGRA.
- [9]Cf. the definition of <support>: "<support> contains a description of the materials etc. which make up the physical support for the written part of a manuscript or other object" https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-support.html.
- [10]https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-ab.html.
- [11]E.g. https://doi.org/10.7925/drs1.ivrla_4071.
- [12]https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-seg.html.
Bibliography
- TEI Consortium, ed. 2019. ‟Correspondence Description.ˮ In TEI P5: Guidelines for Electronic Text Encoding and Interchange. Version 3.6.0, 63–65. https://www.tei-c.org/release/doc/tei-p5-doc/en/html/HD.html#HD44CD.Zotero
- TEI Consortium, ed. 2019. ‟Headers, Footers, and Similar Matter.ˮ In TEI P5: Guidelines for Electronic Text Encoding and Interchange. Version 3.6.0, 419–420. https://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHSK.Zotero