(sigh), Kindle/KPF format Blues...

[Hitch]

Originally Posted by JSWolf

The way I see it is if you want to do interactive books with audio and video, do so as an app. That would works so much better and be able to be written for the platforms in which they will work. Write an app for iOS and Android and they will work. Write them as eBooks and they may or may not work.

Wolfie, apps are arithmetically more expensive than eBooks and part of that is that they have to be approved by the platforms upon which they function, e.g., iTunes, Droid, etc. A basic, barebones app will run you $1200-$1600 and that's for ONE platform, not two.

An eBook, on the other hand--that's not remotely so expensive and with a modicum of talent, you can create eBooks for most eBook-reading environments.

If you want math to show correctly, use SVG. It's got more support then MathML. I can read an ePub in ADE 2.0.1 that uses SVG. You can read KF8 that has math in SVG. I remember back when ADE was at 1.7.2. Someone created an ePub with complex math that used SVG and it resided when you change the font size. It looked like a magazine article.[/QUOTE]

Hell, maybe in the world of ePUBs, but NOT in the world of mobi/Kindle, which is the topic we're discussing here.

You can use MathML now for ePUB3>MOBI or you can use PDFs to make a fixed-layout (which brings us back to the KPF blues), but you are still leaving out a huge part of the marketplace, either way. All the KF7 devices in the former and everything but Kindle Fires and some of the desktop readers (K4Mac/PC, K4iOS/K4Droid) in the latter.

Hitch

[JSWolf]

Originally Posted by Hitch

Wolfie, apps are arithmetically more expensive than eBooks and part of that is that they have to be approved by the platforms upon which they function, e.g., iTunes, Droid, etc. A basic, barebones app will run you $1200-$1600 and that's for ONE platform, not two.

An eBook, on the other hand--that's not remotely so expensive and with a modicum of talent, you can create eBooks for most eBook-reading environments.

If you want math to show correctly, use SVG. It's got more support then MathML. I can read an ePub in ADE 2.0.1 that uses SVG. You can read KF8 that has math in SVG. I remember back when ADE was at 1.7.2. Someone created an ePub with complex math that used SVG and it resided when you change the font size. It looked like a magazine article.

Hell, maybe in the world of ePUBs, but NOT in the world of mobi/Kindle, which is the topic we're discussing here.

You can use MathML now for ePUB3>MOBI or you can use PDFs to make a fixed-layout (which brings us back to the KPF blues), but you are still leaving out a huge part of the marketplace, either way. All the KF7 devices in the former and everything but Kindle Fires and some of the desktop readers (K4Mac/PC, K4iOS/K4Droid) in the latter.

I do think we'd be using ePub 3 with MathML if Apple had not gotten the standards committee to add all crap that's not eInk friendly.


Hitch[/QUOTE]

You are talking older Kindles that only handle Mobi and not KF8. But what about older devices such as Sony Reader that do not handle ePub 3's MathML. But the Sony's do handle SVG. IMHO, the best way to handle complex math is SVG and for older Kindles, you can use a PNG to display the math. That's about all you can do that will work in more situations then MathML.

[Tex2002ans]

Originally Posted by jhowell

Amazon invented their own undocumented, non-standard markup for the features of Illustrated Layout.

The ability to wrap text around arbitrary shapes used a property called -amzn-shape-outside. This defines the border of an image as a polygon instead of a rectangle. Like this.

Ahh, probably just using CSS3 shapes:

"Obliterate Boxiness with CSS Shapes"

... I suspect they probably just pushed it way before the specs were more finalized.

What was the format of the actual animations. MP4s? APNGs?

Complete Side Note: I was just reading this article about Netflix:

Bringing Rich Experiences to Memory-Constrained TV Devices

and they were discussing their proprietary SNG format used to animate foregrounds. (Examples near the end of article.)

Originally Posted by Hitch

As Tex2002ans would tell you, ME TOO. We're working together (to be honest, he's doing all the work part) on a book right now that badly, badly needs it. (sigh).

Yeah, Physics book, ~1100 equations. Many long equations + systems of equations, very important need for strict alignment.

Originally Posted by Hitch

