Opened 9 years ago

Closed 8 years ago

Last modified 6 years ago

#12367 closed defect (fixed)

textdir: control base text direction independently from GUI direction (form widgets)

Reported by: tomerm Owned by:
Priority: high Milestone: 1.7
Component: Dijit Version: 1.5
Keywords: bidi Cc: MARIAVIN@…
Blocked By: Blocking:

Description

Base text direction refers to the order of directional runs in a sentence. For LTR sentences (e.g., in English) the proper base text direction is LTR even if they include Arabic (or Hebrew, Urdu, Farsi) words, while for RTL sentences (e.g., in Arabic or Hebrew) the proper base text direction is RTL even if they include English words or numbers. Determining if a sentence is English or Arabic/Hebrew? is not always easy. For more detail, see section "Why do we need to control the base text direction" below. Let us review the sample sentence used above. Since this sentence is an Arabic/Hebrew? sentence, it has a right to left base text direction, the directional runs must be laid out on the line one after the other from right to left, giving (with each directional run bracketed with square brackets for clarity): .[united states][ EHT OT TNEW I ,][23][ SAW I NEHW]

The natural base text direction for Arabic, Hebrew or Urdu text is Right-To-Left, while for English text it is Left-To-Right. This natural text direction is inherent to the script used for the text and independent from the component direction (GUI mirroring mode) and from the user locale. Namely, even if the GUI of a product is not mirrored, bidirectional text originated by the end user (bidirectional text which the user directly or indirectly introduces and sees via the product's GUI) should be displayed according to its natural base text direction. The user should have control over document and paragraph base text direction independently of the component direction (GUI mirroring mode).

The base text direction of Bidi text affects its display. Let us consider how the following string (that we list in logical order, i.e. the order in which the text is pronounced) is going to be displayed when we change its base text direction:

hello world !

With Left-To-Right base text direction the string will be displayed as follows:

hello world !

With Right-To-Left base text direction the same string will be displayed as follows:

! hello world

Note that in the second case the exclamation mark appears on the left side of the string. Note also that the string will not be displayed as

! world hello

when the base text direction is RTL because even though the base text direction is RTL, consecutive English words always constitute a LTR directional run, so that each word is displayed LTR and the progression of words in the run is also LTR.

Why do we need to control the base text direction?

Why cannot the underlying platform automatically recognize the natural base text direction of typed/displayed text and enforce it appropriately? The algorithm used by platforms for rendering bidirectional text is the Unicode Bidirectional Algorithm (UBA). A human being seeing bidirectional text immediately recognizes its main language and thus can determine its natural base text direction. This is not so for a computer. When a piece of text includes words written in scripts of opposite directions, the computer cannot reliably determine which language is the main one.

To help the UBA properly prepare bidirectional text for rendering, it is required to give it the specification of base text direction. Unfortunately it is not feasible to attach metadata describing the base text direction to every string object. Consequently we are forced to make generalizations. For example, if users are expected to mostly use Arabic sentences within some application, the most natural base text direction for it is RTL. Why is it suboptimal to support only one base text direction? If we consider the case of an unmirrored GUI, the default base direction is LTR, which is not the natural direction for Arabic/Hebrew? text. Thus by default all products with unmirrored GUI are not capable of proper display of Arabic/Hebrew? text. On the other hand, for a mirrored GUI, the default base direction is RTL, which is not the natural direction for English text. Thus by default all products with mirrored GUI are not capable of proper display of English text. In Bidi markets, coexistence of English and Arabic (or English and Hebrew) data in the same product is a reality which must be supported properly.

It could seem that the contextual base text direction is optimal and that there is no need to have options for LTR and RTL. Having just one value for base text direction would avoid the need to specify a preferred base direction. One problem is that different platforms implement different defaults. Here are several examples:

  1. Windows enforces a default base text direction depending on the mirroring mode.
  2. Swing enforces contextual base text direction (for not-editable text only).
  3. Linux GTK enforces contextual base text direction (for both editable and not-editable text), thus Eclipse based on GTK on Linux supports only contextual base text direction.

As can be seen, there is inconsistency across platforms and technologies. Moreover, as was already mentioned, the choice of base text direction should be derived from the nature of the text handled by the user. Different users might deal with different types of text and consequently will require different base text direction settings.

Dojo does not support any control over base text direction independently from GUI direction.

Attachments (2)

DojoBTD_BidiSDD0_14February2011_PublicVersion.pdf (178.8 KB) - added by bill 9 years ago.
detailed spec
patch201102281739_Dojo-textDirFormWidgets.txt (152.9 KB) - added by bill 9 years ago.
patch file

Download all attachments as: .zip

Change History (14)

Changed 9 years ago by bill

detailed spec

Changed 9 years ago by bill

patch file

comment:1 Changed 9 years ago by bill

(In [24073]) Support for textdir attribute on widgets, for controlling text direction independently from GUI direction. See #12367 for explanation of text direction. GUI direction refers to things like positioning of a ComboBox's drop down arrow relative to it's input control.

This checkin provides textdir support for form widgets, plus inheritance of textdir attribute from ancestor nodes. I think there will be more checkins for other widgets.

Refs #12367 !strict. Patch from Maria Vinikov (IBM, CCLA), thanks!

comment:2 Changed 9 years ago by bill

(In [24076]) Remove trailing comma, breaks IE, refs #12367.

comment:3 Changed 9 years ago by bill

(In [24078]) Test fixes for mac, refs #12367. Patch from Maria Vinikov (IBM, CCLA), thanks!

comment:4 Changed 9 years ago by bill

(In [24137]) Fix for when ComboBox drop down direction when ComboBox textdir is changed dynamically. Refs #12367 !strict. Patch from Maria Vinikov (IBM, CCLA), thanks!

comment:5 Changed 8 years ago by bill

Resolution: fixed
Status: newclosed
Summary: Adding support for control over base text direction independently from GU Idirectiontextdir: control base text direction independently from GUI direction (form widgets)

Closing for 1.7, in 1.8 (or later) may be changes to support textdir for non-form widgets. That will be a separate ticket.

comment:6 Changed 8 years ago by bill

In [26067]:

parseonload shouldn't be set for robot test files, refs #12367.

comment:7 Changed 8 years ago by bill

In [26219]:

avoid spurious timeout failures, refs #12367

comment:8 Changed 7 years ago by bill

In [29988]:

fix spacing, refs #12367

comment:9 Changed 7 years ago by bill

In [30055]:

Fix a number of test file errors, especially around parsing:

  • Parser was being called twice, once automatically via parseOnLoad:true, and once manually during the test. It should only have been the latter.
  • Test wasn't waiting for parser to finish running.


Refs #12367

comment:10 Changed 7 years ago by bill

In [30056]:

Adding some debugging code into test file for when it fails, refs #12367

comment:11 Changed 7 years ago by bill

In [30058]:

increase timeout a bit, refs #12367

comment:12 Changed 6 years ago by Bill Keese <bill@…>

In 81a89c7b69b43a02e10e5999bdcb3f63faa0e56d/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 
Note: See TracTickets for help on using tickets.