This is a continuation from "News from Bookeen about firmware upgrade"
I thought this topic deserves a separate thread.

The original discussion has take a rather negative tone, so I would like to hit a reset button and look at this issue from a more constructive point.

In general I would agree with demands to show page number *IF* the device already has the information as implied by the "Go to ..." (page) command. However, let us examine what exactly is involved in computing page numbers for electronic formats.

In the old days it was simple. As soon as you print physical pages you had numbers by default. You simply assign numbers as you go. Then came SGML, followed by simple HTML and other derivatives like MobiPocket.

The critical difference is that new formats like HTML define layout instructions (<p>age break, line <br>eak, etc.) and not the actual page/diaplay content. In fact, the original HTML before CSS style sheets didn't even define font information. What font to use for <h1>eader? Well user could choose anything. Furthermore as displays have many different dimensions and windows can be resized, the physical page size is really unknown, undefined. Instead, HTML content was designed to "flow" into whatever display container is used.

Thus emerged PDF which decided to nail down every last detail, from fonts to spacing, images, etc. even page dimensions. Once page dimensions is fixed then it is easy to divide content into pages in PDF *REGARDLESS* of display device or window dimensions. Keep in mind what is being lost here. This is a clear compromise being made here. You gain fidelity, consistency while loosing flexibility. In some case, like for smaller screens, the lost flexibility can be painful.

