All of the renditions of the bible I have seen seem to founder because of a lack of a good TOC or indexing system. I is unfortunate that the PRS 505 does not support nested TOCs but it doesn't. In an effort to over come this difficulty it occurred to me that if each book of the bible were created with its on TOC and then the books put into a collection named (in this instance) "King James Bible" we would have a workable pseudo nested TOC at two deep. I have completed a working version of "The Book of Genesis" from the "King James Version" of the bible based on that premise. In the process I have tagged each of the verses and may, one day, attempt to build a Jump Table to the verses - but that is a long way in the future.

In the mean time I have attached "Genesis" to this message for your examination. Do you think that this would be a viable approach to the problem?

2 February 2008
I have replaced the previously uploaded versions of the books of the Pentateuch with with files which have had their meta-data and names to facilitate sort ordering in the traditional bible order on both your computer and on the reader.

I have also upload the complete Bible in two Zip files. The books in the Zip files follow the same naming scheme as the individual files.

I am sure that there are numerous typos and editing artifacts in the files. I have done my best to eliminate them but this work involved managing more than 1300 files and I am sure that I missed something. Now is the time for the proof readers to shine!! If you find one please post book:chapter and verse and I will do my best to fix it.

03 Feb 2008
I have added the entire bible in a single PDF file for comparison. Please read my message below.

Later on 03 Feb 2008
After some reflection, and a nice warm bath, I decided to remove the pdf file and post it in pdf limbo. If you are interested follow the link below.

06 Feb 2008
The book First Peter contains in fact the text of Second Peter. The books Amos, Isaiah, Judges and Acts have some minor cosmetic problems. The file KJV Update contains fixed files which should be used to update your bibles.

This work is assumed to be in the Life+70 public domain OR the copyright holder has given specific permission for distribution. Copyright laws differ throughout the world, and it may still be under copyright in some countries. Before downloading, please check your country's copyright laws. If the book is under copyright in your country, do not download or redistribute this work.

In adding the books to a Collection wouldn't it take four bumps of the Menu key to return to the Collection menu and then more "ups" and "downs" to find the book and so, in moving from book to book, present a tedious "collection" of key strokes?

I have come up with a simple way to move from book-to-book. Using the KJV available free (or 1.99) from the Sony Connect store and using the Medium size font (for my tired old eyes) I simply made a list of page numbers giving on what "page" the various books started. For example, Matthew starts on 5326. Type in 5326 using the number keys, press the center Enter key and it jumps to Chapter 1 of Matthew. Still no way to jump to a particular chapter much less a verse but I am thinking of expanding on my list of book page numbers to add certain (not all) chapters within certain books.

It is also possible to estimate the middle, beginning or end of a book. Job starts on page 3054 Psalms on 3237. So, 3150 wold be about the middle of Job.

Indeed your scheme is workable. Indeed manual indicies have existed almost from the time that Gutenburg invented the press. But they too have their limitations, where do you keep the index and how do you access it. For example do you try to memorize it? I would suggest that even with only 66 books of the bible that 66 entry numbers us a fairly good size of entries to memorize and if you wanted to do it by chapter assuming that there is an average of 20 chapters in a book that makes it 1200 entries to memorize. Not me! If you keep it on a piece of paper it sort of violates the concept of the Reader in the first place.

Does it give you quicker access. I think that would be subject to debate. For chapters with page numbers between 1 and 9 you would need two keystrokes for; those on pages 10 to 99, 3 keystrokes; for those on pages 100 to 999, four keystrokes; for those on pages 1000 to 9999, 5 keystrokes - and so on.

Where as in my system there are two methods of navigation. Mehod 1

Menu key - back to current book TOC
Menu key - back to Book menu
Menu key - back to collection
#key to page on which desired book lives
return/enter - to page of collection
key to book
key to TOC
# key to page on which desired chapter lives
return - to page in TOC
key to chapter

A total of 10 key strokes or somewhere between 2 to 2.5 times as many as your scheme. But note that I don't really need to memorize very much to make it work, at most the page number in the collection on which the book I wish to access lives. But? You ask! Don't you need to know page number on which the chapter lives? Not really as it is simply (int.truncate(chap_num)/10). For example chapter 32 would be on 32/10 or 3.2 which becomes simply 3 when we integerize it by truncation.

Also not that I have accepted the penalty of selecting the chapter rather than just the book. This costs me 3 key strokes. So for an apple to apples comparison you would have to estimate how many key strokes it would take you to get from the beginning of your book and the desired chapter. I suspect that in most cases, even if you knew the exact offset to the chapter that it would be more than 3 additional key strokes. It could be as many 4 maybe 5 even you knew, or could reasonably estimate the offset.

Method 2 is a bit more difficult but does have the advantage of combining some steps in two one. Simply holding down the menu key will cycle you back through the various menu levels so that if properly done, and this takes some practice you can combine the first 3 steps into one.

Finally there is the issue of accuracy and convenience. As you have noted your approach must assume that that the format print size must be consistent from use to use. The book clearly must repaginate every time you change font size and hence the entry points change. As for being convenient i guess it is every man to his own poison.

Deputy, I did not mean to suggest my method was better than yours. Obviously, with all the books in a collection and all having the chapter numbers in the TOC you can jump to a specific chapter quicker and certainly more accurately than I can. My method is a quick and dirty way to get to a book and to some proximity to a chapter. Actually, just remembering the pages for the TOC (OT 4,5,6 NT 7,8) will let me get to the correct book except I must scroll to the correct book title which is a pain for a book towards the middle of the TOC page.

As to some of your objections:
I have all all the book (page) numbers on a card that slips into the back of my 505's leather case. No big deal to refer to it.
I always use the M font for this book. It comes up that way when I restart reading it. I don't plan on changing it unless my eyesight gets worse - a possibility at 76.

BUT - you're method is certainly the best I have seen in getting to a specific book and chapter. I posted my original response not to find fault with your approach, but just to suggest another method. No offense meant and, I hope, none taken.

No, sorry, I never did. Just stupid, I guess. I pasted the jpost.py file into the Advanced page of libpr500 but had no idea what to do with the small ._jprpos.p file. To get this to work I think I would need personal hand-holding.

Anyway, thanks for your interest. Maybe a future version of libprs500 will have it along with your CS Monitor feed.

Good work, Deputy-Dawg. Many people will be very happy to have these.
Might I suggest that you add all the attachments to the first post in the thread?
That way people are more likely to find the later books.

I have, with a bit of trepidation added a .zip file containing a copy of the same bible in a rather unusual PDF form.

As many of you know navigation within documents with large or fairly complex TOC requirements have serious problems in the .lrf format because of the inability to constuct nested TOCs in the .lrf format. This is such an overweening problem that Sony elected to put their on Reader manual in PDF format. Yet many have hesitated from using PDF because of the rather miserable appearance of many PDF formatted files on the Reader.

Since Sony had managed a reasonably good appearing manual in PDF format I assumed that it could be done. With a bit of thought and some really miserable first attempts I have arrived at a custom PDF format that appears reasonably well on the Reader with two levels of magnification in the bargin. I suspect that three is undoable. The navigation is much easier, much more intutive, and - once the file has been fully loaded somewhat faster than any other method I have found to date.

There are two downside issues. The file is large (about 26 Mb) and I doubt that because of some of what I had to do to make it really work on the Sony Reader that it would be of much use on other platforms.

If you are interested in looking at the pdf file follow the link below: