With the current recognition, the "style" features could support indeed in principle at least italic, bold, superscript/subscript.

The TEI guidelines introduce <hi> to encode "graphically distinct" text and there is no constraint on the values, see here. We often see values space-separated (for example <hi rend="bold italic superscript">).

In TEI, there's also <rendition> element which uses CSS, which might be more predictable and would not required to further customize the XML schema.

I think what's complicated are the relations and the possible clash with other structures/tagging.

when this style information should be ignored: For instance a reference marker is often in bold or a superscript number. But the logical "reference" structure is already captured by the <ref> labeling and there is no point in keeping rendering information here. The <hi> is only relevant to text without any other explicit other logical mark-up. The only exception I think would be superscript/subscript inside a formula.
to maintain hierarchical structures: The <hi> element would be an inline annotation (like <ref>) so it is always under structure tags like <p> or <s>. This is indeed complicated for sentence segmentation, because the sentence segments are introduced after the initial serialization, directly on the TEI objects (this was to simplify the serialization! working with a tree structure ensures that we have well-formed XML at the end). The <hi> tags should be manageable as the <ref> tags in segmentIntoSentences - except if the bold/italic/etc covers more than the sentence. If a highlight style to be labeled covers more than the current sentence, we would need to close it with the end of the sentence, and re-open it in the next sentence.

Sub/superscript are displayed as plain text characters in the TEI output #160

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions