What the estore does to your epub

[Hitch]

Originally Posted by photon_man62

Amazon adds extra JPG compression to images in KF8 files. So in this example, a cookbook which used to take up 62MB (because of all the photos of ingredients, recipes etc.) in the "classic MOBI" format now takes up only 14MB as a KF8 file. The same cookbook still takes up 62MB in other ebook stores that use EPUB.

Yes, naturally. Images inside a MOBI are compressed to meet certain size stipulations, and always have been. With the advent of the newer devices, the size restrictions are easing up a bit, but still...for most of the MOBI life, each image has been compressed to 128kb.

In the link I posted, I gave an example of the same pictures from an EPUB (mouse out) and from a KF8 file (mouse over the photo). The compression isn't very bad so you normally don't see a big difference in image quality.

Presumably, that works with what, pop-ups? I'm not seeing anything on mouse-over at all, on Chrome, Win7. I have a pop-up blocker, so if that's what happens...if it's supposed to be doing something else, I'm not seeing it. But I've seen thousands of books, so I don't need to see your examples. Yes: there's a difference, because ePUB basically allows someone to "go wild" with image sizes if they wish (although, older devices can choke on HTML files that are larger than about 256KB, if memory serves; don't know how they manage enormous images, assuming that they do.) That's been a restriction of working with MOBI for years now.

However when you look closely, you will see that there is a difference. Hold down Ctrl and press + a few times to zoom in. It's easiest to notice in picture #2 if you look at the background. When you mouse over the image you will immediately see that there is a completely different background texture. Look, this is the top-left corner of picture #2:

<snipped for the forum width>

The difference in picture quality isn't really a problem during normal viewing, especially on a black&white e-ink reader. However if the ebook you're publishing is very reliant on pictures, you should still keep this in mind.

I wasn't asking you about mobi and ePUB--if you look at my post, I asked you why you thought that the KF8 mobi was smaller than "the classic mobi," by which I assume you mean the KF7 mobi. Even with KFX format, I believe, the "multi-MOBI" (the file that contains the source, the KF7, the KF8 and possibly the KFX files) stores hi-rez and low-rez images, the former for the KF8 and KFX files, and the latter for the KF7 mobi.

Presumably, the "classic mobi" would then be smaller than the KF8--would it not?

Or am I missing something else from your posts?

Anyway: if one is working for a MOBI, it's wise to try to pre-process your images, using the best compression algorithms you have or can find. We do a lot of this--we have a lot of clients with image-heavy books (we've done some with just shy of 1,000 images). We use a set of compression tools (basically, File Optimizer), and that works fairly well to get most images to the point where the Amazon compression algo won't kick in.

Amazon no longer mentions the max size for a single image, but I think that the 128 shifted up to 256, a year or so ago. (Anyone else here remember?). In any event, if you place very large images into an ePUB for MOBI conversion, without some pre-processing, yes...you'll get an unexpected compression.

But I'm still fairly certain that a KF8 file is larger than the PRC/MOBI file. Of course, I could be wrong. It's certainly happened. ;-)

Hitch

[Notjohn]

Thanks to whoever brought this thread back to life. It all seemed fresh and interesting, and I was startled to find that I'd earlier replied to it. Perhaps it's true that memory fails as we get . . . what was I saying?

I do what Hitch accuses the "BPH"'s of doing -- I eschew media queries and upload the identical epub everywhere. I don't feel that it limits me at all, but then I don't format for others, only for myself.

