Description: The attached PPTX has two text boxes set with align-right and text-direction-rtl. The text has numbers/letters and +- math symbols. The direction of the math symbols in Impress is wrong. I didn't test other symbols like <, >... Steps to Reproduce: 1. Open the attached PPTX presentation with Impress. 2. Compare the text to the attached PDF exported from PowerPoint. Actual Results: The first text box show: "100-" The second text box show: "+C1" Expected Results: "-100" "C1+" Reproducible: Always User Profile Reset: No Additional Info: Tested with LibreOffice 7.5.0.3 and Version: 7.4.5.1 / LibreOffice Community Build ID: 40(Build:1) CPU threads: 2; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Ubuntu package version: 1:7.4.5-0ubuntu0.20.04.1~lo1 Calc: threaded
Created attachment 185116 [details] PPTX with right-to-left text boxes, numbers and +- symbols
Created attachment 185117 [details] PowerPoint 2023 PDF export
bibisect-42max bisected to 91595b7feb4023ceb8cf49384ea6e704e53fce0b is the first bad commit commit 91595b7feb4023ceb8cf49384ea6e704e53fce0b Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 18:27:18 2015 +0800 source-hash-1ff3ab9235e32305c820af75b9677334c81d9899 commit 1ff3ab9235e32305c820af75b9677334c81d9899 Author: Zhe Wang <wangzcdl@apache.org> AuthorDate: Fri Sep 7 03:45:35 2012 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Thu Jun 13 21:00:34 2013 +0100 Resolves: #i119579# position & direction of bracket incorrect in Arabic locale * subversion/main/oox/source/drawingml/textparagraphpropertiescontext.cxx []WritingMode2 is used to numerous explicit writing directions, so use WritingMode2 to instead WritingMode. Patch by: Ma Bingbing <jiazema@gmail.com> Suggested by: Wang Zhe <kingwisemmx@gmai.com> Found by: Wang Lifeng <phoenix.wanglf@gmail.com> Review by: Wang Zhe <kingwisemmx@gmai.com>(cherry picked from commit 4545d293b1cf5009b075cdc82d43916909b77347) Change-Id: Ic621ce6107bdc0b83c511f055175ae7b629f1503
This is not a regression, the linked commit is fixing a real issue. The issue here is a fundamental difference in how LibreOffice and Microsoft Office handle text direction. LibreOffice simply follows the Unicode Bidirectional Text algorithm, and the result it gives is the conformant one. Microsoft Office will use the keyboard language to guess that portions of the text are English and thus should be left to right even of the whole paragraph is right to left. There is no easy way to fix this, and the inline direction information probably gets lost when opening the file in LibreOffice since it does not have something similar to map it to.
I wonder if this has to do with bug 146572 and the placement of the last character on the line.
(In reply to خالد حسني from comment #4) > The issue here is a fundamental difference in how LibreOffice and Microsoft > Office handle text direction. LibreOffice simply follows the Unicode > Bidirectional Text algorithm, and the result it gives is the conformant one. > Microsoft Office will use the keyboard language to guess that portions of > the text are English and thus should be left to right even of the whole > paragraph is right to left. > > There is no easy way to fix this, and the inline direction information > probably gets lost when opening the file in LibreOffice since it does not > have something similar to map it to. So, it seems this just an effect of the lack of ability to explicitly set the language (and hence the directionality?) of text in LibreOffice, i.e. bug 148257. Once that is possible, we can resolve 162502, and tweak our UBA application to not consider characters marked as "English" or "Hebrew" as just neutral ones, but rather as strongly-directional; or at least apply bias in favor of the language direction.