So back to the question of page numbers. The 1st question is what is a page in the 1st place. Well it is the display device, or browser window, whatever is displaying content. Thus page is defined by our display. Today virtually all displays are simply a 2D matrix of pixels. The process of converting a certain format (like HTMK or MobiPocket) into pixels that can be displayed on a physical display (in this case eInk 6" display) is called "rendering". In short, a rendering engine (like MobiPocket renderer in Cybook) reads the content, executes the instructions like <p> and <br> and converts them into pixels according to a set of rules.

So to actually build a page for display you take some HTML content and render it into pixels. Those pixels (image) is an actual page that is ready for display. There are several important characteristics of rendering:
- it consumers significant computing resources
(more for more complex formats and less for simpler ones)
- thus it tends to consume significant energy (battery power)
- also tends to take relatively long time

Typically generated pixels (images) are much bigger than the input content, so they are only used for display and not kept anywhere. For instance, our typical 1 Mb and smaller MobiPocket books produce many magabytes of images when rendered. Hence rendered page images are only generated on demand, in general.

The HTML content is simply a long sequence of bytes, which in turn consist of a mix of words and rendering instructions (like heading, paragraph, line break, etc.) The Cybook computer simply knows that it is display content from byte #23,859 for instance. No page number. It just keeps reading HTML content from this position until Cybook page is filled. Simple.

Say you want to figure out what is the current page number. This is *THE QUESTION*

Well, the simple approach might be to start rendering content from the 1st byte (in memory only, it doesn't actually get displayed) and keep rendering until you reach the current position, byte #23,859. Say we rendered 31 pages to get to this byte position. Thus we learned that the current page number is 31.

The similar process could be used by the "Go to ..." (page) command to select the new byte position to render from. Again start rendering from byte 0 until the page count reaches the desired page, at which point you display the last rendered page.

There are a lot of problems with this approach. If you are trying to get to page 1,000 then the Cybook processor has to do a lot of work, consumer a lot of batter energy and worst of all would take a very long time (maybe minutes even). In computer speak, this approach doesn't scale. It may work for the initial 10-20 pages, but thereafter becomes too slow and uses too much battery power.

Then you go to work trying to figure out faster ways to manage the page numbers. Maybe the computer keeps track of pages as they are rendered and maps each page number to a corresponding byte position. That also doesn't work since I can jump from TOC to a middle of a book without rendering the initial pages (which could be many). And so on.

In effect, the Cybook programmers (as well as others trying to render HTML or MobiPocket) resort to taking shortcuts, or having Cybook make some guess or approximations to determine a page number without doing so much work. The compromise is lost precision (as reported in the other thread) for far less computation (and corresponding less power usage and better spead).

Of course, I have no clue what is the actual algorithm used and how precise it is (not). Some of you expressed interest in a 100% precise page number. Again, you need to step into Cybook maker's shoes.

SIDE NOTE: Before you scream, it safe to say that page numbers are not important to the majority of users that use browsers and other pageless systems every day without complaints. Sure you may be keen to have them 100% correct, but you are a minority. That being said ....

Bookeen is looking at this marginal feature of a low priority and assigning to it the proportional engineering effort. Of course, they have deadlines and limited resources, so it is just common sense that some manager will decide to assign 10 dev-days, for instance. So this single programmer has only 10 days to implement page "features". Thus they decide they can only do a single "Go to ..." (page) command using some less than great approximation for a barely/reasonably functional go to page command. They just don't have the time/resources to do more. Perhaps due to lower priority they decide they'll assign more effort to it for another release.

So the bottom line is they will spend as much time/effort as X units @350E / @$350 buys them. Simple business decision. You cannot spend more money than you earn.

That is why I said that users with higher expectations should get iRex product as it costs about 2x more. Therefore, iRex has more resources to implement page features better.

In summary,
Page numbers is a difficult feature to implement for certain formats. Such small devices like Cybook lack processing power for precise pagination. It will take both software engineering effort and likely more processing power to obtain more/better page features in the future. How far in the future is hard to say.

This feature like any other tends to increase costs and causes corresponding device price increase. Cybook walks a fine line between providing the desired features like pagination and keeping device price low enough for wider appeal.

Bottom line is, give them a break :)

Hi Bob,

Thank you for your useful summary.

I think, however, the significant thing to note is that the way that page numbers behave on the Gen3 is entirely consistent with the way they work on every other MobiPocket device. This is not some nasty bug that Bookeen have introduced - it appears to be behaviour which is inherent to the Mobi reader.

Personally - as I've stated before - I consider page numbers to be an irrelevent hang-over from paper books which have no place in the eBook world except, perhaps, as a method of making large "jumps" to an approximate position in a book.

The 1st question is what is a page in the 1st place. Well it is the display device, or browser window, whatever is displaying content. Thus page is defined by our display.

Maybe one approach could be to break the connection between a 'page' and the screen display, so that a page could span more (or less) than one screen and rendering calculations aren't required.
If pagination was somehow embedded in the file it would produce stable and consistent page numbering.
Of course then an attempt to 'go to page 136' might only display the first part of the page on the screen; but it would only be a key press or two to get to the bit of the page you wanted (probably no less efficient than the current method).
This approach would also maintain consistency of page numbering regardless of display format and device, and reduce the workload for the device.

Maybe one approach could be to break the connection between a 'page' and the screen display, so that a page could span more (or less) than one screen and rendering calculations aren't required.
If pagination was somehow embedded in the file it would produce stable and consistent page numbering.
Of course then an attempt to 'go to page 136' might only display the first part of the page on the screen; but it would only be a key press or two to get to the bit of the page you wanted (probably no less efficient than the current method).
This approach would also maintain consistency of page numbering regardless of display format and device, and reduce the workload for the device.

That seems to be how FBReader works.

As has been pointed out in the other threads it is not the page numbers that are important. What is important is that you know where you are in the book and the absolute total length. For a text file that would be trivial to implement. For a HTML file you have to ignore markup that does not generate text. If you have this measure you will soon learn how long time it take to read things and how many forward pagings are required for a certain length.

It seems like FBReaders approach is something similar to this.

Just throwing in a torch in the hayloft here....(instead of introducing myself in the appropriate forum...). I just loved the pagination in Microsofts Reader. It was my preferred reading software before I found the fullscreen-option in Mobipocket. :). The pagination saves time whenever I forget to bookmark.

I'm not at all sure that Microsoft Reader does proper pagination, actually. Try the experiment I've described elsewhere with MobiPocket: ie page forward from the start of a book until you get to the start of a certain chapter, and make a note of the page number. Then go back to the start of the book and do a direct jump to that same page number. See if you finish up at the same place. In MobiPocket you don't; I'd be interested to know whether or not you do in Microsoft Reader!

...you might have a point....It has happened that the pagenumber I thought I was at, was not accurate, but I always put that down to my "goldfish-memory"....I will test it...

Hi Bob,

Thank you for your useful summary.