(So if I used ISBNs, I could use the same one everywhere? That's nice to know, for future-proofing.)

[jhowell]

Originally Posted by Hitch

I wasn't asking you about mobi and ePUB--if you look at my post, I asked you why you thought that the KF8 mobi was smaller than "the classic mobi," by which I assume you mean the KF7 mobi. Even with KTX format, I believe, the "multi-MOBI" (the file that contains the source, the KF7, the KF8 and possibly the KTX files) stores hi-rez and low-rez images, the former for the KF8 and KTX files, and the latter for the KF7 mobi.

Hitch, I have a question about your statement. I assume that you mean KFX instead of KTX. If so, do you have any evidence that Amazon has a combined format that includes KFX? I haven't seen any indications of this myself.

[Hitch]

Originally Posted by jhowell

Hitch, I have a question about your statement. I assume that you mean KFX instead of KTX. If so, do you have any evidence that Amazon has a combined format that includes KFX? I haven't seen any indications of this myself.

I'm deducing, from the available evidence. If a KFX (yes, sorry, typo) file is delivered to a device--which we've seen--it has to exist somewhere. Sure, arguably, it could be converted or rendered on the fly--I would never say that's impossible--but the more likely scenario is that the KFX, like other formats, is being introduced during the upload processing, or, the PW (Publishing Workflow), which is everything that happens after you push "publish and save" and before the first buyer clicks "buy."

So...that's my personal deduction. I mean, you were on that thread with me: https://www.mobileread.com/forums/sho...d.php?t=263902 . Amazon has pretty much always put all their elements in a single basket, so to speak, so, yes, I think that the KFX is added in the Publishing Workflow. Just like the AZK-for-iOS AZW file.

If the question is, do I see it in the existing MOBIs built with Amazon tools, at the creation end, i.e., Previewer et al, no: I don't see that. TBH, I hadn't started looking yet.

So...I'm making some assumptions. I have no concrete evidence of anything, other than having seen the delivery of KFX-enabled files to my own devices.

Hitch

[jhowell]

Originally Posted by Hitch

I'm deducing, from the available evidence. ...

Thanks for the info. (Apologies for the thread derail.)

[Notjohn]

Originally Posted by Hitch

I'm deducing, from the available evidence. If a KFX (yes, sorry, typo) file is delivered to a device--which we've seen--it has to exist somewhere. Sure, arguably, it could be converted or rendered on the fly--I would never say that's impossible--but the more likely scenario is that the KFX, like other formats, is being introduced during the upload processing, or, the PW (Publishing Workflow), which is everything that happens after you push "publish and save" and before the first buyer clicks "buy."

So...that's my personal deduction. I mean, you were on that thread with me: https://www.mobileread.com/forums/sho...d.php?t=263902 . Amazon has pretty much always put all their elements in a single basket, so to speak, so, yes, I think that the KFX is added in the Publishing Workflow. Just like the AZK-for-iOS AZW file.

If the question is, do I see it in the existing MOBIs built with Amazon tools, at the creation end, i.e., Previewer et al, no: I don't see that. TBH, I hadn't started looking yet.

So...I'm making some assumptions. I have no concrete evidence of anything, other than having seen the delivery of KFX-enabled files to my own devices.

Hitch

Well, my understanding is that if a book has automagical hyphenation, then it's KFX. Is that correct? I got the new Fire tablet (which I rather dislike, compared to the old one--much more sluggish, as if there were a membrane over the touch screen) just to check out "enhanced typesetting." Sure enough, most of my books do indeed have hyphenation (and it's not bad). So the KFX file MUST be delivered to me, right?

Okay, I suppose it could be on a separate shelf in Jeff Bezos's pool house, and his pool boy pulls it down for delivery to me.

I'm pretty sure it's not in the converted "mobi" that's available to us at Step 7 in the publishing process. So it must be added in the publishing workflow (if it is added -- not every one of my books is so designated) or later. (A little sweatshop out behind the pool house, lots of undocumented relatives of the pool boy?)

I'm enchanted by this whole KFX thing, and I'm sorry to see the KFX thread gone inactive. I wish I had the chops to pick at it and unravel it.

[Hitch]

Originally Posted by Notjohn

