Apache OpenOffice (AOO) Bugzilla – Issue 99246
Bidi text in dialog editable box presents in incrrect order
Last modified: 2017-05-20 11:35:14 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.
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".