[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.)