Text Directionality Draft - Revision history

Lou at 12:47, 28 April 2014

2014-04-28T12:47:40Z

Lou: /* Horizontal directionality */

2014-04-26T15:20:19Z

‎Horizontal directionality

Lou: /* Vertical text with embedded horizontal text */

2014-04-26T15:11:29Z

‎Vertical text with embedded horizontal text

Lou: /* Writing Modes */

2014-04-26T14:58:42Z

‎Writing Modes

Lou: /* Writing Modes */

2014-04-26T14:55:03Z

‎Writing Modes

Lou: /* Writing Modes */

2014-04-26T14:54:22Z

‎Writing Modes

Lou: /* Horizontal directionality */

2014-04-23T11:05:54Z

‎Horizontal directionality

Mholmes: /* Caveats */

2014-04-22T22:13:34Z

‎Caveats

Mholmes: /* Horizontal directionality */

2014-04-22T22:08:54Z

‎Horizontal directionality

Mholmes: /* Vertical text with embedded horizontal text */

2014-04-22T22:02:18Z

‎Vertical text with embedded horizontal text

← Older revision		Revision as of 12:47, 28 April 2014
Line 1:		Line 1:
−	This ~~is a~~ preliminary draft of proposed sections for the TEI Guidelines, created by the [[Text Directionality Workgroup]]. Please ~~see~~ the associated [[Text Directionality Draft Questions]] document for some issues to think about before and after reading this draft, and feel free to respond there and to add new questions. There is also a [[Talk:Text_Directionality_Draft\|talk page]] for more informal discussion.	+	This preliminary draft of proposed sections for the TEI Guidelines, created by the [[Text Directionality Workgroup]] is now (28 April 2014) in the process of being transferred to the TEI svn repository where it will appear as a new section in file Source/Guidelines/en/WD-NonStandardCharacters.xml
		+
		+	'''Please do not make further changes here.'''
		+
		+
		+
		+	See the associated [[Text Directionality Draft Questions]] document for some issues to think about before and after reading this draft, and feel free to respond there and to add new questions. There is also a [[Talk:Text_Directionality_Draft\|talk page]] for more informal discussion.

	==Text directionality and transformation==		==Text directionality and transformation==

@@ Line 192: / Line 192: @@
 Mixed directionality is very common in languages such as Arabic and Hebrew, particularly when numbers (which are always given LTR) or phrases from other LTR languages are embedded, and it is quite unusual though not impossible for ambiguities to arise.