Actually the summary did not cover all the cases. A real book has forced page breaks for things like chapter boundaries and widow and orphan rules can change the page break also. In addition images will cause page breaks since the image can't be split very easily. Every time the font is changed, and the cybook lets you pick your own, the entire book page scheme is thrown out the window. Different fonts kern differently so even if you have the same size the same number of words won't fit on a page.

When a book has specialized text like a quote with different margins or a poem embedded in it then the rules change once again.

Not only is pagination computed in the forward direction it has to be computed backwards as well. If you look at a real mobipocket implementation of their reader and walk past a chapter and then back up you will notice that they attempt to keep the partial page intact (which is done by remembering it from when you went forward). If you go to a new chapter and then backup the history isn't there and the partial page is rendered improperly.

Book readers that support real pagination have a limit to fonts and font sizes and then they store every page boundary in a separate database. This effort is best done on a computer before the book is ever downloaded since it is very compute intensive. This removes flexibility like changing font sizes or font families on the fly after the fact.

Dale

I think page numbers are used for two things. One is for referencing positions in the book. The other is so you know how long the text is and were you are in the text. For this second purpose the exact pagination is not so interesting and the functionality ought to be simpler to implement then real stable pagination.

Just throwing in a torch in the hayloft here....(instead of introducing myself in the appropriate forum...). I just loved the pagination in Microsofts Reader. It was my preferred reading software before I found the fullscreen-option in Mobipocket. :). The pagination saves time whenever I forget to bookmark.
But if you notice that in order to get the page numbers, it has to paginate internally. Do you want the gen3 to do that every time you change the font or the font size or the first time you open the book?

The "Palm" reader does the pagination in the background the first time you open the document. Until the background process finishes, all gotos and progress bars are only approximate. There is some UI feedback -- the progress bar is "greyer" until the pagination is complete. Like Mobipocket, the Palm ereader format compresses the text. I don't know how the Palm ereader deals with embedded markup.

I'm not at all sure that Microsoft Reader does proper pagination, actually. Try the experiment I've described elsewhere with MobiPocket: ie page forward from the start of a book until you get to the start of a certain chapter, and make a note of the page number. Then go back to the start of the book and do a direct jump to that same page number. See if you finish up at the same place. In MobiPocket you don't; I'd be interested to know whether or not you do in Microsoft Reader!

I tried your experiment. It takes me to the same page number as the one I found by manually paging. For some reason, the Alt-G keyboard shortcut for "goto page" didn't work for me, but clicking on a particular spot on the scrollbar at the bottom of MS Reader took me to the same page number every time. It looks like Microsoft got this feature right.

But if you notice that in order to get the page numbers, it has to paginate internally. Do you want the gen3 to do that every time you change the font or the font size or the first time you open the book?

Since screen sizes are different, the page numbers have to come from somewhere. So what's wrong with generating them when you load the book? If the way MS Reader does it works and doesn't cause any noticeable slowdown in reading, what is the problem?

Since screen sizes are different, the page numbers have to come from somewhere. So what's wrong with generating them when you load the book? If the way MS Reader does it works and doesn't cause any noticeable slowdown in reading, what is the problem?
Sony does page numbers with BBeB. But to do so eBook Library does the pagination when it put the eBook on the reade ror if not, the reader will do it. But once done, you have valid working page number that do mean something.

To be honest, I think that's really the only way to do it.

In the thread that inspired this, one person mentioned more than once that his desire for page numbers had a lot to do with reading short stories in a compilation. Without page numbers (and a table of contents that reflects them, I assume), he couldn't tell how far along he was in a short story.

One approach to solving a problem like that might be a change to the file format to store chapter bookmarks, then a change to the reader to display progress within a chapter in place of/in addition to the progress display for the document as a whole. That would involve less work on the reader device's part than pagination, anyway. Since I haven't seen a format that provides a dynamic table of contents with page numbers (just with hyperlinks), accurate page numbers in a list of chapters/stories would involve a change to reader software anyway. It seems like right now the best approach is to select a chapter in the table of contents, note the page it takes you to, then go back and select the following chapter, so you can compare the page numbers.