Wolfie, apps are arithmetically more expensive than eBooks and part of that is that they have to be approved by the platforms upon which they function, e.g., iTunes, Droid, etc. A basic, barebones app will run you $1200-$1600 and that's for ONE platform, not two.

[...]

An eBook, on the other hand--that's not remotely so expensive and with a modicum of talent, you can create eBooks for most eBook-reading environments.

And again, the sales of this... nobody buys these types of "apps".

You also have the yearly developer fees, etc.

They also need long-term maintenance, constantly updating for the latest standards/guidelines, etc. (Just look at all the iOS games completely abandoned because of the forceful change to 64-bit. Android is going down a similar path with updating the mandatory minimum API.)

Plus, you would probably piss people off with the inconsistent reading experiences (being able to change fonts, backgrounds, text-to-speech, notes/highlights, etc. etc.)

Originally Posted by JSWolf

I do think we'd be using ePub 3 with MathML if Apple had not gotten the standards committee to add all crap that's not eInk friendly.

I hate Apple as much as the next guy, but I think you've gotten this history wrong. There were a lot of big (and legacy print-) publishers pushing for all that stuff:

• Magazines (Fixed Format + audio/video)
  
  • Needing more complex spreads + advanced CSS [columns, CSS3 shapes, [...]].
• Educational publishers (Fixed Format + audio/video)
• STEM publishers (MathML)
• Web developers
  
  • EPUB2 was stuck in the stone ages, and was being crippled by Adobe's RMSDK + their extreme slothiness.
    
  • One of the reasons why IDPF joined W3C with EPUB3 is so it can be using some of the latest HTML5+CSS3 [proper web backends instead of creating their own custom renderers].
    
  • Better compatibility with actual HTML means you can use all the usual HTML tools/exporters/[...].
    
    • Also why a lot of the EPUB-specific markup was being dropped for HTML5 equivalents.
      
    • And why publishers then pushed for things like CSS3 Paged Media (float:top/bottom, Footnotes, etc. etc.)

So Apple was one that was pushing ahead of the curve with iBooks (although making it all proprietary and locking down to their ecosystem only... typical Apple maneuver).

MathML Side Note: And with MathML specifically, Apple is actually one better ones.

As I've written previously, they're one of the few who are actually interested in having MathML actively updated/supported. (Both Chrome + Mozilla have dropped the ball for a decade+.)

History Side Note: If you wanted to read more about that EPUB3 history + print stuff, check out Matt Garish's 2014 article "What is EDUPUB?".

In it, he explains some of the irks happening around that time, and mentions the AAP (Association of American Publishers) having issues with EPUB3.

This lead me to AAP's 2013 whitepaper "The AAP EPUB 3 Implementation Project", which broke down lots of important features trade publishers needed in EPUB3 and why.

And for extra commentary on the AAP paper, see Infrogrid's article on it. As usual, I agree with a lot of their assessment.

And even had a little chuckle at this:

Here was part of AAP's list:

[...] examples of issues currently encountered by publishers in attempting to provide consistent EPUBs to reading systems and the variation in rendering and behavior currently encountered [...]:

• Lack of table support
• Lack of SVG support to render text on paths
• Lack of support of embedded fonts
• Lack of consistent support across platforms of @font-face in CSS
• Inconsistencies in the implementation of image sizing and positioning
• Lack of support for good styling on lists and list-style types
• Lack of broad Unicode support across platforms
• Lack of support for the @hidden attribute

[...]

While it is understood that both reading systems developers and publishers will need to make their own decisions in regard to their systems and publications, it was clear to all participants in this initiative that improvements in both reading system feature implementation and practices for creating EPUBs on the part of publishers are not just important, they are urgent. As mentioned above, the current situation is one of great inconsistency, requiring workarounds and multiple variant files, a situation that must be improved by the better implementation of this important standard.

Still haunting us to this day, and it's exactly what we're complaining about here 6 years later!

And then here's Infogrid's commentary on the above:

This reads like an ePub2 feature list critique. Most particularly an Adobe Digital Editions lack of features list. [...]

Reading systems are now being built on highly standards compliant engines such as Mozilla and Webkit that are years in advance of the ePub3 specification. This is certainly a list of features that if they are not supported in a reading system should be subject to positive public comment and criticism.

