Engadget claims Adobe "developed" ePub

[pilotbob]

Ok,

I think Engadget has it's facts wrong here... or I do? This http://www.engadget.com/2009/10/25/s...ook-with-epub/ article boldly states:

The ePUB standard, developed by Adobe, allows consumers to purchase books at a variety of digital stores and use them on a wide range of compatible devices without the manufacturer having to explicitly support them.

Of course the Wikipedia article on ePub http://en.wikipedia.org/wiki/EPUB doesn't mention anything about Adobes involvement.

I personally think the the author of the Engadget article is a bit confused. Adobe developed the Adept DRM wrapper and a mobile reader device SDK and encryption server product which packages ePub (and PDF) files.

Do people feel that this confusion over the ePub format verses the Adobe DRM isn't going to confuse people. Heck, if Engadget is confused, how is the lay person not going to be.

If I am totally of base on this, perhaps I am the one that is confused.

Discuss.

BOb

[Dylrob]

Considering how frequently Engadget writers fumble with facts, I wouldn't give them much credit here.

[zacheryjensen]

Originally Posted by Dylrob

Considering how frequently Engadget writers fumble with facts, I wouldn't give them much credit here.

Yeah I have to agree, they make numerous factual errors in their reporting. Though that does not rule out their example of confusion. Anyone could make the mistake that somehow adobe produced ePub when in reality they have only adopted it. Especially the the prevalence of their content server associated with ePub use.

Frankly I don't think it matters at all. ePub + DRM != ePub. DRM poisons an "open" "standard" making it neither. So all the excitement over ePub adoption by companies wrapping it up in DRM is misplaced... severely.

[Abecedary]

It's true that Adobe didn't develop ePub -- it was developed by the IPDF. However, Adobe is one of the largest technology companies involved with the IPDF, and I think it's fair to say that they had a fairly large role in steering some of the decisions that the IPDF made. But again, they didn't develop the format themselves.

As for the credibility of Engadget, to me it's always seemed like a site run by fanboys that just happens to have a decent budget and a large company standing behind them. But that still doesn't mean that their "reporting" is particularly accurate.

[Direct Ebooks]

