marcello said:

Every OS in use today supports folders, so its best to completely ignore this feature.

that makes it sound like you want to use folders.

Lets throw all books into one folder and use the filename to sort them out.

that makes it sound like you don't want to use folders. i didn't discuss whether to use folders or not because it really doesn't matter much if you do or you don't. but if you don't have unique filenames, then you _have_to_ use folders. but that's not the only reason why unique filenames are a good idea. the benefits of unique filenames apply either way, primarily that you want to be able to unequivocally know the contents of a file by looking at its filename, and that all the files of a book get sorted with each other (if they are among other books), and that they get sorted in their correct order, as defined by the paper-book binding.

Please realize that the etext no. gets assigned immediately before the book is posted. I tried to have this changed, because IMO it is a bad process, but WWers wanted to keep it like it is. In consequence, if you want the etext no. as part of your filename, you'll have to graft it on after the book is posted.

it would be easy enough to twiddle that part of the workflow.

Basically your proposal has following advantages over mine:

wrong on all counts. but everyone else can see that for themselves, so i won't bother with the redundancy of setting the record straight...

That file is just a "remake" of the zipped collection of tiffs. I just wanted to test compression, djvu plugin, loading speed, and deep linking features. This file predates my RFC and so cannot be compliant with it.

the point still stands; whoever made this scan-set did not include a blank-page scan for the verso of the illustration, which means the recto/verso alternating pattern for the set was thrown off...

having 2 different streams for front covers and back covers is overkill

we've got plenty of letters in the alphabet we can use if we need them to get the sequence to run correctly...

nearer to the paper book experience: first thing you see is the front cover

if you've got a cover-scan, that file should be sorted so it rises to the top, without question.

its easier to print: assuming you want to print the covers at all you'll have to print them on the color printer

it's no easier to do it your way than mine. and either way, people can figure that out.

if you split the cover page stream where do you put the spine?

at the end, of course. its name should sort to the very bottom. because it exists outside the linear sequence of the bound pages.

in the *looooooooooooooong* meantime ...

more disinformation i will not bother to counter. except to say that beta testers are still welcome! -bowerbird