Well, my understanding is that if a book has automagical hyphenation, then it's KFX. Is that correct? I got the new Fire tablet (which I rather dislike, compared to the old one--much more sluggish, as if there were a membrane over the touch screen) just to check out "enhanced typesetting." Sure enough, most of my books do indeed have hyphenation (and it's not bad). So the KFX file MUST be delivered to me, right?

Okay, I suppose it could be on a separate shelf in Jeff Bezos's pool house, and his pool boy pulls it down for delivery to me.

I'm pretty sure it's not in the converted "mobi" that's available to us at Step 7 in the publishing process. So it must be added in the publishing workflow (if it is added -- not every one of my books is so designated) or later. (A little sweatshop out behind the pool house, lots of undocumented relatives of the pool boy?)

I'm enchanted by this whole KFX thing, and I'm sorry to see the KFX thread gone inactive. I wish I had the chops to pick at it and unravel it.

Well, if you're saying that your step-7 mobis do NOT have the same hyphenation capabilities, then, yes, I'd say that that confirms that the KFX is being added in the PW. If it's only in the upload, you ought to see it in the Step-7 mobi. As you are not, KFX-capabilities/format/??? must be added in the PW.

Hitch

[Notjohn]

That's correct. I see no hyphenation in the "mobi" downloaded at Step 7, even though the published book has Enhanced Typesetting: Enabled.

