encoding of pre-printed parts in correspondence

[sabineseifert]

On telegrams and postcards, there are often pre-printed parts. A proper markup of these pre-printed parts in order to distinguish these from handwritten text is desirable as these text parts are in relation / have influenced the genesis of the handwritten text.
E.g. see here example 4 https://encoding-correspondence.bbaw.de/v1/pre-printed-parts.html#c-3-1 on the left side of the field postcard.

There should be recommendations, encoding examples and some prose in the Guidelines.

A discussion at a workshop on encoding correspondence resulted in the article "Pre-printed parts: Letterheads and forms", in which serveral possibilities are being discussed (with examples) and to which I will refer below.

How to encode such pre-printed parts of texts?

1. Using <ab> https://encoding-correspondence.bbaw.de/v1/pre-printed-parts.html#c-3-1

• e.g. with attributes type="pre-printed", type="handwritten", type="typed"
• but there is no such convention of using attribute 'type' like this in TEI
• too unspecific?
• there may be cases in which pre-printed parts express date or location and belong in <opener> but <ab> is not allowed there

2. Using <fw> https://encoding-correspondence.bbaw.de/v1/pre-printed-parts.html#c-3-2

• tag abuse? pre-printed parts need not be a running head but rather occur on a single page and are not a continuous feature
• e.g. with attributes type="pre-printed", type="handwritten", type="typed"
• but again: no such convention of using attribute 'type' like this in TEI

3. Using <seg> https://encoding-correspondence.bbaw.de/v1/pre-printed-parts.html#c-3-4

• is inline element and necessity to enclose it with a block element might be problematic
• e.g. with attributes type="pre-printed", type="handwritten", type="typed"
• but again: no such usage convention of attribute type like this in TEI

4. Using <handShift>, or introduce new element e.g. <formShift> https://encoding-correspondence.bbaw.de/v1/pre-printed-parts.html#c-3-5

• contrary to definition of <handShift>, we here have shifts not just between different hands but between hands, pre-printed forms, and typed text (with typewriter)
• maybe introduce new element like <formShift> to mark the points of transition? with attribute 'type' and values like pre-printed, handwritten, typed

[sydb]

@sabineseifert, could you comment on the differences between this and #2457? (My instinct is that a pre-printed letterhead is a subset of what is discussed on this ticket.)

[npcole]

@sydb What about pre-printed forms or other such items? Do we need a more generic approach than just letterhead?

[timofruehwirth]

How do you feel about using @hand (instead of @type) for indicating writing technologies (handwritten, typed, pre-printed)?

[sydb]

As mentioned on #2457, my first instinct is to use @src to differentiate pre-printed from authorial content. I think it would be a bit of a hack to use @hand, but it is not crazy. (Certainly a human hand types on the typewriter, right? :-)

But as @hand is to <handShift>, seems to me a @form (or whatever) attribute could be invented to be parallel to the suggested <formShift>. On the other hand, is there any theoretical difference between form[at] and rendition? I.e., is pre-printed vs typedwritten vs handwritten a subset of @rend|@rendition?

[sydb]

WARNING — this comment apparently belonged on #2195, not here.

Implemented in a branch.
See the tagdoc and the prose, or try out the (lame) exemplar schema.

(Note to future readers of this comment — as you might infer from the “temp/” in the URLs, above, those pointers are likely to disappear, especially if & when this idea is either discarded or included in TEI P5 by the TEI Council.)

[bwbohl]

Thanks for openin this issue. What you describe are issues that many of the projects involved in the recent TEI-MEC conference panel on Materiality in editions of 20th-century paperbound correspondence are facing, too. Unfortunately, due to other obligations, I didn’t make it to the SIG Correspondence meeting, though…

Although my thoughts on the issues raised were correspondence-centered so far. Nevertheless, in light of @npcole’s comment, I think a general approach for handling preprinted material might be favorable.

N.B. A special cross-over case of forms and correspondence might be telegrams!

[sabineseifert]

One might consider pre-printed parts and letterheads quite close but semantically they constitute two different phenomena.

• Pre-printed parts can be about anything (forms to fill out etc.) whereas letterheads are mainly restricted to information about the sender/place of sending (yes, they also might have sth. to fill out, eg. place is printed and date is added by hand).
• Pre-printed parts can occur in any type of documents whereas letterheads belong to correspondence materials (there are always exceptions, e.g. using a letter with a printed letterhead just for scribbling down some notes).
• Letterheads are a subcategory of pre-printed parts but not the other way around.

And yes, we need a generic approach of encoding pre-printed stuff and we need a recommendation for the case of letterheads.

Using @src to differentiate pre-printed from authorial content sounds interesting.

[sabineseifert]

It seems reasonable to consider all three things together:

1. letterheads as special case of pre-printed parts (ticket encoding of letterheads #2457),
2. (smaller) pre-printed parts (this ticket), and
3. bigger structures of pre-printed parts like forms, questionnaires etc. (with blank spaces to fill out, with checkboxes etc.)

(and not to have different solutions for each).

See comment here: #2457.

[raffazizzi]

F2F in Buenos Aires. Action on @joeytakeda to draft a new element for parts to fill out. See also discussion on #2457