Created attachment 183686 [details] Text box with RTL text (DOCX) Description: RTL Text sometimes falls out of the text box. This example is from page 8 of attachment 182846 [details]. Steps to Reproduce: 1. Open attachment Actual Results: Text falls out of the text box Expected Results: Text should fall inside the text box. For a comparison, you can see the output from MS Word. Refer to page 8 of attachment 182846 [details]. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: deb0bb9f2635a8dfec90b42e3727f4224548a8e9 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 183687 [details] Text box with RTL text (ODT) In ODT version, the text is still out of the box, but with different amount.
I can confirm that the text box inside the custom shape ha wrong position I see that the docx-file has left-to-right text directions in Word. But I see these problems: The odt-file should have set text direction to "right-to-left" in page style, but has not. Several default objects have as writing mode "Page", which means they use the writing mode from the closest object in which they are contained and which itself has not writing mode "Page". If the page has writing mode not explicitly set, then (I guess) it takes the writing mode from application environment. For me that is German with "left-to-right". Has the page style for You a text direction "right-to-left"? The result for me is, that the shape has WritingMode=0" and TextWritingMode="LR_TB" and the paragraph style Frame Content too. When they do not have the correct text direction, you cannot expect, that the export to docx, produces correct text directions in Word. Of cause that does not mean that the export will produce a usable document if they are correct. So please try the complete process generating the documents with explicitly setting text directions, so that it is possible to sort out those problems, which come in because of wrong defaults in text directions. In regard to the position problem, when I change the anchor of the shape from "as character" to "to character", the frame jumps to the correct position. I set it to "New", because there is surely something wrong.
I can already see the text area to the left of the shape in: Version: 6.3.6.2 Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded But not as dramatic as the text area completely to the right of the shape in a build from today: Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 1fd42472e2b1a2169d56e62ef11aa7ee1f7815e7 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Hossein, can we reproduce this from scratch? i.e. without importing any other document?
Note that the bug persists with all sorts of other fonts, like Noto Sans Arabic.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4de9d58daefef6da0b64c3db0637f9f9d314dd09 tdf#152142 sw: fix RTL as-char anchored textbox positioning It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jonathan Clark committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/97b15184947a2b81c2b21a0ae7fd20124c5fca57 tdf#152142 sw: fix RTL as-char anchored textbox positioning It will be available in 24.8.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks Jonathan, While your patch fixes the issue in the attachment, it does not fix the problem with the original document. If you open the attachment 182846 [details], the text from the page 9 text box is no longer visible. It is simply empty. The text box is also displayed as "empty" in the PDF output. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 15bdbbb1bcd5be4046466669d6de78f6ddff647b CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to Hossein from comment #8) > Thanks Jonathan, > > While your patch fixes the issue in the attachment, it does not fix the > problem with the original document. > > If you open the attachment 182846 [details], the text from the page 9 text > box is no longer visible. It is simply empty. The text box is also displayed > as "empty" in the PDF output. The important difference between the two documents is that the docx version has the "DoNotMirrorRtlDrawObjs" flag set, while the odt version does not. I haven't fully investigated the implications of this, yet. This may just be another special case to handle when positioning text boxes, but I'm concerned about some noisy interaction between this flag and another bug fix (bug 135198).
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1d3ba3ba5dfd55dccc71b671645dced82795b31d tdf#152142 sw: fix RTL as-char textbox compat flag special case It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
After some more investigation, I believe that interaction is unrelated. The DoNotMirrorRtlDrawObjs compat flag appears to be a bona fide special case that needs to be handled while positioning text boxes. Note to verifiers: These three attachments cover different cases. Please check them all: - attachment 182846 [details] (on page 8) - attachment 183686 [details] - attachment 183687 [details]