Special characters: inverted characters
Abstract
Treatment of characters which are printed upside down or in another alternative orientation in the source
Encoding Instructions (new P5 version)
The WWP collection includes many examples of characters printed upside down; this occurs most frequently with n and u, but also occurs with other characters.
The WWP encodes inverted characters on the level of the word, using an entity reference for the letter in question, and the elements choice, sic and corr, eg:
<choice><sic>m&inverteda;n</sic><corr>man</corr></choice>
Examples
In cases where an inverted letter is printed, and the correct reading is the same letter right-side up, we encode:
morld (where the m is an inverted w)
<choice><sic>&invertedw;orld</sic><corr>world</corr></choice>
Similarly, in cases where an inverted letter is printed, and the correct reading is some other letter, we encode the letter with an entity reference and a sic element.
mother (where the m is an inverted w)
<choice><sic>&invertedw;other</sic><corr>mother</corr></choice>
The only difference between these two cases is that in the previous case, the correct reading requires the inverted letter to be interpreted as itself, turned rightside up, whereas in this case, the correct reading requires the inverted letter to be interpreted as another letter which happens to resemble it.
In cases where a rightside up letter is printed, and it appears that what was intended was that the letter be used upside down as a substitute for some other letter, the WWP expresses agnosticism about causes and simply encodes the letter that appears as a typographical error, using SIC
Her wother nursed her … (rightside-up “w” probably
intended to substitute for an “m”, but inserted upside
down…)
<choice><sic>wother</sic><corr>mother</corr></choice>
In cases where a letter has been printed which might be rightside up or upside down, in the absence of evidence to the contrary, we assume that it is rightside up. The encoder should compare it carefully with other letters in the text to see whether similarities or differences might indicate exactly which letter is printed. If (as might be the case with n and u) two letters look exactly the same (except for the inversion), the encoder will follow the assume it’s rightside up rule. If, however, there are slight differences (if the u has a longer tail, for instance) these can override the assume it’s rightside up rule.
So in the case of the word trnth (which we assume should read truth): If the two letters look identical:
<choice><sic>trnth</sic><corr>truth</corr></choice>
If the two letters look different, and we’re sure it’s a “u” upside down:
<choice><sic>tr&invertedu;th</sic><corr>truth</corr></choice>
Rationale & Reasoning
The reason for this apparent redundancy is that neither the element nor the entity reference by itself is sufficient to guarantee the appropriate output in all cases. If an entity reference is used alone, then we will have problems in cases where two inverted letters should be mapped to two different corrected readings, since both entity references must be resolved to the same character.
Our transcription strategy is founded on an encode what you see philosophy, independent of hypotheses about what the printer intended. Thus if a letter looks exactly like an n, even if it is in a place where a u should be, we encode it as an n and we do not try to imagine whether it could really be an inverted u. Similarly, if we see a letter which looks exactly like all the other ws in the text (except for being upside down), we encode it as an inverted w even if it is functioning in the text like an m.