Text Directionality Workgroup

Text Directionality Workgroup
This page will summarize the evolving work of the Text Directionality Workgroup, tasked by the TEI Council with developing a new section for the Guidelines on recommendations for encoding a variety of textual features related to text directionality and orientation. The related SourceForge ticket is https://sourceforge.net/p/tei/feature-requests/342/.

MDH made a presentation to the TEI Council on this topic during the April 2013 Council meeting in Providence.

Workgroup Members

 * Martin Holmes (TEI Council)
 * Deborah W. Anderson (Unicode Consortium)
 * Robert Whalen (Northern Michigan University)
 * Marcus Bingenheimer (Temple University)
 * Stella Dee (King's College, London)

Order of Tasks

 * Enumerate textual features to be covered
 * Collate existing standards and recommendations and relate them to features
 * Identify any gaps which might require new TEI elements or attributes
 * Outline the new section
 * Write the first draft for consideration by Council
 * Identify other places in the Guidelines where information or links need to be included

Mailing List
The group has a mailing list provided through Brown University at http://listserv.brown.edu/archives/cgi-bin/wa?A0=TEI-DIR-WG.

Notes from discussions

 * We agree (so far) that we would like to distinguish between two distinct types of phenomena: "true" text directionality (such as that found in language such as Japanese written vertically ttb with lines sequence rtl -- and "transformational" features, in which text written in any direction is rotated or written along a path. Our proposal will have to cover both of these phenomena, and provide for cases in which they interact, but they will probably be handled by different mechanisms.


 * We agree that the ITS specification is rather a red herring. Its primary concern is translation rather than text representation, and its provisions for directionality are sparse.


 * We agree that the CSS Writing Modes draft provides the best descriptive introduction to directional phenomena. The general consensus is that we should base our analysis of the phenomena on CSS Writing Modes, and probably base our recommendation on its properties and values, expressed using the TEI @style attribute.


 * We agree that the CSS Transforms draft provides the best approach to describing 2D and 3D rotation, skewing, and similar transformational features, and we will provide some simple examples showing how to use these features, and how they might interact with true directionality features.

If we do base our recommendation on the properties and values specified in CSS Writing Modes, then we have three possible approaches in our recommendation with regard to text directionality:


 * 1) We could recommend the creation of multiple new attributes, one for each property in CSS Writing Modes. This would enable us to add more attributes if there are features we want to describe that are not actually handled by CSS Writing Modes.
 * 2) We could recommend the creation of a single attribute, e.g. @cssWritingMode, whose value could be any valid combination of the CSS Writing Modes properties and values (in other words, its content would be a CSS ruleset constrained only to the properties relevant to writing modes).
 * 3) We could recommend that people use the existing global @style attribute, which is already available for CSS code (although it is not tied to CSS). This would enable users to combine CSS Writing Mode features with other CSS code which applies to the same element.

No. 1 seems too complicated; we'd end up with lots of new attributes, whose values would inevitably need to be combined anyway during any rendering process.

No. 2 is attractive in the sense that it keeps text directionality features separate from other CSS-specified features, and would allow the user to combine writing mode information with a use of @style which didn't happen to use CSS.

No. 3 seems the most attractive in that it's very simple, and involves no change to the existing TEI infrastructure at all; we just need to explain and illustrate how to use the properties, and point users at the W3C specification. MB points out that we are thereby assuming that @style is using CSS3 (since Writing Modes is not available in early versions of CSS); it would therefore be helpful if the styleDefDecl element were able to specify not only @scheme="css" but also the version (perhaps @schemeVersion="3") for clarity's sake. However, it appears that since CSS is now modular, it may not be possible to specify a global CSS level and stick to it, since a module defined in level 3 may be used alongside one which is only available in level 4.

Examples, constructed and from primary sources
This section collects together some examples which our discussion can reference. We aim to collect useful examples of some straightforward cases, but also of some edge cases which our proposal must be able to handle. Some of these may be used as examples in a final draft of the new section of the Guidelines. These are listed in no particular order.

