Khaled's work on bug 116157 has now improved things for Draw/Impress, in line with earlier Writer. But seems there are still occurrences in Calc when the BiDi Strong alone is not enough to hold isolated strings as RTL.
Example as here for Hungarian text where the Old Hungarian (10C80 - 10CFF) RTL Rovás script (Székely rovásírás) placename transliterations are being intermixed with LTR Magyar nyelv text.
But outstanding issue in Calc is that the glyph order while glyphs entered in a mixed stream with other text is correctly as RTL, but when entered it alone into a Calc cell the string is displayed rendered LTR. On selection/editing it correctly displays RTL, but when not selected the text string reverts and displays LTR.
Bug 116157 resolved usage in Draw/Impress, bug 170204 resolved usage in Writer.
s/bug 170204/bug 107204/
*** Bug 116307 has been marked as a duplicate of this bug. ***
Created attachment 140567 [details]
sample Calc sheet showing failure of BiDi lib handling of Strong typed strings entered in cells
Sorry, forgot to actually add this sample doc when generating this issue per Khaled's request in bug 116157
Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":
tdf#116322: Don’t hard-code RTL character ranges
It will be available in 6.1.0.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Verified on Windows 10 Ent 64-bit en-US with
Version: 18.104.22.168.alpha0+ (x64)
Build ID: 4647057a077824cd6782be82b2d13e06fa76704b
CPU threads: 8; OS: Windows 10.0; UI render: GL;
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-03-13_02:03:59
Locale: en-US (en_US); Calc: group
Build ID: fc86c38e4424f1e098c4422ee28fb0f106ce8558
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3;
Locale: hu-HU (hu_HU.UTF-8); Calc: group