• Type: Sub-task
• Component: javafx
• Sub-Component: controls

• Priority: P3
• Status: Closed
• Resolution: Fixed

• Submitted: 2012-08-14
• Updated: 2015-06-16
• Resolved: 2013-01-04

JDK 8
8Fixed

Verified on 8.0b114 05-11-2013 Additional changeset: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2faead8d97aa Some issues still remain before this can be considered finished. 26-12-2012 Changeset for TextField/PasswordField: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/45835ed4cac5 19-11-2012 Right, note that we will need to add that to the Text node, I was thinking of calling the new enum TextDirection and have the following options: LTR, RTL, AUTO. Same as the web. In addition, we could add LEAD (alias to LEFT) and TRAIL (alias to RIGHT) to TextAlignemnt. 16-08-2012 Thanks. I think I have my answer, even though I didn't use the correct terminology and assumptions in my question. :) So it appears that we do need a text content alignment separate from the UI alignment for the text and label controls. The content alignment can have HPos values like LEFT, RIGHT, LEADING, TRAILING, AUTO. The default value is probably LEADING, but it could conceivably be AUTO instead. 15-08-2012 You said everything is LTR oriented (thus I assume that LTR direction was explicitly set on the TextField). In that case LEAD is always LEFT, does not matter if the user inputs Hebrew or English. Try this HTML: LTRL<input dir="ltr" type="text"></input> RTL<input dir="rtl" type="text"></input> AUTO<input dir="auto" type="text"></input> The first case the text is always aligned on the left. The second case the text is always aligned on the right. The last case (auto) it depends, it starts left aligned (with the caret on the left), if the first char typed is English, node text remains left aligned. If the first char is hebrew the text and the caret jump to the right-edge. The ellipsis is a different case and gets handled by the bidi algorithm, regardless of the base direction, if the "..." (which is neutral) is at the end, and it is preceded by hebrew (which is strong RTL) then the "..." is resolved to RTL and place to the right. 15-08-2012 text alignment and text run direction are two distinct concept. So in your example, even if Hebrew was typed in the TextField, the text should be left aligned, but as the user types, the text grows from right to left. 15-08-2012 [Edit: changed "right edge" to "left edge" in the last sentence.] Let me use an example to try to clarify my original question. Assume an app that is running in English on an English locale. A TextField has a promptText, like "Name". Everything is LTR oriented: the prompt is on the left and so is the caret. Let's also say that the TextField.alignment has a value like CENTER_LEAD. Then the user starts typing a name using a Hebrew keyboard. The entire string is entered in Hebrew. My question is, should the TextField detect the new direction from the Text node and change the alignment for the text and the caret? If so, then this would be a separate alignment property from the main one that is used for prompt placement, CSS styling, etc. The same question applies to Label. If everything is assuming English, but the Label receives an RTL string, does it then change its default alignment and move the ellipsis truncation to the left edge? 15-08-2012 Default direction: I agree with Naoto on this one. When the application ships it knows what language bundle it uses and it should set the default direction accordingly (usually in a property file,e.g .ini). This will ensure the application with English strings renders correctly on a Hebrew windows for example. For a default value, we can use locale (which is bad, since will cause every bidi-unaware/english application to come up wrong on a RTL locale ) or "default" (defined by the direction of the first strong character). Personally I'm fine using LTR, it will be correct 99% of the time. Alignment: To tied it to direction means that TextAlignment.LEFT visually is on the right edge, and TextAlignment.RIGHT is on the left edge. Note that some libraries will add constants like TextAlignment.LEAD (=left) and TextAlignment.TRAIL (=right) for conveniency. Personally I think this make sense when the entire layout happens from right to the left. For example, the HBox starts filling from the right to the left, etc. Complex expressions: (note, this is where bidi gets complicated - and we can decide to deal with it in the future) What if you want use a TextField to enter a URL, file path, regular expression ? Example http://wiki.eclipse.org/index.php/New_Bidi_APIs more info https://bugs.eclipse.org/bugs/show_bug.cgi?id=179191 https://bugs.eclipse.org/bugs/show_bug.cgi?id=183164 15-08-2012 [Added text team to discussion] So we need to think about whether we need a content RTL property which is in some ways separate from the control's RTL property. The Text node may be able to provide a primary direction based on some logic, to be used as a default for the content. But how does this play with the control's locale based default, and how does explicitly setting one of them affect the other? 15-08-2012 First of all, I don't think the default line direction is tied to the locale. Even in Arabic locale, an application that provides English translation should align from Left-To-Right. Now, I remember in Swing that the default alignment is tied to the component orientation, not derived from the text content itself. I am not sure this is the preferred behavior but reasonable to me. We need to ask UX team for advice. If we prefer the default alignment depending on the text content, Unicode Consortium defines precise logic to determine how the content should be rendered. (I believe Text node should handle this in itself). 14-08-2012 A question to the experts. If I'm displaying an Arabic string in a text field under the English locale, what should the default horizontal alignment be? And where does truncation happen? If this determination of a beginning and an end of the line depends on the content rather than on the control's locale, then what happens with mixed bi-di text? Is there a concept of a "primary" direction? 14-08-2012