(Sometimes, though, I simply can't get my new Fire tablet to find the book I have just sideloaded to it, and rather than bash about doing things I probably shouldn't be doing, I simply use the Send to Kindle option. This always does show up, though without a cover, and perhaps it's not KFX at all. The versions pushed to me by KDP Support, or purchased in the case of a new book, do show hyphenation.)

[Hitch]

Originally Posted by Notjohn

That's correct. I see no hyphenation in the "mobi" downloaded at Step 7, even though the published book has Enhanced Typesetting: Enabled.

(Sometimes, though, I simply can't get my new Fire tablet to find the book I have just sideloaded to it, and rather than bash about doing things I probably shouldn't be doing, I simply use the Send to Kindle option. This always does show up, though without a cover, and perhaps it's not KFX at all. The versions pushed to me by KDP Support, or purchased in the case of a new book, do show hyphenation.)

Hmph. Well, then...I'd say that our surmise that KFX is added after "save and publish" and before the first person buys a copy, is correct. So, KFX is added in the PW. Anyone else have any ideas about that?

Hitch

[HarryT]

Originally Posted by Notjohn

(So if I used ISBNs, I could use the same one everywhere? That's nice to know, for future-proofing.)

An ISBN should refer to a specific version of a book. So yes, the same ISBN could (and should) be used for an ePub edition sold in different bookstores, but you should (although many authors don't) use different ISBNs for ePub and Kindle editions of the same book.

[Notjohn]

That's not what Hitch just said!

Or what I understood her to say: that an epub is an epub is an epub, regardless of whether Amazon sells it as such.

[HarryT]

Originally Posted by Notjohn

That's not what Hitch just said!

Or what I understood her to say: that an epub is an epub is an epub, regardless of whether Amazon sells it as such.

The purpose of an ISBN is to identify a specific version of a book; that's why hardbacks and paperback editions of the same book have different ISBNs, although they contain the same text. Similarly different formats of the same ebook should each have an unique ISBN, even if their contents are the same.

Of course, many authors don't do this, but that is the way the ISBN system is intended to work.

[AnemicOak]

And format doesn't just mean ePub or Kindle, etc. If DRM is applied to an ePub then each version with the various DRM is a different format. In other words a "standard" Adobe DRM'd ePub is a different format from an Apple DRM'd ePub or a DRM-free ePub. However if the retailer, such as Amazon or Apple, is the only place to get a specific format of a book and if that retailer doesn't require ISBN's then an ISBN isn't required.



From the ISBN Manual (section 6.3)...
https://www.isbn-international.org/s...12%20-corr.pdf

End users need to know a) whether the e-book that they are purchasing will work on their device or software and b) what they will be able to do with it (e.g. copy, print, lend, text to speech etc.). This is normally defined by a combination of file format and software known as Digital Rights Management (DRM) which controls, by technical means, the use that can be made of the e-book. Separate ISBNs will facilitate management, dissemination and discovery of that information as well as delivery of the appropriate version of an e-book.

 Where a specific qualifying e-book is available in different file formats, each different format that is published and made separately available should be given a separate ISBN.

N.B. A file format is a particular way that information is encoded for storage in a digital file. In the case of e-books, the file format is often a combination of an underlying file type (such as EPUB, .pdf etc) and digital rights management software (such as Adobe’s ACS4, Apple's Fairplay etc.).

 Where proprietary DRM is used that ties a version to a specific platform, device or software, separate ISBNs should be used for each such version.

 Where digital publications are being supplied by a retailer that is the sole provider of e-books in a proprietary format that can only be bought through their own websites (e.g. Amazon Kindle, Apple i-books) and that retailer does not require ISBNs, it is not necessary to assign ISBNs to those versions, although it may be useful to do so for tracking sales or for listing publications in third-party databases of available e-books. If ISBNs are assigned, they should be unique to that version.

 A new ISBN may be assigned when a book is digitised by a library or other organisation under certain circumstances. If the electronic version is made available to the public, then as a new product it should be identified by a separate ISBN, regardless of whether or not there is a charge for access to the digital version.

 Where a publication is available in a supply chain with more than one specific type of DRM, whether offered by the original publisher or by a vendor later in the chain, then each of these are unique products that need to be identified by unique ISBNs.

Example 1: A publisher produces two EPUB versions of the same book, each with different DRMs and then distributes them through the supply chain, through different intermediaries. An ISBN is required for each of the specific
DRM versions of the product.

Example 2: A publisher produces a file in EPUB format and releases this to a
vendor who applies two different types of DRM to the EPUB and makes the two versions available separately, as two distinct products. An ISBN is required for each of the specific DRM versions of the product (the ISBN may be assigned by the publisher or by the vendor if the publisher does not do so).

Example 3: A vendor offers to the public the possibility to buy an e-book and to customise on demand the type of DRM to be applied. In this case, the DRM is applied at transaction level and there is no need to assign different ISBNs, since there is no ambiguity in the dialogue between the vendor and the buyer.

 If a publication is made available with different usage rights (e.g. adjusting the usage settings so that printing is allowed in one, but not in another), each version must be assigned a unique ISBN. In almost all cases usage rights are controlled using settings within the DRM software.

Example 4: A publisher releases a publication — one version of the publication is available with accessibility features such as text to speech (controlled through the DRM software) and one without. Each of the versions must have unique ISBNs in order that the particular attributes are clear to potential buyers and users (especially those looking for accessible publications) and so that the versions are separately identified. However, also in this case, when the usage rights are defined during the transaction between the vendor and the user, there is no need to assign separate ISBNs.

Example 5: A publisher releases a publication in one format with one ISBN and then offers to customers a service to acquire different usage rights on demand. Similarly to example 3 above, separate ISBNs are not required to identify the individual customised transactions.

 If publishers are using intermediaries to generate different formats of their e-books, then they should provide separate ISBNs for the intermediaries to assign to each format.

(N.B. The method outlined in this paragraph is not the recommended solution and should only be used in cases where a publisher refuses to assign individual ISBNs to each product).If a publisher will not provide ISBNs to intermediaries for each separate format then intermediaries may assign their own ISBNs. ISBN agencies will provide ISBN registrant elements to intermediaries for this purpose. In this case ISBNs and related metadata should be reported back to the publisher and to the national ISBN agency and other bibliographic agencies.

[Hitch]

Originally Posted by Notjohn

That's not what Hitch just said!

Or what I understood her to say: that an epub is an epub is an epub, regardless of whether Amazon sells it as such.

What? Which post are we discussing? When my clients ask about ISBNs, I ask them a set of questions, e.g., are you selling on Amazon, or Amazon + other places? Are you FTP'ing an ePUB to Amazon, and other places, or not? Upon what other retailers do you expect to sell?

THEN, I tailor my ISBN response, based on the answers to those questions. I have a vanilla ISBN-thing on my FAQ, (This is the one that never gets read--has a case of tl/dr; http://www.booknook.biz/ebook-conver...elf-publishing ) telling them that if they solely plan on selling on Amazon, iBooks and Nook, they simply don't NEED one.

Originally Posted by AnemicOak

And format doesn't just mean ePub or Kindle, etc. If DRM is applied to an ePub then each version with the various DRM is a different format. In other words a "standard" Adobe DRM'd ePub is a different format from an Apple DRM'd ePub or a DRM-free ePub. However if the retailer, such as Amazon or Apple, is the only place to get a specific format of a book and if that retailer doesn't require ISBN's then an ISBN isn't required.

Yeah, well..Bowker being Bowker, of course they have some logical argument as to why you need ISBNs for each "version." It's in their own self-interest. However, ISBNs exist solely for the purpose of ordering, fulfillment and payment. Period.

Therefore, discussing ISBNs in any environment in which the publisher uploads a copy of the book (digital book or POD, really, but let's stick with the convention of ISBNs for a print book), and the retailer does everything else vis-a-vis order fulfilment, collecting payment, paying out to the publisher, etc., then an ISBN is, truly, a moot point. It's gilding the lily.

Why? Because Amazon et al aren't "ordering" the book from a distributor. They're simply copying the source file and setting it to be downloaded by buyer X. Buyer X downloads the file, and Amazon collects the money therefor, albeit not in that order. There's no ordering, fulfillment and payment, in the "supply chain," because the supply chain has ceased to exist, in the tradtional sense of the word. Ergo, it's absurd to have ISBNs for any book that is solely sold in that fashion.

If, however, a seller/publisher goes through ANY type of distributor, like Smashwords or Draft2Digital, then having an ISBN serves a legitimate purpose. Those distributors bulk-upload ePUBs via FTP, sending along an ONIX or CSV/Excel metadata sheet. The ISBNs here serve the purpose of distinguishing Book A from Book B, with less chance of human error. So, yes, there, there is a reason to have one/them.

If the distributor were the party putting DRM on the books, again, that would be a different scenario, but that doesn't happen, either.

In fact, it's inconceivable, in this day and age, the way things worked out, that a publisher even COULD assign an ISBN to the book, once DRM is applied, because 99% of the DRM that's applied, is applied by the RETAILER (Amazon, B&N, iBooks, yadda) after the book is uploaded and set to publish. How could John Doe publisher go in and assign that ISBN, post-facto? I mean, sure, they could log BACK into the Bookshelf, Dashboard, etc., and THEN assign ISBNs, but...crappity. Talk about over-thinking something!

nj: still want to know exactly which post you're taking that from, and the context, please. TY.

Hitch

[Notjohn]

Sorry, Hitch! I misunderstood what you posted here:

ePUB translate fine to MOBI if what you're doing doesn't need "anything." If you need to make a "One Ring to Rule them All" ePUB, then you have an issue, as you will run into problems with media-queries in the same ePUB, if it has to pass ePUBcheck. This means--by definition--that the ePUBs being uploaded are, of necessity, more vanilla than those which are specifically made for MOBI. (Hence: non-fiction-type books which are lower in standard than need be, in order to fit into the ePUB FTP mold.) Alternatively, the retailer has to make two ePUBS w/two ISBNs; one expressly for mobi, replete with media-queries, and one without, for the ePUB vendors.

Which I thought you were saying that if I upload an epub to the KDP that is identical to the one I upload to Barnes & Noble, then they could carry the same ISBN.