I tried your experiment. It takes me to the same page number as the one I found by manually paging. For some reason, the Alt-G keyboard shortcut for "goto page" didn't work for me, but clicking on a particular spot on the scrollbar at the bottom of MS Reader took me to the same page number every time. It looks like Microsoft got this feature right.

Thanks for doing that experiment - that's good to know!

Sony does page numbers with BBeB. But to do so eBook Library does the pagination when it put the eBook on the reade ror if not, the reader will do it. But once done, you have valid working page number that do mean something.

To be honest, I think that's really the only way to do it.

Mobi COULDN'T do pagination in their PC client (the Windows Mobi Reader) because it doesn't "know" what font the Gen3 is going to use to display the book. Remember that on the Gen3 you can load any TrueType/OpenType font you wish onto the machine, and view any book in any font. On the Sony, the fonts are "fixed" and there are only three sizes, so the desktop software can take over the hard work of pagination.

But, if you switch font and/or size, then the Gen3 could repaginte based on that and give you proper page numbers.

Yes, it could. Personally, as I've said before, I don't think it's worth doing.

But, if you switch font and/or size, then the Gen3 could repaginte based on that and give you proper page numbers.

But it is only a 200 MHz processor and it would take considerable resources to do this in the background. Basically every page would have to be displayed in a buffer simultaneous to your viewing to emulate what MS Reader does and in a device where the idea is that the CPU is almost off to save battery power I suspect you wouldn't like the battery consumption it would take nor the main memory resources. It simply isn't designed for this kind of computing task.

Dale

But it is only a 200 MHz processor and it would take considerable resources to do this in the background. Basically every page would have to be displayed in a buffer simultaneous to your viewing to emulate what MS Reader does and in a device where the idea is that the CPU is almost off to save battery power I suspect you wouldn't like the battery consumption it would take nor the main memory resources. It simply isn't designed for this kind of computing task.

Dale

It certainly COULD be done - the Sony Reader does it, for example, if you load a book directly onto the device via its USB drive, rather than go via the desktop software. It doesn't attempt to do it as a background task, though; it simply goes at it "flat out" when you first open the book, or select a new font size, displaying a "busy" cursor while it does so. It's not too bad - takes about 20s for an average novel, 1 min for a real "blockbuster" like "War and Peace".

But it is only a 200 MHz processor and it would take considerable resources to do this in the background. Basically every page would have to be displayed in a buffer simultaneous to your viewing to emulate what MS Reader does...

You only have to emulate the size of characters like TeX does to compute page breaks. You do not have to render the full page.

Dale's point about a limited processing capacity is what I was trying to demonstrate as a general observation - the current eReader devices have limited computing resources relative to the needs of a "proper" pagination, so some compromises have to be made.

Sony may limit font type/size choices and compute pages for them. Cybook took a different route of more font type/size flexibility but less accurate pages.

Thus the conclusion is that better pagination has to wait for more powerful processors combined with batteries that can support them. I think Cybook is in a good shape as its battery is more than sufficient so they could certainly put Cybook CPU to work more with a the next software update. The suggestion of a background pagination based on the current settings and storing results in its data files associated with an eBook would work well. We only use a small number of font type/size combos for any particular book. Based on my current experience regarding battery life, I would not loose anything if CPU did more pagination work and used more power. I still haven't managed to drop below 50% so the current battery has more then enough juice.

Again, the bottom line is we'll need some patience and understanding as this discussion has demonstrated that while on the surface it seems simple, actually it rather difficult problem to solve.

BTW nice ideas/info being posted, great stuff :):)

Page numbers are needed with book clubs and classrooms. ("Now class, turn to page 77"). Personally I don't need a print page equivalent. A percent or even a word number would be sufficient.

Dale's point about a limited processing capacity is what I was trying to demonstrate as a general observation - the current eReader devices have limited computing resources relative to the needs of a "proper" pagination, so some compromises have to be made.


Perhaps I'm not understanding what is needed, but as I said before, MS Reader has been doing pagination for different font sizes for years. If they can do it on a PDA with an older, slower processor than those in use today, then why is it so difficult on the Sony or Cybook?

Perhaps I'm not understanding what is needed, but as I said before, MS Reader has been doing pagination for different font sizes for years. If they can do it on a PDA with an older, slower processor than those in use today, then why is it so difficult on the Sony or Cybook?

