The Hebrew numbering system uses letters of the Hebrew alphabet. Libreoffice offers an option to use this system, but incorrectly assigns values above ten. Ten is the letter 'yod' = "י". Done correctly by Libreoffice. Eleven should be the two letter combination 'yod aleph' = "יא". However, Libreoffice incorrectly jumps to the next single letter of the Hebrew alphabet, 'chof' = "כ". See the wikipedia article for 'Gematria'. You want to be using the method described there as 'Mispar Hechrachi'. The article includes a 'values table' for letters - you want to limit yourself to the first 22 letters only.
Here's a code snippet, written in C and taken from libhdate (hdate_strings.c, function hdate_strings), that should solve the bug: #define H_CHAR_WIDTH 2 static char *digits[3][10] = { {" ", "א", "ב", "ג", "ד", "ה", "ו", "ז", "ח", "ט"}, {"ט", "י", "כ", "ל", "מ", "נ", "ס", "ע", "פ", "צ"}, {" ", "ק", "ר", "ש", "ת"} if ((index > 0) && (index < 11000)) { /// HEBREW_NUMBER_BUFFER_SIZE 17 defined in hdate.h return_string = malloc(HEBREW_NUMBER_BUFFER_SIZE); if (return_string == NULL) return NULL; return_string[0] = '\0'; int n = index; if (n >= 1000) { strncat (return_string, digits[0][n / 1000], H_CHAR_WIDTH); n %= 1000; } while (n >= 400) { strncat (return_string, digits[2][4], H_CHAR_WIDTH); n -= 400; } if (n >= 100) { strncat (return_string, digits[2][n / 100], H_CHAR_WIDTH); n %= 100; } if (n >= 10) { if (n == 15 || n == 16) n -= 9; strncat (return_string, digits[1][n / 10], H_CHAR_WIDTH); n %= 10; } if (n > 0) strncat (return_string, digits[0][n], H_CHAR_WIDTH); /// possibly add the ' and " to hebrew numbers if (!short_form) { return_string_len = strlen (return_string); if (return_string_len <= H_CHAR_WIDTH) strncat (return_string, "'", H_CHAR_WIDTH); else { return_string[return_string_len + 1] = return_string[return_string_len]; return_string[return_string_len] = return_string[return_string_len - 1]; return_string[return_string_len - 1] = return_string[return_string_len - 2]; return_string[return_string_len - 2] = '\"'; return_string[return_string_len + 2] = '\0'; } } return return_string;
You should choose "Native Numbering" instead of "א ב ג".
(In reply to comment #2) > You should choose "Native Numbering" instead of "א ב ג". Two responses: 1] Your suggestion doesn't work. Maybe 'native numbering' uses the default WESTERN language set in the libreoffice default, and Hebrew is set in the CTL section. 2] Even were your suggestion to work, it would not close this bug, because having the eleventh letter of the Hebrew alphabet follow the tenth one makes no sense to any Hebrew speaker in any listing or counting context. In Hebrew, letters ARE numerals, and have always been numerals, so when a Hebrew speaker sees the tenth letter of the Hebrew alphabet, she thinks the number 'ten', and when she sees the eleventh letter, see thinks the number 'twenty'.
(In reply to comment #3) > (In reply to comment #2) > > You should choose "Native Numbering" instead of "א ב ג". > > Two responses: > > 1] Your suggestion doesn't work. Maybe 'native numbering' uses the default > WESTERN language set in the libreoffice default, and Hebrew is set in the > CTL section. > In order to make it work, you should go to Tools->Options..->Language Settings->Languages and change the "Locale setting" field to "Hebrew". It works for me. > 2] Even were your suggestion to work, it would not close this bug, because > having the eleventh letter of the Hebrew alphabet follow the tenth one makes > no sense to any Hebrew speaker in any listing or counting context. In > Hebrew, letters ARE numerals, and have always been numerals, so when a > Hebrew speaker sees the tenth letter of the Hebrew alphabet, she thinks the > number 'ten', and when she sees the eleventh letter, see thinks the number > 'twenty'. OK got it.
Changing status to 'NEW', as the current behaviour is completely wrong. See comment #3 and Wikipedia article about 'Hebrew numerals' for more details. The Item 'א ב ג' should act the same as 'Native Numbering'+Hebrew locale. Also I'm lowering the severity, as users can get the right behaviour using 'Native Numbering'+Hebrew locale (although it's not easily discoverable).
** 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 (4.4.1 or later) 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: 2015-04-01
** 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.2 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-04-16
(In reply to tommy27 from comment #7) Bug still manifests in the release version used in Ubunutu 16.04 at the moment (5.1.4.2). This should actually not be incredibly hard to fix, so if any developer is checking this page out - try devoting 15 minutes to doing this (i.e. changing the Hebrew numerals behavior to be the same as Default numerals + Hebrew locale). Anyway, about the workaround and the importance setting: While it does work, it has two issues 1. It is not at all obvious, and involves changing settings at two different and UI-far places. I would probably not have guessed it even given some time. 2. Some people have non-Hebrew locales, and should still see Hebrew documents rendered properly. So, I'm upping the severity to normal.
The current Hebrew numbering is an alphabet character numbering like A,B,C,... This is not a bug but just what was implemented upon request. What is requested instead indeed seems to be the Native Numbering in a Hebrew locale that is also available in the number formatter with [NatNum1]0 in a Hebrew locale. Just being available as a fixed numbering and not depending on the current work locale. I'm setting this to enhancement because an additional numbering is actually what is needed.
(In reply to Eike Rathke from comment #9) > The current Hebrew numbering is an alphabet character numbering like > A,B,C,... > This is not a bug but just what was implemented upon request. > > What is requested instead indeed seems to be the Native Numbering in a > Hebrew locale that is also available in the number formatter with [NatNum1]0 > in a Hebrew locale. Just being available as a fixed numbering and not > depending on the current work locale. Please read the thread before adding to it and before changing things. Everything you wrote is wrong. My guess is that the basis for your error is that you think that a language / localization is just a different set of words and unicode characters. But it isn't. Different languages -do- things differently. And, for Hebrew, what you're suggesting makes no sense at all. You're taking an English-style cultural convention and imposing it on a Jewish one, and it doesn't work. > I'm setting this to enhancement because an additional numbering is actually > what is needed. Kindly revert. You're action was misguided. Please read the prior comments on this thread and consult with native speakers of the language before jumping into the fray. As for this bug being inherited from Ooo, I'll take it on good faith that you researched that to be the case, but the bug was discovered in LibreOffice 5.1.4.2 release and reported against that version.
You may have discovered the behavior in 5.1.4, but the Hebrew Alphabet numbering was implemented since OOo, see https://bz.apache.org/ooo/show_bug.cgi?id=17516 and related the Hebrew Number numbering https://bz.apache.org/ooo/show_bug.cgi?id=23372 Don't tell me everything I wrote is wrong, I did research. You want the NatNum1 (and maybe even NatNum2) numbering being explicitly available as outline numbering.
Yossi Zahn committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=08fb6d73f8c22d98ab806dd93f4afe3f78b4ff83 tdf#66212 - Add Hebrew NATNUM1 to numbering-format menus. It will be available in 5.4.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.
Hello, Is this bug fixed? If so, could you please close it as RESOLVED FIXED?
The original complaint is fixed via http://cgit.freedesktop.org/libreoffice/core/commit/?id=08fb6d73f8c22d98ab806dd93f4afe3f78b4ff83 I still would like to add support for Hebrew numbering in the rtf and doc/docx filters.
Yossi Zahn committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5937eefe533fba332ab6a83da02496bb4b0bd3db tdf#66212 - Hebrew numbering import/export support It will be available in 6.0.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.