Its widely known in the industry that Adobe are heavily involved in the development of Epub. I dont see anything wrong with this really, as it is an open format.
Ok, so it benefits Adobe greatly as they have the drm and distribution platform for the format, but ultimately, the consumer wins as better and better versions of the format and its delivery emerge (I'm thinking improved features, rentals, sociable drm etc)

The only danger would be if Adobe assumed control over Epub which is unlikely.

[Nate the great]

Originally Posted by Direct Ebooks

Its widely known in the industry that Adobe are heavily involved in the development of Epub. I dont see anything wrong with this really, as it is an open format.
Ok, so it benefits Adobe greatly as they have the drm and distribution platform for the format, but ultimately, the consumer wins as better and better versions of the format and its delivery emerge (I'm thinking improved features, rentals, sociable drm etc)

The only danger would be if Adobe assumed control over Epub which is unlikely.

I think they already have control over the format.

[fjtorres]

The article is factually correct.

The epub "standard" that allows consumers to buy epub books is owned lock, stock, and barrel by adobe. They control the DRM, the back-end servers, the reader software, and the file creation software. For all intents and purposes, epub is what adobe says it is, not what the nominal spec says.

Just look at the calibre and sigil forums; whenever there is an issue displaying an epub file, who has to adjust? The adobe software? Or the conversion tool?

Since the committee spec, like all committee specs, is loose and has room for interpretation, and there is no serious compliance program with teeth, the dominant interpretation is adobe's. Moving forward, epub is, in effect, adobe-controlled. No two ways about it; even B&N had to go through Adobe to implement their own *proprietary* DRM, which has now been subsumed and is controlled and licensed by adobe.

Absent a certification program that can tell adobe to stick to the letter of the spec, the true test of epub compliance is how it displays on ADE.
That is true control.

And since they are the ones pushing for its adoption as a counter to big bad evil Amazon they are in fact "developing the epub standard".

Nothing to fault the author for, other than not fully documenting his facts.
But the facts, he's got them right.

[ahi]

But, but, but... isn't ePub OPEN like the endless blue skies of Mongolia, unfettered by the ugly corporatism afflicting all other eBook formats that are therefore not just impure but downright soiled?

Did my mother LIE to me???

- Ahi

[Ankh]

Originally Posted by fjtorres

The article is factually correct.

The epub "standard" that allows consumers to buy epub books is owned lock, stock, and barrel by adobe. They control the DRM, the back-end servers, the reader software, and the file creation software. For all intents and purposes, epub is what adobe says it is, not what the nominal spec says.

I disagree. The non-DRM portion of the standard is definitely not "owned", and, at worst, mildly influenced (through their contribution to the standardization body) by Adobe.

If one assumes that DRM for ebooks will follow the fate of DRM for music (that is, disappear), the de facto Adobe control of the DRM side of ePub is time-bound, as well.

I couldn't care less about Adobe's control of the DRM ePub's.

[edembowski]

Originally Posted by fjtorres

The article is factually correct.

The epub "standard" that allows consumers to buy epub books is owned lock, stock, and barrel by adobe.

This is factually incorrect, but to a large degree true. Adobe does not own the ePub standard at all, but they are big enough to be able to influence it any way they want. Take a look at http://www.openebook.org/ Here's the list of members: http://www.openebook.org/membership/currentmembers.asp

They control the DRM, the back-end servers, the reader software, and the file creation software. For all intents and purposes, epub is what adobe says it is, not what the nominal spec says.

Since the commercial viability of the format does depend so heavily on DRM and device interoperability, they do have a strong edge. Although they do sell their own creation tools, publishers are by no means bound to use them. They do not have a hold on the reader software or the creation tools, but that's OK for them. The DRM component is where the money is.

Just look at the calibre and sigil forums; whenever there is an issue displaying an epub file, who has to adjust? The adobe software? Or the conversion tool?

It's always easier for the small guy to adapt to the big guy. For the past 20 years, whenever there has been a technical standard, bigger companies' interpretations of that standard would prevail for the sake of interoperability.

Since the committee spec, like all committee specs, is loose and has room for interpretation, and there is no serious compliance program with teeth, the dominant interpretation is adobe's.

This is largely true, but what "teeth" would you recommend? There is no such enforcement agency for mpeg video, and yet there is interoperability. There is no enforcement for jpeg yet I can open jpeg images on any platform.

Moving forward, epub is, in effect, adobe-controlled. No two ways about it; even B&N had to go through Adobe to implement their own *proprietary* DRM, which has now been subsumed and is controlled and licensed by adobe.

I don't think we know enough about the DRM that B&N will have, or how it significanly differs from what we have today. From everything that I've read, it could be implemented with the exact same technology as we have today. The "social" aspect of it is not a new thing; libraries do it today with ePub. Until we actually see what they are doing, we won't know what the interoperability is like, if it really is a new DRM system or just a new provisioning model.

Absent a certification program that can tell adobe to stick to the letter of the spec, the true test of epub compliance is how it displays on ADE.
That is true control.

I do agree completely that Adobe has a very strong hold on the ePub standard, but I still do not see a certification program helping. It's a published standard, and it is in Adobe's best interest to conform to that standard. Note that the standard does provide for implementing arbitrary DRM systems while maintaining compliance. From the standard:

"Reading Systems may include additional processing functions, such as compression, indexing, encryption, rights management, and distribution. "

And since they are the ones pushing for its adoption as a counter to big bad evil Amazon they are in fact "developing the epub standard".

They're not the only ones. The eBook reader manufacturers are pushing for it also. Sony is not one of the "small guys" and does carry a lot of weight.

Nothing to fault the author for, other than not fully documenting his facts.
But the facts, he's got them right.

He didn't. As stated several times in this thread, IPDS owns the standard, but Adobe does have a great deal of control. The article is factually incorrect.

- Ed

[DMcCunney]

Originally Posted by Abecedary

As for the credibility of Engadget, to me it's always seemed like a site run by fanboys that just happens to have a decent budget and a large company standing behind them.

Correct. Engadget is part of the Weblogs, Inc. network, and that, in turn, is part of AOL.

But that still doesn't mean that their "reporting" is particularly accurate.

Like anything else on the Internet, wise readers season with appropriate amounts of salt and look for independent confirmation of claimes.
______
Dennis

[fjtorres]

We may by dealing with semantics but in the real world there is a difference between standards and paper specifications. Standards are tied to actual products and there are penalties for not adhering to them (as MS discovered when they licensed Java and didn't read the buried fine print).
Specifications simply list product features and components or attributes.Epub aspires to be a standard but the bodybthat drafted the specification did not tievit to any product nor is their any meaningful certification process that say; you either pass this test or you can't call it epub. Such a test must by definition require ecactly the same performance on all certified products. (DVDs are supposed to play the same way on all DVD players regardless of what code lies underneath; epubs display differently pretty much everywhere.)

A "standard" without a certification process and penalties for incomplete/improper compliance is just a specification in disguise. Without a meaningful certification process the ebook products that people can buy will follow the defacto standard set by adobe just as in the early days of PCs the standard for PC compatibility wasn't MS-DOS, but rather Lotus 1-2-3 and Flight simulator. If it ran those, it was deemed PC compatible and it stayed that way until MS finally asserted their control with MS-DOS 5. ("DOS ain't done until Lotus won't run", says the legend.)

Regardless of what the standards body says, in real world terms, adobe controls epub: If it won't display properly in ADE, it isn't "proper" epub in the eyes of the buying public. And since every eReader supporting ePub with DRM uses adobe code, everything else is up the creek; pay adobe its fees or try to convince the customers that the inconsistencies that *will* arise aren't your fault.

Heck, even licensing from adobe won't prevent that; just ask the folks with Hanlin-based readers...

[edembowski]

Originally Posted by fjtorres

...Epub aspires to be a standard but the bodybthat drafted the specification did not tievit to any product nor is their any meaningful certification process that say; you either pass this test or you can't call it epub. ...

We'll have to agree to disagree here. There are too many standards in existence that do not follow your model for me to buy what you're saying. Enforcement does not a standard make.

- Ed

[DMcCunney]

Originally Posted by fjtorres

We may by dealing with semantics but in the real world there is a difference between standards and paper specifications. Standards are tied to actual products and there are penalties for not adhering to them (as MS discovered when they licensed Java and didn't read the buried fine print).

Agreed in the sense that a standard is useless if it isn't actually implemented by any products. The point to a standard is something everybody can implement and use.

Since the products which implement standards are sold for money, there is a lengthy and highly political process involved in making something a standard. Various players in whichever industry will say "We're all in favor of standards. Do it our way!". Depending upon the standard being hammered out, there may be several incompatible approaches being put forward. In some cases, companies have made bets that their approach, or something close too it, will be anointed as the standard, and have shipped prodcuts based on it, so the stakes can be high.

Specifications simply list product features and components or attributes.Epub aspires to be a standard but the bodybthat drafted the specification did not tievit to any product nor is their any meaningful certification process that say; you either pass this test or you can't call it epub. Such a test must by definition require ecactly the same performance on all certified products. (DVDs are supposed to play the same way on all DVD players regardless of what code lies underneath; epubs display differently pretty much everywhere.)

This is not meaningful, as variation is inevitable. For example, assume your ePub file contains full color cover and interior illustrations. Your eInk based reader doesn't do color. Color images will be rendered as 16 shade gray scale. Adobe Digital Editions on the PC does do color, because the PC hardware does. So you now have a fundamental difference in the way the file will display, based on limitations in the underlying hardware.

This is not something any certification process such as you advocate can address.

A "standard" without a certification process and penalties for incomplete/improper compliance is just a specification in disguise. Without a meaningful certification process the ebook products that people can buy will follow the defacto standard set by adobe just as in the early days of PCs the standard for PC compatibility wasn't MS-DOS, but rather Lotus 1-2-3 and Flight simulator. If it ran those, it was deemed PC compatible and it stayed that way until MS finally asserted their control with MS-DOS 5. ("DOS ain't done until Lotus won't run", says the legend.)

So it's a spec in disguise. So what? From our point of view, the idea is that it's a spec everyone can write to and support. I expect an ePub file to be readable on any device that supports the ePub format, and I expect "graceful degradation", such as a decent grey scale conversion of color images in the file if my device doesn't support color.

The market does the policing here. If the informal test is "It looks as expected in Adobe Digital Editions", it's my responsibility as a content producer to create ePub files that do. If I am a device manufacturer or software developer, it's my responsibility to make a device or write software that will do the job the same as Adobe Digital Editions to the extent possible, so differences are those imposed by the underlying hardware.

Content that isn't displayable on any specs confirming device, and devices that don't properly conform to the spec will get weeded out soon enough because people won't buy them. The biggest issue with any spec are the gray areas that are open to interpretation as to just what you should do in a particular case. Look at any discussion of the specs for the C and C++ languages, and how various compilers have chosen to implement the specs for good examples of the issues involved.

And no, that informal compatibility test didn't come to an end when Microsoft asserted control in MS-DOS 5.

The issues involved had little to do with MS-DOS and everything to do with hardware. While you technically could do hardware access through the BIOS and MS-DOS, most software vendors wrote directly to the hardware for performance reasons. The informal "runs Lotus and Flight Simulator" test was primarily for video display, and become less relevant as PC manufacturers began making hardware that was compatible, with BIOSes that were likewise. Once upon a time Compaq was the gold standard for IBM-PC compatibility, and could charge a price premium because you could expect it to be compatible with with genuine IBM kit.

MS didn't truly assert dominance until Windows. Windows was multi-tasking, and you pretty much had to do everything through the OS. You couldn't assume, as you could in MS-DOS days, that your program had sole control of the machine and could talk directly to the hardware when it ran. As of Windows NT, the OS became positively surly if programmers tried to bypass it.

(I was around back then, and have fond () memories of when the IBM PC was first becoming popular in corporate America, displacing Apple ][s running VisiCalc, and Lotus 1,2,3 was forcing everyone to upgrade to a whole <gasp!> 640K of RAM to accommodate enormous Lotus spreadsheets.)

Regardless of what the standards body says, in real world terms, adobe controls epub: If it won't display properly in ADE, it isn't "proper" epub in the eyes of the buying public. And since every eReader supporting ePub with DRM uses adobe code, everything else is up the creek; pay adobe its fees or try to convince the customers that the inconsistencies that *will* arise aren't your fault.

Heck, even licensing from adobe won't prevent that; just ask the folks with Hanlin-based readers...

<shrug> So?

It's not in Adobe's interest to play games with the spec. They are a B2B outfit. They make their money licensing stuff like this. They want a spec everyone can adhere to. If someone chooses to bypass them and create their own software to produce or display ePub files, that's not going to kill Adobe. They are betting it will be faster and cheaper for most folks to license their code than to roll their own, and mostly, they'll be right.

And sorry about Hanlin, but simply licensing code from another party doesn't mean I will successfully implement that code on my hardware.
______
Dennis

[DawnFalcon]

ADE is the dominant render for handheld devices, sure. But if there's an open liscence program - and I sure haven't heard about anyone being refused a liscence - it dosn't even come close to Amazon's tactics.

Calibre displays non-DRM'ed ePub just fine without using ADE...