Created attachment 195166 [details] Material for natural sort test Open attached file. Data > Select Range > choose 'naturalSort' Data > Sort... > Tab Options, check 'Enable natural sort' > OK Data > Select Range > choose 'alphanumericSort' Data > Sort... > Tab Options, make sure 'Enable natural sort' is not checked > OK Save file. Reopen saved file. Data > Select Range > choose 'naturalSort' Data > Sort... > Tab Options. Error: 'Enable natural sort' is not checked. Open saved file in editor and inspect element <table:database-ranges> in content.xml. You will find two <table:database-range> elements, one for database range 'naturalSort' the other for database range 'alphanumericalSort'. Compare their child elements <table:sort>. Besides the cell addresses they are identical. The element for database range 'naturalSort' should have an attribute table:embedded-number-behavior (19.628, part 3, ODF 1.3) with value 'double' or 'integer'. This attribute is needed to specify, that natural sort has to be used. If you add it manually, it is not read. Support for this attribute is missing and thus the setting 'Enable natural sort' is lost on save/load.
Reproducible Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7a5d0c413f37e02356d0bd1e1da7a9445ee25fe8 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Aoo has no the option. It fails in LIbreOffice from the start. LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
The import is in https://opengrok.libreoffice.org/xref/core/sc/source/filter/xml/xmlsorti.cxx. But the ScXMLSortContext has no suitable member yet. The export is in https://opengrok.libreoffice.org/xref/core/sc/source/filter/xml/XMLExportDatabaseRanges.cxx The property "case-sensitive" can be used as a kind of template to see what needs to done. I propose this as easyHack.
The specification of the ODF attribute table:embedded-number-behavior is in https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#attribute-table_embedded-number-behavior
See also: https://ask.libreoffice.org/t/enable-natural-sort-by-default/105916/
The struct ScSortParam has the members bNaturalSort and aCollatorAlgorithm. The latter is e.g. used in German locale for sort algorithm 'Telefonbuch'. With a German local I see table:algorithm="alphanumeric" or table:algorithm="phonebook" in the ODF file source. As ODF has only this one attribute for the algorithm, we need to encode the bNaturalSort attribute into this string. We could use a ";" (or a "+" or a "|") sign as delimiter. So we could get table:algorithm="alphanumeric;naturalsort" or table:algorithm="alphanumeric" or table:algorithm="naturalsort". The export is in /core/sc/source/filter/xml/XMLExportDatabaseRanges.cxx The import would need to separate the tokens and extend ScXMLSortContext for the bNaturalSort property. The import is in core/sc/source/filter/xml/xmlsorti.cxx. I'm not sure whether we have "Natural Sort" already in the API.
*** Bug 167997 has been marked as a duplicate of this bug. ***
(In reply to Regina Henschel from comment #5) > As ODF has only this one > attribute for the algorithm, we need to encode the bNaturalSort attribute > into this string. There I was wrong. Correction: ODF has the attribute table:embedded-number-behavior attribute of the <table:sort> element to describe a natural sort. https://docs.oasis-open.org/office/OpenDocument/v1.4/cs01/part3-schema/OpenDocument-v1.4-cs01-part3-schema.html#attribute-table_embedded-number-behavior. The standard describes in detail, how natural sorting has to be done.
I'll try to solve it. There will be three steps: 1. Bring natural sort to API. That's were I'm currently working on in https://gerrit.libreoffice.org/c/core/+/190133 2. Read/write it with ODF. 3. Implement ODF attribute value 'integer'.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/47eb7f4e4dd0ed72679246b462686e153a1c07d0 tdf161948 bring natural sort to API It will be available in 26.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.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/da42aee85993637e5aff3c2bf6c948dfe2f7c1b4 tdf161948 read & write ODF 'embedded-number-behavior' It will be available in 26.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.
This is not set to "Fixed" because I'm still working to bring the "integer" sorting type, that is provided by ODF, to LibreOffice.
(In reply to Regina Henschel from https://listarchives.libreoffice.org/global/design/2025/msg00080.html) > ODF has the attribute table:embedded-number-behavior of the <table:sort> > element [1]. It has the values `alpha-numeric`, `double` and `integer`. > ... > With my implementation, there are three possible sorting types then, and > therefore a checkbox no longer fits as a control element. In order to save space, the best control is a dropdown with the options. The labels could be: Sort options: [<...>] "Natural sort (A1, A2, ..., A19, A20)" "Alpha-numeric (A1, A10, ... ,A19, A2)" "Integer (..." -> what could be a good and short example here?
The current state of the patch uses a drop-down list. I'm aware, that the wording for the items need to be improved. A short explanation with examples of the three kinds of sorting can be found in /offapi/com/sun/star/sheet/SortNumberBehavior.idl Find the patch in https://gerrit.libreoffice.org/c/core/+/191159.
(In reply to Regina Henschel from comment #13) > ...the wording for the items need to be improved. I like Regina's solution with * Alpha-numeric (A1.14, A1.2, A10, A2.5) * Natural sort (A1.14, A1.2, A2.5, A10) * Split sort (A1.2, A1.14, A2.5, A10)
Disclaimer: I totally understand that naming is hard; and the following is not to Regina, but rather to UX, to think about proper terms / UI strings etc. > * Alpha-numeric (A1.14, A1.2, A10, A2.5) > * Natural sort (A1.14, A1.2, A2.5, A10) > * Split sort (A1.2, A1.14, A2.5, A10) Without looking at the details, and as an end user, I don't quite understand the names. => Alpha-numeric (A1.14, A1.2, A10, A2.5) What does "Alpha-numeric" tell me? I see it sorted lexicographically, right? I don't see the "numeric" effect there. => Natural sort (A1.14, A1.2, A2.5, A10) Hm. How is this "natural" - compared to next? The term seems to imply what in fact implemented by "Split sort" - that would likely be what a human expect, when they tell the program "treat the data intelligently, taking into account numbers in the strings"? IMO, with the change, we need to re-consider the name. Something about "taking first number into account". => Split sort (A1.2, A1.14, A2.5, A10) What does "Split" tell me?
Maybe my habits affect understanding - then sorry for the noise. > => Natural sort (A1.14, A1.2, A2.5, A10) > > Hm. How is this "natural" - compared to next? ... Oh. Does it convert '1.14' to floats for sorting (using dot as decimal separator - is this locale-dependent)? I somehow assumed that it *only* took the parts before dot into account, sorry.
(In reply to Mike Kaganski from comment #15) > => Natural sort (A1.14, A1.2, A2.5, A10) > ... Something about "taking first number into account". I believe that complex functions never can be named in a way that makes everything perfectly clear to users. That's why I suggested the amended examples (and a tooltip for more explanation). Sort by "Taking first number..." vs. "Separate integer and fractional part" is surely not an improvement.
Following the discussion in the design meeting yesterday, here are suggestions for labels for the checkbox-and-radiobox solution. First, a brief description (since Heiko hasn't posted it here yet). The idea is to have the following arrangement: [ ] Label1 ( ) Label2 ( ) Label3 One state of the checkbox corresponds to the choice of "table:embedded-number-behavior=alpha-numeric". The other state corresponds to one of the other two values, where the radio-group chooses between "table:embedded-number-behavior=double" and "table:embedded-number-behavior=integer". Now, what should the labels be? Before making concrete suggestions, let's think about some principles of the labeling: * They should make clear that these settings regard the processing of cells with text values (which is not explained elsewhere in any separate label). * They should avoid misunderstandings: It is acceptable for a user not to know what a certain choice does, but it is unacceptable for the user to believe it will do something and then see it did something else and contradictory. So, for example, using the phrase "natural sort" would be a really bad idea, because different people have a different idea of what is "natural" in the sorting of strings (is considering character ASCII/Unicode values natural? Is parsing words and numbers in strings natural? etc). * They should focus on intent, need, or use case rather than on the detail of how to achieve it; i.e. we would rather not say how a widget makes LO behave, but what its toggling can achieve. So, finally, some suggestions. First, for Label1: 1. "Parse string-values for numbers" 2. "Parse strings in cell values for numbers" 3. "Account for numeric values in strings" 4. "Account for numeric values in cell string-values" 5. "Account for numbers in string-valued cells" 6. "Account for numbers in text cell-values" 7. "Extract numbers from cells with text values" 8. "Extract numbers from cells with string values" 9. "Recognize numbers in strings" 10. "Recognize numbers in string-valued cells" 11. "Numeric sort" 12. "Sort strings by numeric values" 13. "Use numeric values in cell text for sorting" 14. "Sort strings using parsed numeric values" ... and the phrases "strings", "string-valued cells", "string values", "cell string values" can be replaced one of the other, mostly. Now, for Label2 and Label3: 1. "Parse only integers" , "Parse integers and fractional numbers" 2. "Parse only integers" , "Parse integers and decimal numbers" 3. "Parse only integers" , "Parse integers and fractionals" 4. "Parse integers" , "Parse integers and fractional numbers" 5. "Parse integers" , "Parse integers and decimal numbers" 6. "Parse integers" , "Parse integers and fractionals" 7. "Parse integers" , "Parse fractional numbers" 8. "Parse integers" , "Parse decimal numbers" 9. "Parse integers" , "Parse decimal-representation numbers" ... and you can also take and of the above 9 options and replace "Parse" with "Account for"; or replace the word "and" with "&". Feel free to make other, different suggestions.
We discussed the topic at the design meeting. One use case for "Split Sort" would be sorting of IP numbers. Nothing similarly clear for alphanumeric vs. natural, though. Alternatives to the current dropdown could be a set of radiobuttons in order to provide tooltips or a combination of checkbox and radiobutton like Order: [ ] Natural Sort ( ) Use entire numbers ( ) Split integer and fractional parts The label "Natural Sort" could also be "Recognize numbers within strings", "Parse numbers in Strings", or "Numeric Sort". The label "Order" should be rephrased too (if label and control are not in one line anymore) in order to point out that this option does not apply to numbers. Something like "Order for textual content:" comes in mind. Ultimately we need to provide a proper documentation, perhaps also via a dedicated sidebar tab that shows up when some (i)-button is pressed.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/45e8e48301c100e35da4e5da3d643a92ab06ba17 tdf#161948 support embedded-number-behavior='integer' It will be available in 26.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.
The implementation uses now the radio-button solution. Its advantage is, that each entry has its own label and its own tooltip. If necessary and desired, these texts can be changed in the file sortoptionspage.ui independently from the other technical solutions of this patch. Changing texts could be done together with work on bug 168687, for example. I'm not familiar with Glade and working with Glade on Windows is not nice anyway, so improving texts should be better done by someone else.