Every PDA I have seen has a processor about twice as fast and sometimes 3 times as fast as the one on eBook Readers.

Dale

Every PDA I have seen has a processor about twice as fast and sometimes 3 times as fast as the one on eBook Readers.

I'm ok with slow pagination and random page numbers and would not want to trade that for a 5-10 hour battery life from a 2x or 3x bigger battery.

My desktop PC has a processor 1000x as fast, and it gets battery life not too far off the average PDA too. Of course, it's trying to do a completely different job to the PDA or liseuse, which makes the comparison a bit meaningless, but the numbers are there.

Every PDA I have seen has a processor about twice as fast and sometimes 3 times as fast as the one on eBook Readers.

Dale

You're talking current PDAs. I said that MS Reader has been doing this for years. Over the course of several years, I had owned three different PDA devices. Only the last one had a CPU comparable to the current Eink devices. And the original version of MS Reader was designed for PDAs that we would find laughable by today's standards.

jgray,

How old is MS Reader? What is its current version number? Sounds it is a lot more mature than Cybook's software, so I am not surprised it works better.

Both PDA and eReaders use similar processor types. However, PDA have been moving to more capable/powerful CPUs as their software evolved to ever bigger more powerful versions. Also, they don't care much about battery life so tend to use more power. Therefore it is not surprising that MS Reader being much more mature and having more resources would do a better job.

Cybook on the other hand is using Linux where more emhpasis is placed on power management. In general, the entire design approach and expectations are that eReader spends most of its time being idle (obviously) so processing is limited to bursts of activity, like page changes and menu access. So you wouldn't necessarily spawn a bunch of background threads for pagination. At this point I am guessing too much ....

Based on the current experience of a very long battery life on a single charge it is reasonable to assumbe that Cybook CPU is not very busy. Perhaps Bookeen engineers will change their approach to pagination in the future and make more use of the CPU.

Point taken. It works in MS Reader. I will also remind you that virtually all portable computers based on Microsoft software never get a very good battery life. On the contrary, laptop batteries are famous for lasting mere few years before they no longer can hold their charge. Therefore it is perfectly valid to consider a different compromise: less features and longer battery life

On the contrary, laptop batteries are famous for lasting mere few years before they no longer can hold their charge.

This is a limitation inherent in lithium ion battery technology. Every LiIon battery gradually loses its ability to hold a charge over the course of a few years. You can slow down the degradation depending on how you charge it, but you can't halt the process. The clock "starts ticking" on the battery's lifetime when it's initially charged, and nothing will stop it.

Great post on a blog I read about batteries and chargers... and reco's on which type to get.

http://www.codinghorror.com/blog/archives/001078.html

BOb

Harry,

There has been 2 primary development directions for batteries, such as Lithium Ion based chemistry. A lot of electronics batteries have been pushing for the maximum capacity in order to provide the longest runtime. One of the tricks for increasing capacity involved using thinner separators. It is shorts caused by broken separators that caused those fires and other accidents. So the end results was higher capacity and more fragile batteries that would not last very long. This problem was made worse by having devices like laptops drawing a lot of power (due to bigger LCD screens and more functionality like WiFi). The end result is batteries that last only a few years.

So your statements is correct regarding this design approach. Even so, they can last 5 and 10 years even when power draw is lower, such as eReaders. I fully expect our Cybook batteries to last 10 years, probably more. So while lifespan is limited, there is a big difference between 2-3 years and 10+ years.

More recently the new Lithium chemistries are being developed for power tools and cars. These sacrifice some capacity (lower) for a much more robust design that lasts much longer. So for instance GM Volt car demands that its batteries last at least 10 years, while supplying much higher power demands from a car. These should easily last 10 to 20 years.

So while all batteries do have a limited lifespan, they can differ a great deal. Some people reported their 20+ year old NiCd batteries still working!

What I was trying to say that there is again a tradeoff being made. More functionality causes more power draw that both reduces battery runtime and battery lifespan. Personally I prefer that device designer is more selective about functionality. Most makers these days just keep putting in more and more and couldn't care less about battery.

Great post on a blog I read about batteries and chargers... and reco's on which type to get.

http://www.codinghorror.com/blog/archives/001078.html

