Issue 99246

Summary: Bidi text in dialog editable box presents in incrrect order
Product: gsl Reporter: jiayanmin
Component: codeAssignee: AOO issues mailing list <issues>
Status: ACCEPTED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: chrcm, hennerd, issues
Version: DEV300m41   
Target Milestone: ---   
Hardware: PC   
OS: Linux, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
The visual order of the bidi-text in the dialog isn't consistent with the case in the document respectively.
a suggested patch
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
non-bmp chinese characters represent in dialog none

Description jiayanmin 2009-02-16 03:30:45 UTC
Open a dialog such as "Find and Replace" from menu Edit->Find & Replace.Then
Type some Arabic character with a few English letters following up in "search
for" box. The English letters at the left of the Arabic characters incrrectly,
which is not consitent when copy the input text to the writer doument.

This defect only occurs on Linux platform.

Maybe fixing the defect need to modify the source code:
         vcl/source/gdi/sallayout.cxx: ImplLayoutArgs::ImplLayoutArgs(......)

I'm not sure how to submit my update to community. Any suggestion would be
wecome. Thanks.
Comment 1 jiayanmin 2009-02-16 08:53:04 UTC
Created attachment 60186 [details]
The visual order of the bidi-text in the dialog isn't consistent with the case in the document respectively.
Comment 2 philipp.lohmann 2009-02-16 09:21:20 UTC
pl->hdu: please have a look
Comment 3 jiayanmin 2009-02-16 09:46:44 UTC
Created attachment 60189 [details]
a suggested patch
Comment 4 2009-02-16 10:22:25 UTC
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.
Comment 5 jiayanmin 2009-02-17 01:04:15 UTC
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. 

Comment 6 jiayanmin 2009-02-18 02:58:17 UTC
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
Comment 7 jiayanmin 2009-02-19 01:19:15 UTC
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. 
Comment 8 2009-02-19 16:06:49 UTC
> it's better to behavior consistently on every supported platform

Indeed, it is behaving differently on WIN -> analyzing
Comment 9 jiayanmin 2009-02-20 01:19:52 UTC
yanminjia->hdu: The patch I provided can work for this defect. But I'm not sure
if it would cause other problem.   
Comment 10 2009-02-20 07:23:12 UTC
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 

Should editfields format their text as "default-LTR" or in their natural order (the first strong character 
Comment 11 hennerdrewes 2009-02-20 07:43:46 UTC
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.
Comment 12 jiayanmin 2009-02-20 09:32:20 UTC
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

Comment 13 2009-02-25 12:15:59 UTC
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-

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-
Comment 14 hennerdrewes 2009-02-25 13:33:47 UTC
Although the actual cause may be different, but the result visible to the user
certainly is related: see also issue 96854
Comment 15 cemu 2009-05-16 23:13:05 UTC
Maybe this article could be helpful for understanding:
Comment 16 jiayanmin 2009-05-19 02:49:59 UTC
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.  
Comment 17 jiayanmin 2009-05-22 10:18:11 UTC
Created attachment 62431 [details]
non-bmp chinese characters represent in dialog
Comment 18 jiayanmin 2009-05-22 10:19:34 UTC
sorry, made a mistake attachment
Comment 19 Marcus 2017-05-20 11:35:14 UTC
Reset assigne to the default "".