Hi יוסי, On Wednesday, 2016-12-07 13:58:54 +0000, יוסי צאהן wrote:
Looking at tdf#66212 - Hebrew Numbering incorrect above value ten, First of all, the current behavior of the 'א ב ג' option is rather useless as I have never seen this numbering used in practice (and yes, I spend my day reading Hebrew texts). I will note however that MS Office supports this numbering as well, so it may be used in some context that I am unaware of.
The history of its implementation can be seen by following git annotate and the issue numbers mentioned in the CWSs being integrated back at that time, which leads to https://bz.apache.org/ooo/show_bug.cgi?id=17516 (the alphabet numbering) https://bz.apache.org/ooo/show_bug.cgi?id=23372 (the number numbering)
Secondly, I totaly agree with comment #8. 1. The rendering of a document should not depend on the users locale
Probably there are uses cases where the numbering should follow the current locale, similar to what is expected to be seen if you load a spreadsheet in different locales and the number formats are in the default locale, not fixed.
2. All numbering systems should be usable regardless off the users preferred locale. That said, I can hardly understand the point of the "native numbering" menu item. I feel that it is confusing, non-intuitive and should be removed entirely. MS Office does not have such an option and I don't think anyone misses it. As far as fixing the issue goes - I can see a more than 1 way to fix it. - The easy way: Change the behavior of the 'א ב ג' item - as "Maxim Monastirsky" states in comment #3 "The Item 'א ב ג' should act the same as 'Native Numbering'+Hebrew locale". pros: easy to implement - will change only 2 lines of one file, namely "i18npool\source\defaultnumberingprovider\defaultnumberingprovider.cxx". Will probably also allow the removal of a few unnecessary lines. cons: 1. changes the semantics of a setting that people may be using. 2. the meaning of this option is not readily apparent from the menu item. 3. will break compatibility with MS Office ODF import.
It would also break loading existing documents that use the Hebrew Alphabet numbering in LibreOffice, probably also for OOXML/BIFF and not only ODF, so it isn't really an option.
- The MS way: as per https://msdn.microsoft.com/en-us/library/jj671735%28v=office.12%29.aspx, MS seem to have added support for another Hebrew numbering format that LibreOffice does not support, it serializes to odf xml as "א, י, ק," and is shown in menus as 'א...י, יא...כ'. This format provides the behavior that people generally want when they choose native Hebrew numbers. pros: 1. avoiding all cons of first method. 2. retain support for old behavior for those who really want it.
Sounds like the way to go.
cons: Adding a new number format to LibreOffice seems to involves more work. It will involve changes to more files - including the XML parsing/serialization code. (Can anyone provide me with pointers to all files that must be updated in order to add a new number format?)
This should be similar to FULLWIDTH_ARABIC in
i18npool/source/defaultnumberingprovider/defaultnumberingprovider.cxx
DefaultNumberingProvider::makeNumberingString(), just instead using
case NUMBER_HEBREW:
natNum = NativeNumberMode::NATNUM1;
locale.Language = "he";
so the string is obtained using NativeNumberSupplierService below.
NUMBER_HEBREW needs to be newly introduced, best check all places where
FULLWIDTH_ARABIC occurs. From an API perspective it needs to be appended
to offapi/com/sun/star/style/NumberingType.idl
The string stored to / loaded from ODF is determined by
DefaultNumberingProvider::makeNumberingIdentifier() that uses
Supported_NumberingType aSupportedTypes[]
in
i18npool/source/defaultnumberingprovider/defaultnumberingprovider.cxx,
also appending an entry to the list, in this case the identifier needs
to be given instead of generated via nullptr to distinguish it from the
Alphabet numbering. The same identifier string as MS uses should be used
for interoperability. Once in the wild (stored in documents) the
identifier can not be changed anymore.
The UI visible strings are obtained from
cui/uiconfig/ui/numberingoptionspage.ui
Note also that there are two Hebrew numberings, one NATNUM1 and the
other NATNUM2 which uses Geresh and Gershayim. I have no idea which one
would be correct (or even both needed?), but you seem to know.
I hope this helps.
Eike
--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Attachment:
signature.asc
Description: PGP signature