Created attachment 92593 [details] An .odt file contains valid captions and non valid ones. Numbers are shown from left to right in "Number range" variable when used in RTL scripts. This happens when Number range variable is used in table captions (for example) in Arabic script. For example: The table caption should be something like this: الجدول 3-1: وظيفة الجدول where "3" is the chapter number; And "1" is the table number; But, because of this bug, The caption will be something like this: الجدول 1-3: وظيفة الجدول I have included a simple .odt file contain a valid caption written manually (first), and a caption contain Number range variable. Operating System: Linux (Other) Version: 4.1.4.2 release
Same problem here. Operating System: Linux (Other) Version: 4.2.0.4
A question related to this bug http://ask.libreoffice.org/en/question/30201/problem-with-arabic-language-and-book-numbering/
Created attachment 100142 [details] Screenshot in LibO 4.2.4 Looks fine to me in 4.2.4 on Debian Linux, see screenshot.
The chapter number in the left and the number of table in the right. It should be the opposite.
Created attachment 100152 [details] Screenshot in LibO 4.2.4 with non numbers I don't agree with you about this, when both characters are numbers, they should be from left to right. This is also the way numbers are written in both Hebrew and Arabic. When one of the characters isn't a number (e.g. a letter), then, and only then it appears to be affected by the paragraph directionality. This is what happens in LibO 4.2 and regardless if the letter is in RTL or LTR language, only the paragraph directionality applies.
A workaround can be by an option to make LibreOffice reverse the rendering of the numbers. I mean instead of adding 1 then 2, It adds 2 then 1. It's must be an option in everything use placeholders, The numbering lists also.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.0) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
Correct me if I'm wrong, but this issue seems to not be about tables only, but any case of "nested numbering", e.g. heading numbers and so on. And you're arguing that the default should be "First number on the left, last number on the right" rather than "First number comes first, last number comes last". Myself, I like the style you argue for when the numbering involves numerals and Latin characters, but _not_ when it involves RTL language characters. Example: In Hebrew, א is the first character in the alphabet, followed by ב and then ג. If I read "א.ג" (Aleph on right, then Gimel on left) - I would interpret it as the third item in the first section/chapter, regardless of whether I read it in an RTL paragraph or not.
Dear safa alfulaij, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear safa alfulaij, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
*** Bug 88974 has been marked as a duplicate of this bug. ***
In my - admittedly anecdotal - opinion and experience, most people who use RTL language still expect numbers, or number-like-sequences (e.g. 1.3.2) to be ordered left-to-right, and that goes in particular for numbering in their documents. But there are exceptions! So, I would say that _both_ orderings are valid, and that we should keep the current default, but make it reasonably easy to have RTL-ordered numbering. What I'm less sure about: * Numbering with no strong-LTR characters, in particular no digits (e.g. א.ג.ב) * Numbers with mixed strong-LTR and strong-RTL characters Also, we should consider with MS Office does in these different cases.
Created attachment 189798 [details] The image shows the current inversed numbering for Arabic chapters in LibreOffice I am from Algeria, and many users here are using LibreOffice. However, they encounter difficulties when trying to correctly format chapter numbering. Unfortunately, this essential feature is not available in LibreOffice, which forces users to resort to manual numbering and write the chapter numbers in reverse order to avoid this issue. The attached image displays the current reversed numbering for Arabic chapters in LibreOffice, and the correct formatting for Arabic chapters