Fiction books should come with minimal pictures (give them a “cover” for easy recognition) and small file sizes, 100-500k depending on the lenth of the book/series.
The determining factor for me is the reflowability (to use the PDF term) of the document. Making a format that has to be zoomed nd scrolled is a waste of time in my opinion.

Educational reading is somthing that can eat up a lot more size. Files should be compressed, images made “scalable” so that they can be viewed on every screen size withouth either losing detail (small screen) or smoothness (large screen).
The max. File-size here is difficult to realize…if you’re talking about black and white/grayscale eink screens, you could put the limit around 20MB, if you use full-color illustrations, you coulöd end up with files that exceed 100MB even when compressed.

Devices with colour screens will have to come with more built-in memory (ram) and should use fast and cheap cards (like CFII) for external storage. More RAM would also come in handy.
For the greyscale readers, 1GB should be overkill and the speed of processor and memory should be less important.

Complex topic.

Lots of readers already only load parts of the document into memory — there’s no need to wait for OpenReader. The PalmOS reader for Plucker does this, for instance, only loading the “records” that the user is currently reading.

On the subject of file size, 2GB is an interesting size boundary for a single-file format. Files larger than that aren’t handled properly by lots of libraries that are used in standard desktop/laptop applications. One can get around that by using Apple-style multi-file documents which are in reality folders containing lots of sub-documents. Most systems handle this properly. It’s the approach I took with the document format design for UpLib. UpLib “books” can be very large; the UpLib version of Christoph Schiller’s Motion Mountain physics text (1253 pages) is a little over 1 GB. The book Common Lisp the Language, Second Edition (1097 pages) is 295 MB.

Aside from that, network bandwidth is the determining factor for lots of document usage. If you can’t mail it to someone else as an attachment, because it’s too big — that’s a real determining factor for lots of people.

But would it make sense for a zipped ebook to contain high resolution and low resolution versions of the same graphic?

Plucker does this — a small version of the image for smaller devices, a larger version for large screens. UpLib stores multiple rasterizations of each page image — one at 300 dpi or better, one at “screen size”, one small page thumbnail with a big page number on it. It can also store more versions for special uses.

Yes, but when you switch off images, sounds, animations, etc. on your browser then the browser won’t even download the image, sound, etc. files and thus the webpages get smaller. This won’t work as well with e-books, since the images, sounds, etc. would have to be included in the e-book file anyway, and thus be using memory even if they are not used. However, even if the files are equally big regardless of the device configuration it would still be possible to save a lot of CPU time (which might even be more valuable than memory) if the reader chooses not to process/display all contained media elements.

I’m sure your guess, that e-book software that support images, sounds, etc. will be able to easily switch off these additional media types, is correct. At least if the software is not made by microsoft.

IMHO it would be better to use a multi-resolution capable format, such as jpeg-2000.

> When creating e-books, what should the optimal file size and resolution
> be for raster graphics?

That’s a really hard question. If the images are small then they might look as good as possible now but will look bad in the future when the displays are better. If the images are large then they will look good in the future but the files will be too big and/or slow to use now.

> How many is the minimum the reader would expect to have on his memory
> card?

As much as possible. I have a ton of dictionaries, reference manuals and academic literature that I’d like to have on my e-book device(s) at all times. I think that the absolute minimum number of titles that my e-book device would have to fit is 100. It sounds feasible to me to keep the average file size below 10 MiB, so 100 titles should easily fit on a 1 GiB memory card. However, if books will start containing many more pictures then the file sizes would increase drastically. Hopefully we’ll have bigger memory cards by then.

Jon.

The size of the file is less important than the way the device/software manages it. On my Nokia 770, my biggest txt file is about 12 Mb and I read it with Fbreader from a zipped directory and it loads a little bit slower than others, but acceptably so, while navigation is as fast as the others.
I also have lots of scanned books that I read as jpg’s cut to 800×480 (either full page or half page) and embedded in a blank html, the biggest being about 98Mb and they load and read as fast as a regular book since Fbreader reads them a page at a time, while even a 1mb pdf with evince is not readable due to slowness, scrolling, zooming…
On my Ebookwise1150 I have the same books (the jpg’s being now 318×448 and all cut to half pages due to lower resolution, embedded in html and converted with librarian to imp), though in imp format and even the biggest at ~100 Mb is as fast as any other book, just that due to card limitations, I have to use more cards than on the Nokia where a 1Gb card is acceptable.
So size is not the determining factor, but fast rendering and acceptable storage.

Liviu

just compare the iPod model with the DiskMan model.
The DiskMan model said: take the CD you want to listen to, load it in your DiskMan and there you go.
The iPod model on the oether hand said: load all your music library and have it all the time with you.
This model worked out fine…
I think ebook reader manufacturers should follow this model and aim to keep all the users library on the device, always accessible.