Text directionality

 * Wikipedia has some good examples of Boustrophedon (alternate lines running in different directions, with glyphs also flipped horizontally for rtl lines).
 * Ancient Berber is an example of a script written bottom-to-top, with lines right-to-left.
 * This Berber inscription also incorporates rotation, so we could demonstrate the combination.
 * Rongo Rongo (Easter Island, reverse boustrophedon)

Rotation

 * Rotation along X axis: [[File:Rotation_on_x_axis.png‎]] "tei-c.org" 180 deg: "ʇǝı-ɔ˙oɹƃ"
 * Rotation along Y axis: [[File:Rotation_on_y_axis.png‎‎]]
 * Rotation along Z axis: [[File:Rotation_on_z_axis.png‎]]


 * Easter Wings is a good real-world example of rotation along the z axis.
 * Arabic text written along a circular path (a roundel).
 * The Phaistos Disc (spiral writing)
 * Ogham (clockwise from bottom left)

Useful documents

 * UTR 50, Unicode Properties for Horizontal and Vertical Text Layout
 * Forum for UTR 50
 * UAX 9, Unicode Bidirectional Algorithm
 * Proposed update to UAX 9 for Unicode 6.3
 * Unicode BIDI forum
 * UTR 20, Unicode in XML
 * What you need to know about the bidi algorithm and inline markup (W3C)
 * Unicode controls vs markup for bidi support (W3C)
 * CSS Writing Modes
 * CSS vs Markup in XHTML

Other notes
Deborah points to four new bidi isolate characters to be added to Unicode (probably 6.3), and quotes this description:

HTML/CSS recently introduced “bidirectional isolates” to improve handling of bidirectional text in HTML. However, this new technology does not provide a means to solve the bidi issues in non‐HTML documents or when copying and pasting HTML into plain text. This proposal requests four format characters that can be used to support formatting of bidirectional text in non‐HTML documents and plain text, in a way which can be interoperable with the mechanisms used by HTML/CSS for markup.

This is in addition to the five bidi codepoints (LRE, RLE, LRO, RLO, and PDF). They are described in proposed update to UAXZ #9.

Preliminary drafts of Guidelines sections
Early drafts will be presented here for discussion and editing.

Introduction
Scripts used for writing human languages vary not only in the glyphs they use, but also in the direction in which these glyphs are to be read. The majority of modern languages are written from left to right within the line, and have their lines stacked from top to bottom vertically (English, Russian, Greek), but there are several widely-used scripts which run right-to-left (Arabic, Hebrew), while also stacking lines top-to-bottom. Some east Asian languages such as Japanese and Chinese can be written with the same directionality as English, but are often also written from top to bottom within the line, with their lines sequenced from right to left. There are a few cases of bottom-to-top writing, such as Ancient Berber, and some Ogham inscriptions; there are even instances of writing which changes direction on alternate lines (boustrophedon, discussed in detail below).

When a language or script can be arranged in two or more different directions, there are often other consequences arising out of the choice; for example, when Japanese is written horizontally, the Unicode character U+3001, the "ideographic comma", is used, whereas in vertical writing an alternative glyph, U+FE11, may be used to ensure that the comma appears in the correct position relative to the surrounding glyphs. In addition, scripts which normally have a single directionality (such as English) may be written in a different direction in the context of another language (English words inserted into vertical Chinese text, for example), or in response to layout constraints such as those imposed by a complex table, in which column or row labels may be written vertically to make the most effective use of available space.

Horizontal directionality
The directionality features of scripts, and the consequences arising out of them, are generally referred to as "writing modes". For many documents encoded in TEI, there may be no need to encode any information relating to writing mode, because it will be obvious. Modern printed texts in most European languages, for instance, may be expected to use left-to-right/top-to-bottom directionality; Arabic or Hebrew texts are expected to run right-to-left/top-to-bottom. Even in the case of many "mixed mode" documents (documents in which languages or scripts with different writing modes are mixed together), it may not be necessary to be explicit about directionality. Consider the case of an English text containing a few Arabic words--what is termed a "bidirectional" text:

