XnView Software

In the picture browser there are 2 options to sort them by file name.

Sorting by Name (not numeric) is obviously a pure text mode and match the default sort order of file explorers, whatever the system. This option works fine when you get a number of pictures and video from the same camera, all having the same structure and a fixed length. Most of the files comes with DSCnnnnn or IMG_nnnnn where nnnnn is a number with non-significant zeroes. It works as well if the file names starts with a timestamp with year, month, date,... (eg. "2020-11-27_13-14-55_My picture" )

In such mode digits and numbers are ignored for their value, letters, digits and other signs are evaluated by their weight in the ASCII printable characters coding table or the more modern Unicode (signs, digits, capital letters, small letters) and then by their position in the text. Also, names are "shifted left" (all treated as if they have the length of the longest one and padded with spaces at the end). As a result, the shorter names comes first, "a3" comes before "43b" that comes before "4 b" and so on. It's a bit difficult at start but comes easier as time goes.

Sorting by Name (numeric) is useful when the naming is not consistent but includes a number that help put the pictures in the right order. Typical example is when pictures illustrate a list of actions: 1 Turn the key, 2 Open the door,... , 44 Take a burger in the fridge,..., 99 Turn on TV,..., 105 close your eyes,... Using Sort by Name(not numeric) would have put 105 between 1 and 2, all the range 40-49 before 5 and 99 before 8
I noticed that the actual sorting order is bit more complex. For example it may happen there are multiple sequences of digits in the name. In this case it use all the characters before the last sequence as text and sort these 1st (so the files are grouped by the beginning of their names) and then the sequence of digits is used to sort in numerical order. For examples, files like Back home 1, Back home 2,...,Back home 44,..., Back home 99,...,Back home 105 will by in the right sequence, as per previous example.

The same if there are text (no digits) after the sequence of digits, this part will be used a sub-sort. For examples, files like Back home 1 turn the key, Back home 1 put back the key in your pocket..., will be in the wrong order as p from put has precedence to t from "turn".

There is a very practical consideration in relation to the alternative sort orders when sort order is dependent on the numbering of files.

The alternative sort orders determine whether the files are sorted in what could be considered the natural order (1, 2, 3...) or whether they are sorted by an alternative sort order widely used in computing, including the Windows command line utility CMD (cmd.exe) and I believe the default sort order in early versions of Windows.

Illustrating for files numbered 1,2,3,10,11:

Sort by > Name 1,2,3,10,11

Sort by > Name (not numeric) 1,10,11, 2,3


Regarding the command line utility NConvert:

As the command line utility NConvert uses the above non-numeric sort order, when a multipage output file is created from numerically numbered input files some pages may be placed in the wrong order. This can be avoided if the input file numbers can be padded with leading zeros's 001, 002, ... and I believe may also be avoided by running the code using the newer Windows Powershell tool.

see https://en.wikipedia.org/wiki/Natural_sort_order

gaaned92 wrote: Wed Dec 23, 2020 8:55 am see https://en.wikipedia.org/wiki/Natural_sort_order

Thank you, a useful link, but when I looked into this some time ago I didn't find the terms 'natural' and 'numeric' very intuitive, so I illustrate the issue using the alternative short number sequences above, which clearly illustrate the practical problem.

The issue originally came up when someone using the command line tool NConvert to create a multi-page PDF found that some pages were placed in the wrong order, the files used to create the multi-page file were numbered 1,2,3... etc.

The problem can be avoided by numbering the source files 001,002,003 etc. with leading zeros. But there is a potential catch: the source files can't be renumbered using a command line renaming tool, as they will again be read in the same incorrect order; it is necessary to 'pad' the filenames using a Windows renaming tool, for example. However, as mentioned but not tested, the issue may possibly be avoided by running code using Window's PowerShell.

Another possible solution when using the command line is to add an offset to the source file numbers, so that they are ordered 1000, 1001, 1002... etc.