-[Would it be helpful to have another example presenting ambiguity arising out of the use of a g element at the end of a text run?] [how might a <g> element introduce ambiguity? only if the glyph or character concerned is vague about its directionality surely] [(MDH) A <g> element would normally be used for a glyph which has no Unicode representation; therefore it has no directionality per the Unicode character database; therefore its effect would be potentially disruptive. Imagine a case where a rtl text run ends with a weak-directionality character such as a period, followed by a <g> for a glyph which the encoder knows should represent an rtl character, but which isn't in Unicode, followed by a strongly ltr character.]
+[Would it be helpful to have another example presenting ambiguity arising out of the use of a g element at the end of a text run?] [how might a <g> element introduce ambiguity? only if the glyph or character concerned is vague about its directionality surely] [(MDH) A <g> element would normally be used for a glyph which has no Unicode representation; therefore it has no directionality per the Unicode character database; therefore its effect would be potentially disruptive. Imagine a case where a rtl text run ends with a weak-directionality character such as a period, followed by a <g> for a glyph which the encoder knows should represent an rtl character, but which isn't in Unicode, followed by a strongly ltr character.] [If the encoder knows that the glyph or character concerned has a strongly ltr character then they should use the &lt;charProp> element to document this fact within the &lt;glyph> or &lt;char> definition, as per http://www.tei-c.org/release/doc/tei-p5-doc/en/html/WD.html#ucsprops. If they want a rendering agent to deal with the character properly, they are at liberty to put a strongly ltr character as content for the &lt;g> ]
 ====Summary====

@@ Line 117: / Line 117: @@
 </syntaxhighlight>
-The rule <code>text-orientation: mixed</code> gives the expected orientation: "In vertical writing modes, characters from horizontal-only scripts are set sideways, i.e. 90° clockwise from their standard orientation in horizontal text. Characters from vertical scripts are set with their intrinsic orientation" ([http://www.w3.org/TR/2013/WD-css-writing-modes-3-20131024/#text-orientation CSS Writing Modes]). Since the default value for <code>text-orientation</code> is "mixed", this rule is not strictly required. However,  if the Indonesian glyphs (which are roman characters) had been set vertically, like this:
+The rule <code>text-orientation: mixed</code> specifies that "characters from horizontal-only scripts are set sideways, i.e. 90° clockwise from their standard orientation in horizontal text. Characters from vertical scripts are set with their intrinsic orientation" ([http://www.w3.org/TR/2013/WD-css-writing-modes-3-20131024/#text-orientation CSS Writing Modes]). Since the default value for <code>text-orientation</code> is "mixed", this rule is not strictly required. However,  if the Indonesian glyphs (which are roman characters) had been set vertically, like this:
 <div style="clear: both">&#160;</div>
@@ Line 124: / Line 124: @@
 then an encoding like the following could be used to make this explicit:
 <syntaxhighlight lang="xml">
@@ Line 140: / Line 139: @@
 </syntaxhighlight>
-The value <code>text-orientation: mixed</code> specifies that "characters from horizontal-only scripts are rendered upright, i.e. in their standard horizontal orientation. Characters from vertical scripts are set with their intrinsic orientation and shaped normally" ([http://www.w3.org/TR/2013/WD-css-writing-modes-3-20131024/#text-orientation CSS Writing Modes]).
+The rule <code>text-orientation: upright</code> specifies that "characters from horizontal-only scripts are rendered upright, i.e. in their standard horizontal orientation. Characters from vertical scripts are set with their intrinsic orientation and shaped normally" ([http://www.w3.org/TR/2013/WD-css-writing-modes-3-20131024/#text-orientation CSS Writing Modes]).
 <div style="clear: both">&#160;</div>

@@ Line 7: / Line 7: @@
 The scripts used for writing human languages vary not only in the glyphs they use, but also in the way (or ways) that those glyphs are arranged on the writing surface. For the majority of modern languages, writing is arranged as a series of lines which are to be read from top to bottom. Within each line, individual characters are frequently presented from left to right (English, Russian, Greek), but there are also several widely-used scripts which run right-to-left (Arabic, Hebrew). Writing in which the lines of glyphs are presented vertically and read from right to left is also often encountered, notably in older East Asian scripts (Sinitic characters, Japanese Kana, Korean Hangul, Vietnamese chữ nôm). In many cases, a language normally uses the same ''writing mode'' (we use this term to refer to the orientation of individual glyphs within a line and the order in which they should be read), but there are exceptions in which the same language may appear in different modes, for example either vertically or horizontally. East Asian scripts were traditionally written from top to bottom within the line, with their lines sequenced from right to left. Although modern Japanese, Chinese, and Korean are often written horizontally, the traditional vertical writing mode is still widely used. There are also comparatively rare cases of ancient scripts written with lines running left to right, each line being read top to bottom (Ancient Uighur, classical Mongolian and Manchu), or scripts such as Ogham where the writing direction is from bottom to top around the edge of an inscribed object.
-When different languages are combined, it is possible that different writing modes will be needed: for example, in Hebrew text, running right to left, sequences of Latin digits still run left to right. When different writing modes are available for the same language, it may be that different glyphs will be preferred when the script is used in different modes. For example, when Japanese is written horizontally, the Unicode character U+3001, the "ideographic comma", is used in preference to Unicode character  U+FE11, the vertical mode comma. This ensures that the comma appears in the correct position relative to the surrounding glyphs. Even for scripts which are usually written in exactly the same way, different writing modes may be encountered in particular contexts; for example when a language using Roman script is embedded within vertically organized Chinese text, it may sometimes be displayed in vertical and sometimes in horizontal orientation. The writing mode may also vary in response to layout constraints such as those imposed by a complex table, where column or row labels may be written vertically or diagonally to make the most effective use of available space, just as it may vary in response to the size and shape of the carrier in the case of a monumental inscription.
+When different languages are combined, it is possible that different writing modes will be needed: for example, in Hebrew text, running right to left, sequences of Latin digits still run left to right. When different writing modes are available for the same language, it may be that different glyphs will be preferred when the script is used in different modes. For example, when Japanese is written horizontally, the Unicode character U+3001, the "ideographic comma", is used in preference to Unicode character  U+FE11, the vertical mode comma. This ensures that the comma appears in the correct position relative to the surrounding glyphs. Even for scripts which are usually written in exactly the same way, different writing modes may be encountered in particular contexts; for example when a language using Roman script is embedded within vertically organized Chinese text, it may sometimes be displayed vertically and sometimes horizontally. The writing mode may also vary in response to layout constraints such as those imposed by a complex table, where column or row labels may be written vertically or diagonally to make the most effective use of available space, just as it may vary in response to the size and shape of the carrier in the case of a monumental inscription.
 For many, perhaps most, TEI documents there may be no need to encode the writing mode explicitly, even in so-called "mixed mode" texts containing passages written in languages which use different writing modes. Modern printed texts in most European languages, for instance, may be expected to use left-to-right/top-to-bottom directionality; while Arabic or Hebrew texts are expected to run right-to-left/top-to-bottom.  In a TEI document, language and script are explicitly stated in the markup using the attribute xml:lang (reference); this indication will usually imply a particular default writing mode.  Even where this attribute is not used, passages in different scripts will use different Unicode characters, and will thus imply a particular default writing mode.

@@ Line 5: / Line 5: @@
 ===Writing Modes===
-The scripts used for writing human languages vary not only in the glyphs they use, but also in the way (or ways) that those glyphs are arranged on the writing surface. For the majority of modern languages, writing is arranged as a series of lines which are to be read from top to bottom. Within each line, individual characters are frequently presented from left to right (English, Russian, Greek), but there are also several widely-used scripts which run right-to-left (Arabic, Hebrew). Writing in which the lines of glyphs are presented vertically and read from right to left is also often encountered, notably in older East Asian scripts (Sinitic characters, Japanese Kana, Korean Hangul, Vietnamese chữ nôm). In many cases, a language normally uses the same ''writing mode'' (we use this term to refer to the orientation of individual glyphs within a line and the order in which they should be read), but there are exceptions in which the same language may appear in different modes, for example either vertically or horizontally. East Asian scripts were traditionally written from top to
+The scripts used for writing human languages vary not only in the glyphs they use, but also in the way (or ways) that those glyphs are arranged on the writing surface. For the majority of modern languages, writing is arranged as a series of lines which are to be read from top to bottom. Within each line, individual characters are frequently presented from left to right (English, Russian, Greek), but there are also several widely-used scripts which run right-to-left (Arabic, Hebrew). Writing in which the lines of glyphs are presented vertically and read from right to left is also often encountered, notably in older East Asian scripts (Sinitic characters, Japanese Kana, Korean Hangul, Vietnamese chữ nôm). In many cases, a language normally uses the same ''writing mode'' (we use this term to refer to the orientation of individual glyphs within a line and the order in which they should be read), but there are exceptions in which the same language may appear in different modes, for example either vertically or horizontally. East Asian scripts were traditionally written from top to bottom within the line, with their lines sequenced from right to left. Although modern Japanese, Chinese, and Korean are often written horizontally, the traditional vertical writing mode is still widely used. There are also comparatively rare cases of ancient scripts written with lines running left to right, each line being read top to bottom (Ancient Uighur, classical Mongolian and Manchu), or scripts such as Ogham where the writing direction is from bottom to top around the edge of an inscribed object.
 When different languages are combined, it is possible that different writing modes will be needed: for example, in Hebrew text, running right to left, sequences of Latin digits still run left to right. When different writing modes are available for the same language, it may be that different glyphs will be preferred when the script is used in different modes. For example, when Japanese is written horizontally, the Unicode character U+3001, the "ideographic comma", is used in preference to Unicode character  U+FE11, the vertical mode comma. This ensures that the comma appears in the correct position relative to the surrounding glyphs. Even for scripts which are usually written in exactly the same way, different writing modes may be encountered in particular contexts; for example when a language using Roman script is embedded within vertically organized Chinese text, it may sometimes be displayed in vertical and sometimes in horizontal orientation. The writing mode may also vary in response to layout constraints such as those imposed by a complex table, where column or row labels may be written vertically or diagonally to make the most effective use of available space, just as it may vary in response to the size and shape of the carrier in the case of a monumental inscription.

@@ Line 173: / Line 173: @@
 ====Horizontal directionality====
-[Question MDH to LB: Why is this bit detached from the original horizontal text section above?]
+[Question MDH to LB: Why is this bit detached from the original horizontal text section above? Because he section above isn't specifically about horizontal texts only, though it uses one as an initial example]
 Returning to our previous simple example

@@ Line 277: / Line 277: @@
 ====Caveats====
-As with other parts of the CSS specification, the intended effect of CSS Transforms properties and values are defined with reference to a specific [http://www.w3.org/TR/CSS2/visuren.html Visual formatting model]; the language is designed to describe how an HTML document should be formatted. This is not, of course, the case for the TEI which lacks any explicit processing or formatting model, and attempts to define objects as far as possible without consideration of their visual appearance. As long as the properties and values from the CSS Transforms module are used as a convenient, well-specified descriptive language to capture features of a text, without any expectation of using them directly and reliably for rendering, this is not particularly problematic. CSS provides a useful and well-defined vocabulary to describe many aspects of the appearance of source texts, benefitting particularly from the clarity of definition provided by the specification. However, if there is any expectation of using this information to render a text in a predictable and accurate way, it will be essential to provide enough styling information throughout the document hierarchy to resolve all ambiguities with regard to size, positioning, block status, etc. before any element undergoes a transform operation.
+As with other parts of the CSS specification, the intended effect of CSS Transforms properties and values are defined with reference to a specific [http://www.w3.org/TR/CSS2/visuren.html Visual formatting model]; the language is designed to describe how an HTML document should be formatted. This is not, of course, the case for the TEI, which lacks any explicit processing or formatting model, and attempts to define objects as far as possible without consideration of their visual appearance. As long as the properties and values from the CSS Transforms module are used as a convenient, well-specified descriptive language to capture features of a text, without any expectation of using them directly and reliably for rendering, this is not particularly problematic. CSS provides a useful and well-defined vocabulary to describe many aspects of the appearance of source texts, benefitting particularly from the clarity of definition provided by the specification. However, if there is any expectation of using this information to render a text in a predictable and accurate way, it will be essential to provide enough styling information throughout the document hierarchy to resolve all ambiguities with regard to size, positioning, block status, etc. before any element undergoes a transform operation.
 <references/>