Since Arabic is never written from left to right, we can assume that the Arabic glyphs are to be read in that direction, even if they are in the context of a left-to-right English sentence. In fact, most codepoints in the Unicode standard have a specific directionality setting which helps any rendering engine to determine how they should be ordered. The Latin glyph "a" has a bidirectionality setting of strong left-to-right; the Hebrew א (alef) is strongly right-to-left. Other glyphs have weak or neutral settings because of the contexts in which they may appear. The Unicode Bidirectional Algorithm (http://www.unicode.org/reports/tr9/) provides a complex series of rules enabling user agents to render mixed-mode texts with predictable and reliable results, based on the bidirectionality class values of their glyphs.

In many mixed-mode texts, though, the Bidi Algorithm may not give the desired results. To deal with this, Unicode provides a set of "directional formatting characters" (http://www.unicode.org/reports/tr9/#Directional_Formatting_Codes), which are additional codepoints whose only function is to signal to a user-agent that a specific directionality setting should be turned on or off. These can be inserted into a text to influence the outcome of the bidirectional algorithm. However, in the case of documents encoded in XML, the W3C explicitly advises that markup rather than directional formatting characters should be used ("In (X)HTML and XML do not use the paired Unicode bidi formatting code characters where equivalent markup is available," http://www.w3.org/International/questions/qa-bidi-controls). We concur with this recommendation, and the remainder of this section and the next provide a set of encoding strategies for handling text directionality without the use of directional formatting characters. The approach we recommend is based on two external specifications, in line with our normal practice of incorporating existing standards where they are available and appropriate. Those specifications are the CSS Writing Modes module (http://dev.w3.org/csswg/css-writing-modes/) and the CSS Transforms module (http://www.w3.org/TR/css3-transforms/). Since (at the time of writing) neither of these modules has yet reached the stage of a Recommendation, the advice offered below should be regarded as provisional, and you should check your usage of the properties concerned against the current version of each specification where possible.

[The next section should provide an example of this: SD is working on providing one. For instance, if we imagine a run of Hebrew embedded within English, terminating not with a Hebrew period but an English colon (which resembles it), the directionality wrapper would be essential to clarify that the colon is not part of the English run. Even better would be an example in which a  element terminates an RTL run; here the markup metacharacters (which are intrinsically LTR) intervene between the rest of the RTL run and the final glyph.]

Vertical writing modes
So far, we have looked only at left-to-right and right-to-left text running horizontally, using the "direction: ltr|rtl" property. However, there are many scripts and languages which are written vertically (mostly top-to-bottom, but with a few unusal examples running bottom-to-top, as we shall see below). Handling vertical directionality requires the use of another CSS property, the writing mode:

The values for this property include two components: "horizontal" or "vertical" specifies the inline writing direction, while the second component specifies the direction in which lines in a block, and blocks in a sequence may be arranged: from top to bottom (as in most European languages, in which lines and paragraphs are arranged from top to bottom on a page), from right to left (as in the case of Japanese, which we will see below), or left-to-right (e.g. Mongolian). This example shows a Japanese haiku poem transcribed first in Japanese, then in Romaji (Japanese in Latin script), and finally in an English translation.



Note: for the sake of simplicity, the indenting of lines in the vertical Japanese has been ignored in this encoding, since this section focuses on language and writing mode issues. The Japanese transcription has "writing-mode: vertical-rl", which is required because Japanese may be written either in this mode or horizontally. The transcription in Romaji has @xml:lang="ja-Latn" (Japanese written in Latin script) and has a horizontal writing mode.

When Japanese is written vertically, the glyph orientation remains the same as when it is written horizontally. In other words, glyphs are not rotated (although as noted above some different glyphs may be used for some characters the two orientations; punctuation for instance needs to be positioned differently in vertical versus horizontal text). In other cases where text is written vertically, though, glyphs may be rotated. This example is a fragment from a table of information about agricultural development on Vancouver Island, written in 1855:



Four subheading cells in this fragment contain English text, written vertically, bottom-to-top, to conserve space on the page. This is not a "native orientation" for English; readers would not find it easy to read this text, and might be inclined to rotate the page in order to read it in a more natural way. To describe this sort of phenomenon, we can use the text-orientation property:

For full details on this property, we refer the reader to the CSS Writing Modes specification. For the moment, we will make use only of the "sideways-left" value, which "causes text to be set as if in a horizontal layout, but rotated 90° counter-clockwise." We might encode the four cells containing vertical text like this: