John Jenkins wrote:
>I'm probably not the best one to respond, as I am not solidly in agreement
>with the decision. It's basically so that Unicode implementations that
>don't do bidi could still do Etruscan after a fashion, I believe.
Curtis Clark wrote:
>It is my understanding that scholars prefer LTR to fit in with Latin text.
>The glyphs are more easily recognizable to those familiar with the Latin
>alphabet when they are in their LTR orientation.
Yes, this is true for both Etruscan and Hieroglyphic, if the scholars write
in a Western language, because this eases interlinear transliteration,
word-by-word translation, etc.
Israeli or Arab scholars would probably prefer embedding these ancient
scripts in RTL, for exactly the same reasons.
Some other scholars may want to reproduce the actual directionality of the
corpus they are analyzing, for some other good reasons.
Let's imagine how all this would work, for Etruscan, on two hypothetical
"Unicode enabled" word processors:
LTRwp. The typical Western application that does support bidi or complex
scripts. This kind of application is also so naive to have 1-to-1 mappings
between glyphs and characters. The font contains Etruscan, but has only
right-facing glyphs.
Doctor Westson uses this system to write a paper about Etruscan, in English.
BIDIwp. The typical RTL-enabled application that implements the Unicode
bidirectional algorithm or some equivalent higher-level protocol. It also
implements contextual shaping and glyph mirroring; the font contains
Etruscan, with both left- and right-facing glyphs.
Professor Al-Arabi uses this system to write a paper about Etruscan, in
Arabic.
Crossing the wp's with the 3 possible choices for directionality (LTR, RTL,
neutral), we have the following scenarios:
1) LTR + LTRwp. Etruscan is LTR. Doctor Westson is happy.
2) RTL + LTRwp. Etruscan is LTR. Doctor Westson is happy, until she
views her paper on Professor Al-Arabi's computer, to discover that the
Etruscan text is all swapped!
3) neutral + LTRwp. Etruscan is LTR. Doctor Westson is happy, and
she is also when she views her paper on Professor Al-Arabi's computer:
Etruscan remains LTR because it gets the direction of the surrounding text.
4) LTR + BIDIwp. Etruscan is LTR. Professor Al-Arabi is *not*
happy! He has to manually add bidirectional overrides to see Etruscan
properly. If he forgets to do so, some part of his paper will read wrong.
5) RTL + BIDIwp. Etruscan is RTL. Professor Al-Arabi is happy.
6) neutral + BIDIwp. Etruscan is RTL. Professor Al-Arabi is happy.
As you see, cases 2 and 4 miss the user's expectations in a way or another,
so both LTR and RTL are not appropriate.
The neutral directionality (cases 3 and 6) always meets the basic user
expectation: having Etruscan in the same direction as the user's language
*automatically*.
There could also be a 3rd scholar (Professor Chang) who is so pedantic to
use both LTR and RTL Etruscan in her paper. Of course, she needs BIDIwp
software to do this. And, willy or nilly, she has to use bidirectional
controls.
If Etruscan is neutral, she will only need to add one LTR and/or RTL mark
(200E or 200F) in each Etruscan paragraph or word. If Etruscan has a strong
directionality, she will need to enclose text in directional overrides (200D
or 200E ... 200C). Notice that, while any bidi systems supports directional
marks, only the most sophisticated systems implement directional embedding
and overrides.
All summed up, why should Etruscan (or other scripts with ambiguous
directionality) be cast in an artificial RTL or LTR bidi class?
Ciao. Marco
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:58 EDT