Thread: Touch Cover image frustrations
View Single Post
Old 10-26-2012, 09:00 PM   #8
davidfor
Grand Sorcerer
davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.
 
Posts: 24,907
Karma: 47303748
Join Date: Jul 2011
Location: Sydney, Australia
Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos
Quote:
Originally Posted by scoobertron View Post
I have attached one of the epubs. The cover image is one I have generated to replace the original, which was also 600x800.
RG1 has made a change to the book that fills the first page properly and hence the cover images have no borders. That is the change I would have made.
Quote:
Yeah, something funny is going on. When I was copying the image files I had made, I was getting errors that there was no disk space, even though there was plenty. Using df -i showed 0 free inodes, which made me think that I had run out, but looking again it shows 0% used, so I am wondering if the filesystem is borked.
I checked the details of the max files, and there is a comment about the number being reduced if long file names are used. I don't know by how much, but I wouldn't have thought by that much.

My Linux skills are enough to know what "df" is, but not to go that much further. But, is an inode count valid for a FAT32 file system? If it wasn't, that would explain the strange numbers.

One other thing is path length. I have had a couple of strange things happen with the image files because of very long names. Because the device uses the full path of the book plus a suffix for the image file name and then puts it into a subdirectory, the path can get very long. It is actually possible to get the device to create an image so that the path is longer than 260 character when looked at under Windows. You can see the file, but not do anything with it. And I have also put a book on so that some of the cover images weren't generated because of the path length being exceeded.

If you are hitting this, it shouldn't give a disk full error. But, it is also possible that something is misinterpreting the error.

Quote:
I am using 2.1.5. The reason I was thinking it is a bug is that the image is already the right size to fit the screen, so adding the margins changes the aspect ratio, which distorts the text.
I can see way you thought that. But, the thing to remember that the Kobo devices don't use the image file in the epub, but the first page of the book. But an option to stretch this when generating the cover image would be very popular.
davidfor is offline   Reply With Quote