Description: When I type Old-Hungarian text, it appears LTR direction, however it is a RTL codepage, described in UNICODE 8.0 standard. In Writer resolved the problem with bidi algorithm, with language nothing. Actual Results: Appear as LTR text Expected Results: 𐲠𐳢𐳜𐳂𐳀𐳤𐳯𐳞𐳮𐳉𐳍 Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: hu Module: PresentationDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Created attachment 140307 [details] Old Hungarian font There is a font for testing
Created attachment 140308 [details] Screenshot
Confirming on Windows 10 Pro 64-bit en-US with Version: 6.0.1.1 (x64) Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6 CPU threads: 4; OS: Windows 10.0; UI render: GL; Locale: en-US (en_US); Calc: CL Text within Draw text boxes in Impress and Draw does not respond to ICU BiDi. STR: 1. Install a font with coverage of Old Hungarian (10C80 - 10CFF) in the SMP. 2. Create a blank presentation in a Left-to-Right locale 3. create a new text box 4. type some text and select 5. context menu select Character dialog 6. select the font with Unicode 10C80-10CFF coverage 7. set language -> None 8. copy paste a sample Rovas string "𐲠𐳢𐳜𐳂𐳀𐳤𐳯𐳞𐳮𐳉𐳍" Result -- Unicode BiDi from ICU libs are not invoked, like happens in Writer, and string is rendered Left-to-Right. Shouldn't Draw/Impress be consistent with the handling in Writer? Can the Draw/Impress Text objects be made so? Work around, requiring multiple Draw Text boxes for layout, select text and use the context menu Paragraph dialog. Set it to Right-to-Left. This of course is not optimal, as the RTL Rovas would normally be embedded into LTR paragraphs containing Hungarian.
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7a683c31e090e5a81debadcef025df9cd61c75f0 tdf#116157: Always apply Unicode Bidi in editeng 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
On Windows 10 Pro 64-bit en-US with Version: 6.1.0.0.alpha0+ (x64) Build ID: 7a683c31e090e5a81debadcef025df9cd61c75f0 CPU threads: 8; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-03-08_01:44:18 Locale: en-US (en_US); Calc: CL Mixed text with strong BiDi like Old Hungarian (10c80 - 10cff) is now behaving in Draw and Impress Text boxes so issue of OP is fixed. It now also behaves in mixed text strings in a Calc cell where, if embedded in a mixed string, the BiDi triggers. But if a string is entered with just glyphs from a Unicode block,e.g. Old Hungarian, it sometimes does not pick up the BiDi change and is rendered reversed. A <ctrl>+<shift>+F2 or a double click to move focus to the input line will trigger the BiDi in the cell. But on ending edit, the string rendering in the cell reverts. So not quite right in Calc--but much better there.
Created attachment 140459 [details] sample of BiDi issues in Calc Calc sheet with Old Hungarian (10c80 - 10cff) BiDi issues in Calc.
Created attachment 140460 [details] Calc example exported to PDF
Created attachment 140461 [details] sample of BiDi issues in Calc (rev setting lang None)
Created attachment 140462 [details] Calc example exported to PDF (rev setting lang None)
Please file a new bug for Calc issues.
(In reply to Khaled Hosny from comment #10) > Please file a new bug for Calc issues. What would you like to ask "please file"?
(In reply to Khaled Hosny from comment #10) > Please file a new bug for Calc issues. Done => bug 116322