BOb

Yes, decent link. Just glimpsed it quickly.

Couple of notes. Like he said go with the lower capacity LSDs (low self discharge rate) batteries like Eneloop and hybrids. Most 2500 mAh and higher capacity batteries tend not to last.

BC900 is a nice charger. However, make sure to increase the charge rate. Default 200 mA rate it too slow. For instance, for a 2000 mAh battery go with a 1000 mA rate.

Thanks Bob - that's extremely interesting information.

I am currently reading a book with well over 3000 pages - and when I turn it on it always goes to a page around 2700, irrespective of where I turned it off. It is a monumental pain to have to find the place again (for some reason the bookmarks don't work, either) and a running page number display would be a real help.

Incidentally the justifications [A] that adequate pagination uses too much power and processing, and [B] that too few readers require it, do not hold water. It is all very well to be understanding about the costs and complications of developing an ebook to a price with limited resources but if the product does not do what the customer expects it will not sell. This was the problem with a number of Clive Sinclair's world-changing innovations - they were the first, but their defects were such that as soon as there was any competition the Sinclair device was so obviously inferior that they lost out quickly.

Readers of paper books expect them to have page numbers to simplify navigation. If migration from dead tree to ebook is to be successful the new medium must offer all the same conveniences and more, anything missing is a scourge for the backs of the ebook promoters. And if some ebooks have the feature the ones that do not will lose out.

If real pages (one screenful) are too really much trouble, it is likely that an "epage" of 512 words would be acceptable.

James

I am currently reading a book with well over 3000 pages - and when I turn it on it always goes to a page around 2700, irrespective of where I turned it off. It is a monumental pain to have to find the place again (for some reason the bookmarks don't work, either) and a running page number display would be a real help.

Incidentally the justifications [A] that adequate pagination uses too much power and processing, and [B] that too few readers require it, do not hold water. It is all very well to be understanding about the costs and complications of developing an ebook to a price with limited resources but if the product does not do what the customer expects it will not sell. This was the problem with a number of Clive Sinclair's world-changing innovations - they were the first, but their defects were such that as soon as there was any competition the Sinclair device was so obviously inferior that they lost out quickly.

Readers of paper books expect them to have page numbers to simplify navigation. If migration from dead tree to ebook is to be successful the new medium must offer all the same conveniences and more, anything missing is a scourge for the backs of the ebook promoters. And if some ebooks have the feature the ones that do not will lose out.

If real pages (one screenful) are too really much trouble, it is likely that an "epage" of 512 words would be acceptable.

James

As long as you're having this problem when returning to the last page you read, I'd agree that knowing what "page" to jump to is important. And it indicates there's a problem in the program. I'd like to know if, when you say "3,000 page", you mean 3,000 e-book pages or 3,000 dead-tree pages. Could be that a 3,000 page book (in TPB or HC format) falls out to a much larger page count on an ebook - maybe even large enough that it violates Mobipocket's preconceptions about page count. I know that the David Weber book "Empire from the Ashes" runs to 784 pages in HC but runs to well over 2,400 on the Cybook when I use Georgia font and the font size that works best for me. That's a 3x page-count multiplier. Perhaps there's a limit for the bookmarking software where it presumes nothing higher than 8,000 pages???

Derek

I am currently reading a book with well over 3000 pages - and when I turn it on it always goes to a page around 2700, irrespective of where I turned it off. It is a monumental pain to have to find the place again (for some reason the bookmarks don't work, either) and a running page number display would be a real help.

Actually, what would help is if the reader properly remembered your last read page. I never have this problem on my Sony. It remembers the last page for every book on it and choosing "continue reading" after selecting the book brings me right to that page.

Frankly the Sony does have page numbers, but I don't really pay attention to what page I am on.

So rather than asking for a bandaid I think CyBook users would want a fix for the autolastpage remembering (or whatever you'd call it) feature which to me is MUCH more basic than displaying page numbers for an ebook reader.

BOb

The issue with remembering bookmarks and the last page was resolved when I replaced the SD card delivered by Bookeen with one from SanDisk. The same has been reported from others.

I have started on a wiki entry for page numbers (http://wiki.mobileread.com/index.php?title=Page_numbers), that could need further contributions.

So rather than asking for a bandaid I think CyBook users would want a fix for the autolastpage remembering (or whatever you'd call it) feature which to me is MUCH more basic than displaying page numbers for an ebook reader.


The reason for wanting some numerical indication of were you are in the book are not to work around this bug. But having these indicators and possibility to jump to numerical positions will be a work around for the bug or design misfeature. There are no confirmed instances when problem with bookmarks was not caused by a corrupt file system. Switching to another card of course solves the problem since the file system is not corrupt on the other card.

With the current design file corruption will sometimes cause the Cybook not remembering the last position. So when you have fixed the file corruption you need a way to jump to where you were in the book.

There are no confirmed instances when problem with bookmarks was not caused by a corrupt file system.

I've experienced this several times. It was solved after switching off the Cybook and then on again, so if it was a filesystem corruption, it was a temporary one. It has happened with books in the SD card as well as in the internal memory.

I've experienced this several times. It was solved after switching off the Cybook and then on again, so if it was a filesystem corruption, it was a temporary one. It has happened with books in the SD card as well as in the internal memory.

If you have some corruption and you try to write to that position then I think the file system is remounted read only. Rebooting will then mount it read/write and if you do not trigger a read only remount it will work.

The book in question is all Miller & Lee's "Liaden" books and chapbooks condensed into a single "book" so it's probably about 2500 pages on paper. I use the smallest practicable font size in my ebooks, but have not yet taken the step of reducing line spacing from standard.

James - who has also "compressed" Bujold's "Vorkosiverse", Moon's "Familias Regnant" series, and all John Buchan's Leithen, Hanny and McCunn novels, and is working on other favourites.

The book in question is all Miller & Lee's "Liaden" books and chapbooks condensed into a single "book" so it's probably about 2500 pages on paper. I use the smallest practicable font size in my ebooks, but have not yet taken the step of reducing line spacing from standard.

James - who has also "compressed" Bujold's "Vorkosiverse", Moon's "Familias Regnant" series, and all John Buchan's Leithen, Hanny and McCunn novels, and is working on other favourites.

Y'know... I *have* that set of books, but I chose to download them as individual ebooks and haven't bothered to 'condense' them into one book. Not sure I'd want to do so after hearing about your problems! :)

Of course, these wouldn't be issues if we could get decent folder/sub-folder navigation which would allow us to store all the Liad stories into one sub-folder. :)

Derek

Y'know... I *have* that set of books, but I chose to download them as individual ebooks and haven't bothered to 'condense' them into one book. <SNIP!>

Derek
There is much less need to condense with the Cybook - with the REB1100 there is a size limit of 200 books set by the firmware. The 128 MB card will hold more but there are only 200 "slots" in the index. So combining several books as one "book" allows me to carry more books on one card.

James - whose initial interest in ebooks was sparked by the wish to be able to carry more books with him as he traveled

I would love page numbers, or word count, or percentage. This is partly because to get me through parts of books I find less interesting I try to get through a certain number of page turns in a sitting. However one measure no-one else seems to have mentioned is stitch count. Only available for those with the standard cover and very arbitrary - however I find it useful to note that I am say 141/2 stitches out of the 24 that align to the progress bar! Bizarre but possibly helpful to others I hope! HR

I would love page numbers, or word count, or percentage. This is partly because to get me through parts of books I find less interesting I try to get through a certain number of page turns in a sitting. However one measure no-one else seems to have mentioned is stitch count. Only available for those with the standard cover and very arbitrary - however I find it useful to note that I am say 141/2 stitches out of the 24 that align to the progress bar! Bizarre but possibly helpful to others I hope! HR

And how do you say " go to stitch 10 " ? laugh out loud ?

I would love page numbers, or word count, or percentage. This is partly because to get me through parts of books I find less interesting I try to get through a certain number of page turns in a sitting. However one measure no-one else seems to have mentioned is stitch count. Only available for those with the standard cover and very arbitrary - however I find it useful to note that I am say 141/2 stitches out of the 24 that align to the progress bar! Bizarre but possibly helpful to others I hope! HR
I do like page numbers as I can see how long I have left. Then I can decide how much I want to keep reading or how much I have left.