So if anything, I would put lots of blame on Adobe/RMSDK for holding EPUB3 back so far.

Apple (iBooks) and Kobo (KEPUB) were the ones moving forward...

And as was discussed over the years, even Amazon supports some EPUB3+CSS3 stuff better than some EPUB3 readers... which is just embarrassing. (One case this absolutely isn't true though is the SVG+MathML support. Even the ol' EPUB2 readers seemed to have pretty good SVG support.)

[Little.Egret]

Originally Posted by Tex2002ans

--Snip--

Side Note #2: (And I forget, can big publishers actually have access to this?) ONE thing that would be helpful for some self-publishers is limiting certain ebooks to ONLY be read on specific Kindles (or KF8 or higher).

I love the fantastic backwards compatible support Amazon does, but there are just some ebooks that are not possible to be read on KF7... heavy math is one of them.

Amazon does allow publishers to specify a subset of Kindles.

Only Fire Tablets and Apps is the most frequent but NO Mobi7 (in effect) can be found.

[Hitch]

Originally Posted by Little.Egret

Amazon does allow publishers to specify a subset of Kindles.

Only Fire Tablets and Apps is the most frequent but NO Mobi7 (in effect) can be found.

Why do you think that? Other than Print Replica--for the moment, being available only on Fires, effectively--where else do you see the sales being restricted by the publisher?

Hitch

[jhowell]

Originally Posted by Tex2002ans

Ahh, probably just using CSS3 shapes:
... I suspect they probably just pushed it way before the specs were more finalized.

Yes. I think they based Kindle in Motion on emerging specs when they could.

Originally Posted by Tex2002ans

What was the format of the actual animations. MP4s? APNGs?

Animated WebP.

[JSWolf]

Originally Posted by Little.Egret

Amazon does allow publishers to specify a subset of Kindles.

Only Fire Tablets and Apps is the most frequent but NO Mobi7 (in effect) can be found.

Given that a subset of Kindles can be specified, would it be possible to specify just Kindles that can handle KF8?

[Hitch]

Originally Posted by JSWolf

Given that a subset of Kindles can be specified, would it be possible to specify just Kindles that can handle KF8?

Wolfie:

AFAIK, that cannot be done by the publisher. It's AMAZON that decides that a book is restricted to devices XYZ. You're thinking of the CSS; I'm talking about the actual sales on the website, the sales page that says "available on these devices."

Believe me, kids--I just went through this rodeo with a customer--THIS VERY CUSTOMER, the guy that was the subject of this thread--about how his fury with me is not about the links inasmuch that it cannot be purchased on eInks. Amazon's own Help pages say that they will "selectively" allow certain PR files to be purchased on eInks (like the Debbie Harry book, which was a fracking disaster, made with the Kids' Book Creator program), and all that.

As far as I know, there's no way that any INDY publisher can tell Amazon to restrict sales to Device X. I've never even seen that option for PR books--they simply go through and then it's Amazon that restricts the viewability on the Sales page.

Little.Egret, do you have contrary info????? I'd love to know it, truly.

Hitch

[Quoth]

Agree, Hitch.
Basically there are now Kindle ebooks which are not really ebooks, but sort of an Amazon proprietary epub3-fixed or pseudo PDF. So they only work on things that are not really Kindles, such as the Fire and maybe apps. I got one ages ago and was mystified that it wasn't available for my actual kindle. I managed to get it into Calibre and found out that though it was a text novel that could easily have been the regular format, the "Publisher" had wanted a layout matching the paper edition. So without a massive edit the converted version was ghastly layout on a real kindle or epub reader after conversion.

IMO this format should have a new name and not be called Kindle or eBook. It's just a confusion. I can see the value of it for text books or picture books that need a Fire or tablet. Amazon have been idiotic slipping it in under the Kindle and ebook Branding.
It was stupid too that the Fire was called a Kindle Fire, it's an LCD Android Tablet customised to Amazon. It's not remotely like a Kindle.

