The really good way to resolve this is not to change the Unicode bidi algorithm, but to add support for inline direction marking to the OpenDocument standard and then implement it in LibreOffice. Put simply, HTML has <div dir="rtl"> and <span dir="rtl">, and OpenDocument only has something like <div dir="rtl">, but not <span dir="rtl">.

Using directionality marks like RLM, RLE and PDF is not a robust way to resolve this, although if they are used internally and the user doesn't have to use them directly, it's probably OK.

I tried to bring this issue up several times on the OpenDocument mailing list, but didn't get any useful replies. See here:
https://lists.oasis-open.org/archives/office-comment/201110/msg00000.html

There may be some challenges with implementing this, but before discussing the implementation challenges, it must be agreed to make the change in the standard that LibreOffice is implementing.

*** Bug 68092 has been marked as a duplicate of this bug. ***

The bug is still a problem in LO 4.4.2.2 on Ubuntu 14.04. The bug now is not affecting the brackets in the middle of the line but at the end of the line the brackets will not stay with the LTR word when the rest of the line is RTL. If you insert "no width no break" formatting mark, the brackets stick to the first letter but then the rest of the LTR word break at the end of the line.

Still reproducible with:

Version: 5.2.1.2
Build ID: 1:5.2.1~rc2-0ubuntu1~xenial0
CPU Threads: 1; OS Version: Linux 4.4; UI Render: default; 
Locale: en-US (en_US.UTF-8); Calc: group

The bug is still reproducible in LO Version: 5.2.1.2
Build ID: 31dd62db80d4e60af04904455ec9c9219178d620
CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; 
Locale: en-US (en_US.UTF-8); Calc: group

OS Ubuntu 15.10

This is how the Unicode bidirectional text algorithm works, and the latest versions of LibreOffice support the latest version of the algorithm which handles bracket pairing. Using formatting characters is a perfectly fine way to solve ambiguities that the algorithm can’t handle by automatically.

I seriously don't see how this is resolved. There is a serious problem here: Users get the _wrong_ results out of what they type. That means that this is in fact a bug.

Regarding "Using formatting characters is a perfectly fine way..." - if what you mean by this is that users enter these formatting characters manually, then it is definitely _not_ fine. This is a terrible nuisance to the few who even know what these formatting characters are and how to input them, but the vast majority of users are simply dumbfounded by the current behavior, and this is something that does actually work in the popular (sorry) office suite.

All of this has of course already been mentioned by the OP of this bug, and what has already been said (in subsequent comments) is that the Unicode BiDi algorithm does not have to change, but libreoffice _does_.

