Created attachment 60186 [details]
The visual order of the bidi-text in the dialog isn't consistent with the case in the document respectively.

pl->hdu: please have a look

Created attachment 60189 [details]
a suggested patch

This issue is not a problem: The difference between the text in the editfield and writer is that a writer 
paragraph uses the "BiDi default direction" (enable Tools->Options->LanguageSupport->EnableCTL to 
see&change the BiDi icons in the toolbars) whereas the editfield uses the "natural direction" (the first 
"BiDi-strong" character defines the default direction).

Unless text in an editfield and writer are set to the same default direction the order of the glyphs can 
easily differ.

Hi hdu,
The reason you describe is right. But for the example in my attachment, the
editfield should use LTR direction to layout bidi text in English UI. On windows
platform, OOo use uniscribe process bidi text, and the visual order in editfield
is consistent with the case in writer in default. 

Thanks. 

Created attachment 60268 [details]
On windows, the Arabic character is always at the left of English letters in editfield because the dialog direction is left-to-right with English UI, no matter the bidi text in sw is left-to-right or right-to-left. I think that is the correct behavior. O

It's really a defect on Linux system. I think it's better to behavior
consistently on every supported platform. Pls give more concerns. Thanks. 

> it's better to behavior consistently on every supported platform

Indeed, it is behaving differently on WIN -> analyzing

yanminjia->hdu: The patch I provided can work for this defect. But I'm not sure
if it would cause other problem.   

With the patch applied text would always be in "default-LTR" order even if just the opposite has been 
requested by upper layers. Ignoring this request and doing the exact opposite is not a solution. Whether 
edit-fields should always request "default-LTR" is another question. It doesn't sound like a good idea 
though.

Should editfields format their text as "default-LTR" or in their natural order (the first strong character 
decides)?

Ideally, this should be more context-dependent. 

If the content of an edit field relates to a document text paragraph, it should
take that order, I guess. 

Another option, which I already mentioned in some other issue, is to add a
text-direction option to the context-menu of edit fields, just like e.g. Windows
does by default. This gives at least the flexibility to correct a faulty
direction. But probably it won't be easy to decide, if and how such user defined
options will be persistent.

Making clear the what's cause of the defect would be very helpful to fix it. As
mensioned in one my previous comment, the difference between Windows and Linux is,

On windows, the bidi text is seperated into runs each of which contains only
single language characters before being reordered by uniscribe bidi algorithm.
That why no problem is on windows.

On Linux, the whole multilingual bidi text is delivered to icu with the
parameter UBIDI_DEFAULT_LTR, so the initial direction or paragraph is determined
by the first character with bidi-strong character. Unfortunately, the editfield
in English UI should use LTR as paragraph direction to layout text.

So the paragraph direction of bidi text in editfield should depend on the
attribution  mnTextLayoutMode in class OutputDevice. But the LayoutMode
TEXT_LAYOUT_BIDI_LTR seems be ignored or mixed with TEXT_LAYOUT_DEFAULT because
they have same binary value. What's more, there is no value of mnFlags in class
ImplLayoutArgs responding to LayoutMode TEXT_LAYOUT_BIDI_LTR. 

Solution: make difference between LayoutModes TEXT_LAYOUT_BIDI_LTR and
TEXT_LAYOUT_DEFAULT defined in vcl/inc/outdev.hxx at first; and then set mnFlags
according to mnTextLayoutMode; finally assign the nLevel with correct value
according to mnFlags in
vcl/source/gdi/sallayout.cxx::ImplLayoutArgs::ImplLayoutArgs(...). 

Indeed there is an ambiguity that has historical reasons: The app has almost 10e7 lines of code and 
most of it was developed without any BiDi-considerations. Writer and EditEngine have been fixed to 
handle this, but most of older parts just assumed LTR-preference or was lucky with the much better 
matching natural-default.

Requiring each of these code parts to set their BiDi-preferences correctly is not trivial, a huge amount 
of work and all that effort would not make any visible difference to 99% of the end-users. And even to 
those where it makes a difference a weak-LTR preference may be a step backwards from the natural-
default.

In any case the patch that sets a weak-LTR preference when a weak-RTL preference really is requested 
is not a good idea. One can argue whether the default OutputDevice setting should be weak-LTR or 
BiDi-natural, but this is a different question. I think BiDi-natural is a good default, though.

Debugging into this problem on Windows I think the problem for weak-BiDi settings is that the 
ordering of the BiDi-runs from the ICU-algorithm and the algorithm used in UniscribeLayout differs. I'm 
99% sure that the code near "L2 algorithm" needs a closer look to match the result of the ICU-
algorithm.

Although the actual cause may be different, but the result visible to the user
certainly is related: see also issue 96854

Maybe this article could be helpful for understanding:
http://www.w3.org/International/articles/inline-bidi-markup/

yanminjia->cemu: Thank you for your information. I think the link is really a
good description about BiDi behavior. But as the comment of hdu, the problem is
how to overcome the difficulties caused by the "historical reasons": the former
development without BiDi-consideration.  

Created attachment 62431 [details]
non-bmp chinese characters represent in dialog

sorry, made a mistake attachment

Reset assigne to the default "issues@openoffice.apache.org".