So those are the only two categories:
1) Real ebooks that work on real Kindles and properly reflow.
2) Semi-fixed layout Kindle branded electronic books, sort of like fixed layout epub3 or PDF, not ebooks as we know them, so need an app/Tablet. Won't work at all on a real Kindle. Won't convert properly to ebook and probably unusable on smaller screens, really for the Fire, though may run on an Android or iOS tablet via an app?

The two categories use different tools. (1) can use a Wordprocessor and can be uploaded as doc, docx, mobi or epub2 etc.
(2) Needs special tools, like DTP used to. The Kid's Book Creator is one such tool.

From point of view of novel author or Publisher of Fiction the fact that (2) exists is irrelevant. Because you'd want to be in Apple Store, Barnes & Noble etc too, using epub2 distribution.

From point of a Kindle owner (2) is evil because it's called a Kindle ebook. It's not. It should have a new name. It's between a real ebook and a PDF (a PDF is electronic, but only meant for proofing for paper, so page size is absolute).

[Little.Egret]

Originally Posted by Hitch

Why do you think that? Other than Print Replica--for the moment, being available only on Fires, effectively--where else do you see the sales being restricted by the publisher?

Hitch

Reading what passes for the minds of publishers is not something I do much.

My guess is that either publisher fonts or many (especially colour) illustrations is the usual reason.

I have forgotten the boilerplate text Amazon use, maybe "available on the following devices"? If someone will remind us, a Google search will be possible and even helpful

[jhowell]

Originally Posted by Hitch

Why do you think that? Other than Print Replica--for the moment, being available only on Fires, effectively--where else do you see the sales being restricted by the publisher?

Hitch

If you click the “available on these devices” in listings you get a pop up list and for some on the bottom it says:

Why?
This publication is not available for some devices. The publisher may have opted out of making it available on certain devices, or the reading experience may not yet be optimized for this publication on those devices.

That wording implies the publisher has made a choice.

I have seen this mainly for magazines, such as this one.

[Little.Egret]

Originally Posted by jhowell

If you click the “available on these devices” in listings you get a pop up list and for some on the bottom it says:



That wording implies the publisher has made a choice.

I have seen this mainly for magazines, such as this one.

Thanks.

It's a strange device list because it includes even the Kindle 1!

[Quoth]

It's restricted by the publisher only in the sense of what the Publisher has uploaded (a semi-fixed print related layout unsuitable for real kindles and likely best on Fire and may include apps).
There are essentially real ebooks for real Kindles, and now the option to create an electronic document that's not a PDF or a real eBook. Amazon then decides what it can run on, not the publisher. The publisher is though inherently basically limiting the document to Not-real-kindles by choice of creation tools, not by telling Amazon what they want it to run on.

Some publishers through ignorance are creating what could be real ebooks in this "not-actually-ebook" electronic book format because maybe they think it looks pretty.

It's an Amazon created mess / confusion and they are trying to blame publishers.

[Hitch]

Originally Posted by jhowell

If you click the “available on these devices” in listings you get a pop up list and for some on the bottom it says:

That wording implies the publisher has made a choice.

I have seen this mainly for magazines, such as this one.

It may imply it--but that's Amazon shifting the focus away from themselves. I'm sorry, but Indy publishers have NO, repeat, NO ability whatsoever to affect the list of where their eBooks can be read, other than using the various Amazon software options, e.g., Kindle Create's Print Replica option, and it's Amazon that "decides" where that book is read.

To wit, Amazon's own HELP pages will tell you that if you make a PR eBook, it's buyable and readable on eInks, right? Except---they're not. They're not at all. This very thread is about a customer of mine, that's irate that the PR eBook that we made for him cannot be read on eInks, Amazon's own Help pages be damned. Trust me, if he could choose, it would be served to eInks. It's not his choice.

@Little.Egret: I didn't ask you to mind-read Indy publishers or trade publishers. You stated, as a fact, that:

Amazon does allow publishers to specify a subset of Kindles.

...and I asked you to explain why you asserted that--not what's inside the heads of publishers.

Hitch

[Quoth]

Agreed, Amazon decides, based on what you upload. Thus the publisher doesn't directly decide and the process is opaque and could change.

Series listings are strange too. It seems you have to contact Amazon, the KDP meta info isn't enough.

Their help texts are one thing and what they do is another.