Quote:
Originally Posted by tshering
I understand this as meaning that the covers look like those of kepub.epubs. And this is something I would like. But what I see is that the covers show a miniature of the first page of the book. (Edit: A little later I found that you are saying this yourself in another post:
Anyway, you are right in saying that no images are stored for them. With respect to processing time, however, I guess it might be better to set the imageId-s of all books (or a selected group of books) to the same value so that the share the same stored image files.
|
That is the type of cover I meant. But I was also saying that if the ImageId is set to NULL, no cover image is ever generated and that text only cover it used. Performance wise, I don't know if this or the same image for all books would be the best. If the cover doesn't exist, then the text cover flashes up before being replaced by the generated cover. If the cover image already exists, I think this still happens but isn't as noticeable.
If you are using an SD card, setting the ImageId to null should prevent the generation of any cover images.
Quote:
I am not sure what solutions you are referring to.
|
I made some suggestions on manipulating the ImageId in an earlier post. At the moment, my favourite solution is using subdirectories. If the directory structure for the books is replicated for the images, then the directory size limits won't be hit. But the path length would have to be watched.