Download it now!
Bug 73933 - TABLE: Numbers are shown from left to right in "Number range" variable when used in RTL scripts.
Summary: TABLE: Numbers are shown from left to right in "Number range" variable when u...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
Whiteboard: BSA
Depends on:
Blocks: RTL-CTL
  Show dependency treegraph
Reported: 2014-01-22 14:47 UTC by safa alfulaij
Modified: 2019-09-18 02:52 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

An .odt file contains valid captions and non valid ones. (11.30 KB, application/vnd.oasis.opendocument.text)
2014-01-22 14:47 UTC, safa alfulaij
Screenshot in LibO 4.2.4 (69.92 KB, image/png)
2014-05-30 06:06 UTC, Lior Kaplan
Screenshot in LibO 4.2.4 with non numbers (68.97 KB, image/png)
2014-05-30 09:05 UTC, Lior Kaplan

Note You need to log in before you can comment on or make changes to this bug.
Description safa alfulaij 2014-01-22 14:47:14 UTC
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: release
Comment 1 libreoffice user 2014-02-02 12:01:15 UTC
Same problem here.

Operating System: Linux (Other)
Comment 3 Lior Kaplan 2014-05-30 06:06:10 UTC
Created attachment 100142 [details]
Screenshot in LibO 4.2.4

Looks fine to me in 4.2.4 on Debian Linux, see screenshot.
Comment 4 safa alfulaij 2014-05-30 06:42:11 UTC
The chapter number in the left and the number of table in the right. It should be the opposite.
Comment 5 Lior Kaplan 2014-05-30 09:05:00 UTC
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.
Comment 6 safa alfulaij 2015-01-23 21:58:37 UTC
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.
Comment 7 QA Administrators 2016-02-21 08:35:43 UTC Comment hidden (obsolete)
Comment 8 Eyal Rozenberg 2018-09-17 20:12:06 UTC
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. 


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.
Comment 9 QA Administrators 2019-09-18 02:52:45 UTC
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

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

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:

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team