View Single Post
Old 08-04-2017, 09:27 PM   #11
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,905
Karma: 47303824
Join Date: Jul 2011
Location: Sydney, Australia
Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos
Quote:
Originally Posted by salamanderjuice View Post
Well the different renderer makes some pretty huge differences...
Yes, the renderer is different. But, you used the word "organisation". That implied to me you saw there was a difference in how kepubs were managed on the device.
Quote:
Metadata wise I don't think there's a huge difference.
Well there is zero difference that I know of. I'm happy to be told that I'm wrong.
Quote:
Does KoboTouchExtended make changes to the cover image? I find sideloaded ePubs will often have too small a cover.
No the extended driver doesn't make any changes in the cover. If epub covers are to small, it is related to how the covers are produces on the device, but it is largely the fault of the person producing the epub. For a kepub, the cover image is marked in the OPF and the device extracts that and sizes it appropriately. For epubs, the first page of the book is rendered and that becomes the cover image. If the cover image is properly displayed on that, there shouldn't be any real difference between the two versions.

The drivers can send the covers separately so that the device doesn't generate them. In this case, the covers will be identical as they use exactly the same code.
Quote:
But sideloaded ePubs are also garbage at comic books/manga. I don't think Kobo's ePub renderer can handle RTL page flips AT ALL. Regardless of what the file says. I have purchased ePubs from Google Play Japan that work perfectly in ADE 4.5, and in the kepub renderer that don't work properly in the epub renderer. You also end up with margins on the image too, even if the file is correctly made.

This is why my mentioned method using Kindleunpack to get an ePub3 needs it to be transferred as a kepub.
I'm not sure about RTL and the epub renderer. I thought it did do this, but my quick test last night didn't work. I'll have to find the test book I've used in the past.

For the margins, I can easily produce an epub full of images with no side margins. But, I wouldn't. To do this, I would either have to only use images that were exactly the same size as the display area used for the book, or I would have to let it resize automatically to fill the area. And that would mean the image was distorted. If I assumed the epub was going to be read in full screen mode, it would be easier as it just means I would needed images of the correct aspect ratio.

You are probably right that the kepub render handles manga better than the epub renderer. I'll have a look at the sample you pointed to when I have a chance. I'll be interested in the difference. But, personally, the few times I have looked at comics on my devices, I have found the CBR/CBZ formats more than adequate.
davidfor is offline   Reply With Quote