Book reader 1.4 has sort order problem with file names.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a book consisting of Chapter_10 and Chapter__0
2. Notice that they are the same length.  _'s are used to pad the file names.
3.

What is the expected output? What do you see instead?

1.3.7 would properly sort the filenames (chapter 0 before chapter 10), the
new version does not.

What version of the product are you using? On what operating system?

1.4-r469

Please provide any additional information below.

Please sort on both the start of the file and any trailing digits
independently.  A strict directory sort is not going to look the way that
users expect.

Original issue reported on code.google.com by jason.po...@gmail.com on 29 Mar 2008 at 11:21

[GoogleCodeExporter]

confirmed. I believe the problem is that the underscore character is greater 
than all
digits.

I would recommend the following heuristic: in FileBrowser.m:numberCompare, do a
find-replace on the strings replacing any odd punctuation/illegal characters 
with a
space character. Doing a replace of "_" to " " would do the trick for this 
specific
problem, but replacing other characters might avoid future similar bug reports.

A better algorithm, but more work, would be to tokenize the file names using 
spaces
and funny characters as delimiters. e.g., 12345__67 would become two tokens:

"12345"
"67"

Then sort from left to right: if the first character of a given token is a 
letter,
sort that token alphabetically. If the first character of a token is a number, 
then
sort by the integer value of the token.

This should work in almost every conceivable situation...

Original comment by edwinolson@gmail.com on 27 Apr 2008 at 1:21

[GoogleCodeExporter]

Doing a find/replace on all filenames in a directory causes an enormous 
performance
hit and wastes quite a bit of memory.  The original kludge that was in place 
for Baen
books caused weird artifacts in certain book filenames (filenames that were 
similar
to Baen's but weren't actually) and also caused an extreme slow down in sorting 
files
as described in Issue #89.

I don't currently have any plans to re-instate this custom sorting of files for 
a
particular publisher's naming convention.  The best option is to rename the 
files
before placing them on the device.

Original comment by pendorbo...@gmail.com on 27 Apr 2008 at 3:21

• Changed state: WontFix
• Added labels: Milestone-Release1.4, Performance, Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

It's understandable that doing the find replace in the numberCompare function 
would
be particularly slow: why not hoist the find/replace into reloadData(), so that 
the
modification only needs to be performed once per file name?

I'm sympathetic to the notion of holding publishers to sanely name their chapter
titles (rather than kludging up the code), but I think the popularity of Baen's 
free
library  will cause this problem to have an undue impact on the EBook's users'
experiences.

Can you give an example of a filename where the heuristic you had did something
unfortunate? I'm happy to try to brainstorm a better heuristic.

Original comment by edwinolson@gmail.com on 28 Apr 2008 at 10:20

[GoogleCodeExporter]

Well, in terms of the Baen Library, I've fixed the file names in my installer
packages (http://library.pollock.ca/baen_books), combining the _'s.  It will be
rolled out when I finish the 1.4 changes (using ~ is causing problems), probably
tonight NZ time.

Are people buying webscriptions books and putting them on the iPhone?  My 
source only
covers the free books. :)  I'll have to figure out some way to add the non-free 
ones
to sources for people.

I'll leave it to you guys to decide if the behaviour is correct or not, I 
reported it
because it was a change from 1.3. :)

Original comment by jason.po...@gmail.com on 28 Apr 2008 at 10:59