(In reply to amirimobile from comment #9)
> I seriously don't see how this is resolved. There is a serious problem here:
> Users get the _wrong_ results out of what they type. That means that this is
> in fact a bug.

No it is not, that is how the Unicode Bidirectional Text Algorithm works, not ideal but that is why control characters exists; to asset the algorithm when there is ambiguity (which is the case here).

> Regarding "Using formatting characters is a perfectly fine way..." - if what
> you mean by this is that users enter these formatting characters manually,
> then it is definitely _not_ fine. This is a terrible nuisance to the few who
> even know what these formatting characters are and how to input them, but
> the vast majority of users are simply dumbfounded by the current behavior,
> and this is something that does actually work in the popular (sorry) office
> suite.

Please cite examples of this working differently elsewhere.

> All of this has of course already been mentioned by the OP of this bug, and
> what has already been said (in subsequent comments) is that the Unicode BiDi
> algorithm does not have to change, but libreoffice _does_.

So what are the requested changes, other than changing the algorithm?

(In reply to Khaled Hosny from comment #10)
> (In reply to amirimobile from comment #9)
> > I seriously don't see how this is resolved. There is a serious problem here:
> > Users get the _wrong_ results out of what they type. That means that this is
> > in fact a bug.
> 
> No it is not, that is how the Unicode Bidirectional Text Algorithm works,
> not ideal but that is why control characters exists; to asset the algorithm
> when there is ambiguity (which is the case here).

That's just it: The algorithm is not at all the point here. LibreOffice Writer _is_. The algorithm specifies how to display bidirectional text. Writer is the instrument to be used to write text. What we're saying here is that writing is broken, not how the already-written text is displayed.

> 
> > Regarding "Using formatting characters is a perfectly fine way..." - if what
> > you mean by this is that users enter these formatting characters manually,
> > then it is definitely _not_ fine. This is a terrible nuisance to the few who
> > even know what these formatting characters are and how to input them, but
> > the vast majority of users are simply dumbfounded by the current behavior,
> > and this is something that does actually work in the popular (sorry) office
> > suite.
> 
> Please cite examples of this working differently elsewhere.

Microsoft Word:
- Base direction: LTR
- Write text using strongly typed LTR characters
- switch to RTL language
- write text using strongly type RTL characters, mixed with various bracket types
-> brackets keep their intended positions

> 
> > All of this has of course already been mentioned by the OP of this bug, and
> > what has already been said (in subsequent comments) is that the Unicode BiDi
> > algorithm does not have to change, but libreoffice _does_.
> 
> So what are the requested changes, other than changing the algorithm?


Two possible solutions that I would consider have already been suggested by Amir E. Aharoni 2013-03-07 11:36:10 UTC:

--- start quote ---
The really good way to resolve this is not to change the Unicode bidi algorithm, but to add support for inline direction marking to the OpenDocument standard and then implement it in LibreOffice. Put simply, HTML has <div dir="rtl"> and <span dir="rtl">, and OpenDocument only has something like <div dir="rtl">, but not <span dir="rtl">.

Using directionality marks like RLM, RLE and PDF is not a robust way to resolve this, although if they are used internally and the user doesn't have to use them directly, it's probably OK.
--- end quote ---

(In reply to amirimobile from comment #11) 
> Microsoft Word:
> - Base direction: LTR
> - Write text using strongly typed LTR characters
> - switch to RTL language
> - write text using strongly type RTL characters, mixed with various bracket
> types
> -> brackets keep their intended positions

Please attach a sample document.

Screenshot of the MS Office rendering would be appreciated as well.

Still happens in 5.4.1.

This is not really a bug but the expected Unicode bidirectional text rendering. The claim that MS Office handles this differently have not been supported with evidence (it wouldn’t matter even, MS Office is known not be in full compliance with Unicode Bidirectional Text Algorithm).

(In reply to Khaled Hosny from comment #17)

Khaled:

I agree with OP, that there *is* a problem here. Again: that's not the problem of rendering! There's nothing to Unicode bidirectional text algorithm. The user is able to manually create good-looking text if user performs some special actions; i.e., citing comment #0,

> Todays LibreOffice's solution is to add LRM and RLM chars in the correct place

Of course, text *rendering* should not place some formatting characters anywhere they aren't present in source. But the problem is not rendering, as already said multiple times; the problem is *input*, which should analyse the situation (current IME mode?) and insert those characters at input stage, when the string is created from keyboard. So, I suggest you to revert your decision to dismiss this, as UX-wise, this is a horrible bug actually.

(In reply to Mike Kaganski from comment #18)
> (In reply to Khaled Hosny from comment #17)
> 
> Khaled:
> 
> I agree with OP, that there *is* a problem here. Again: that's not the
> problem of rendering! There's nothing to Unicode bidirectional text
> algorithm. The user is able to manually create good-looking text if user
> performs some special actions; i.e., citing comment #0,
> 
> > Todays LibreOffice's solution is to add LRM and RLM chars in the correct place
> 
> Of course, text *rendering* should not place some formatting characters
> anywhere they aren't present in source. But the problem is not rendering, as
> already said multiple times; the problem is *input*, which should analyse
> the situation (current IME mode?) and insert those characters at input
> stage, when the string is created from keyboard. So, I suggest you to revert
> your decision to dismiss this, as UX-wise, this is a horrible bug actually.

There is no concrete proposal what should be done here. I don’t personally think we should start inserting characters the user didn’t type, not invisible ones at least. I don’t know any program that does that (regarding weak bidi characters) apart from what said here about MS Word (and I don’t think this is publicly specified anywhere, so we would be effectively reverse-engineering it). Also I feel that whatever we do here is likely to have undesired side-effects, if there were a robust way to handle this it would have made it to UBA by now.

But anyway, that is my 2 qirsh, feel free to re-open the issue if you think otherwise.