8 ms·

IDPF, EPUB Standardizing Body, Has Combined with W3C

131 points by rhythmvs 10y ago

rhythmvs 10y ago
I believe it a good thing that the EPUB standard will henceforth be further developed by and within the same body that develops the standards on which EPUB relies. After all, EPUB is “stripped down html5” anyway. As a developer of Web-based html5 books, I can certainly see the benefits of becoming enabled to re-use my static html and css ‘as-is’ and repackage into EPUB-based books for offline consumption by e-readers. But there’s some fierce objection against the merger of IDPF into the W3C [1][2], the key (?) argument being formulated as: > “The W3C is focused on promoting the Web, but eBooks are not websites. When the IDPF is gone, who will advocate for readers?” Maybe a fair point, but I don’t think I can agree. While it is true indeed that reading long-form content like books requires enduring focus, and that having to read them in a browser where linkbait always is luring to have you click away into a never ending feed of distraction, the problem is not the underlying technology. [1] http://www.publishersweekly.com/pw/by-topic/digital/content-and-e-books/article/72492-overdrive-s-steve-potash-moves-to-block-idpf-merger-with-w3c.html http://www.publishersweekly.com/pw/by-topic/digital/content-... [2] http://futureofebooks.info/ http://futureofebooks.info/
- staz 10y ago
  I thought that WhatWG were actually the ones developing HTML5?
  - kuschku 10y ago
    WhatWG is just rubberstamping "whatever Chrome implements" (sometimes with feedback from Firefox) as HTML5. The actual development is entirely controlled by the browser vendors, causing pain for everyone trying to parse HTML programmatically.
    - andybak 10y ago
      Because everything went so well when the W3C was left to their own devices...
      - kuschku 10y ago
        Certainly better than bullying cURL into accepting their idiotic URL specification. Especially considering what they want would rather be specified as a parser for generating URLs from user input, and not to simply demand every tool interacting with URLs to be able to parse malformed URLs.
        jcranmer 10y ago
        WHATWG didn't bully cURL into URL, people complaining that cURL didn't match browsers did that. The WHATWG made a decision long ago that its standards would be descriptive (describe how people parse it), not prescriptive (describe how people should write it). Anyone who attempted to write a web browser would have had to reverse-engineer how other browsers treated crap, because it was the only way to get websites to work. If you think the definition of URL was stupid, you should see what they had to do to support document.all: define a new concept in JS to represent the notion of "this looks and acts like undefined but you can actually use it as an object."
        kuschku 10y ago
        And a descriptive standard is entirely useless. The entire point of a standard is that implementors agree on a design definition, then implement it, and it stays consistent, forever. If you look at standards that work and fail, you’ll quickly notice a pattern. Prescriptive are Metric, the A-series of paper, the entire SI system, most open standards, etc. Descriptive are the imperial / US standard, Letter paper, Microsoft "Open" XML, etc. And before you complain that prescriptive standards are useless because you can never change legacy systems: Several countries have prescriptive language design, with legal authorities how the language has to be used, and they manage to deal with centuries of legacy data.
        10y ago
    - deleted 10y ago
      [deleted]
chris_wot 10y ago
I guess I've never really understood the need for ePub when PDF is now a standard. I'm sure I'm missing something, the question is: what is that thing?
- cicero 10y ago
  The big thing is that PDF is page oriented and ePub is flow oriented. An ePub book can be reformatted for different page and font sizes. A PDF book is difficult to read if the screen is not large enough.
- jck 10y ago
  EPUBs have reflowable text(HTML).
  - deleted 10y ago
    [deleted]
- chx 10y ago
  If you are reading an ePub format book on your Kobo and zoom in then it'll work as expected. If you are reading a PDF format book then after zooming in you will need to move the page around making reading incredibly awkward / impossible. In other words, ePub cares about where the chapters are and such, it is structured text, while PDF is a page description and what's on a single page will always be on a single page.
  - hollander 10y ago
    Aside from zooming, most ereaders offer the option to use a bigger font. That will result in a different text flow, which usually works. But it can break up text flow within a paragraph, within a sentence and even within a word. I've seen words break up into single letters, each letter one line.
- JustSomeNobody 10y ago
  PDF sucks on mobile and ebook readers. Seriously sucks. I apologize for the language but I find no other words that work.
jathu 10y ago
When I was making a simple EPUB app for my own use [1], I found it surprising that many publishers don't follow IDPF standards. Most do, but there are a significant amount that mix and match all sorts of rules. [1] http://jathu.me/bisheng/ http://jathu.me/bisheng/
- protomyth 10y ago
  Any pattern to it or anything in particular that struck you?
  - matwood 10y ago
    The problem is two fold. The first is that most authors and publishers are not very technical. The second is tools like InDesign created EPUBs that would fail the idpf epubcheck tool with errors [1]. Adobe has fixed some of these issues in later versions, but it's expensive for a publisher to re-export all their books. What this leads to is basically fixing random, one off issues depending on publisher and book. I would definitely suggest not writing your own reader and instead looking at something like Readium (and contribute if you have time!). [1] http://mademers.com/two-more-indesign-cs5-export-to-epub-bugs-to-report/ http://mademers.com/two-more-indesign-cs5-export-to-epub-bug...
    - Finnucane 10y ago
      I oversee the epub production for an academic publisher, and the epub conversions are created by our typesetter at the end of production. They do indeed do a bit of custom programming (and sometimes manual labor) to make the files come out decent. They're supposed to run epubcheck on every file before delivery. I'm the guy who ends up fixing all those little random errors, so I have to insist that the code be reasonably clean and orderly (they work to a spec document that I prepared). Plus, accessibility is a concern. Poorly coded and disorganized files don't play well for people who need assistive reading systems.
nivals 10y ago
This is good news. Making fully baked ePubs for the first few versions of the B&N Nook was more art than science due to some of the problem with ePubs.

131 points by rhythmvs 10y ago

I believe it a good thing that the EPUB standard will henceforth be further developed by and within the same body that develops the standards on which EPUB relies. After all, EPUB is “stripped down html5” anyway. As a developer of Web-based html5 books, I can certainly see the benefits of becoming enabled to re-use my static html and css ‘as-is’ and repackage into EPUB-based books for offline consumption by e-readers. But there’s some fierce objection against the merger of IDPF into the W3C [1][2], the key (?) argument being formulated as: > “The W3C is focused on promoting the Web, but eBooks are not websites. When the IDPF is gone, who will advocate for readers?” Maybe a fair point, but I don’t think I can agree. While it is true indeed that reading long-form content like books requires enduring focus, and that having to read them in a browser where linkbait always is luring to have you click away into a never ending feed of distraction, the problem is not the underlying technology. [1] http://www.publishersweekly.com/pw/by-topic/digital/content-and-e-books/article/72492-overdrive-s-steve-potash-moves-to-block-idpf-merger-with-w3c.html http://www.publishersweekly.com/pw/by-topic/digital/content-... [2] http://futureofebooks.info/ http://futureofebooks.info/

staz 10y ago
I thought that WhatWG were actually the ones developing HTML5?
- kuschku 10y ago
  WhatWG is just rubberstamping "whatever Chrome implements" (sometimes with feedback from Firefox) as HTML5. The actual development is entirely controlled by the browser vendors, causing pain for everyone trying to parse HTML programmatically.
  - andybak 10y ago
    Because everything went so well when the W3C was left to their own devices...
    - kuschku 10y ago
      Certainly better than bullying cURL into accepting their idiotic URL specification. Especially considering what they want would rather be specified as a parser for generating URLs from user input, and not to simply demand every tool interacting with URLs to be able to parse malformed URLs.
      - jcranmer 10y ago
        WHATWG didn't bully cURL into URL, people complaining that cURL didn't match browsers did that. The WHATWG made a decision long ago that its standards would be descriptive (describe how people parse it), not prescriptive (describe how people should write it). Anyone who attempted to write a web browser would have had to reverse-engineer how other browsers treated crap, because it was the only way to get websites to work. If you think the definition of URL was stupid, you should see what they had to do to support document.all: define a new concept in JS to represent the notion of "this looks and acts like undefined but you can actually use it as an object."
        kuschku 10y ago
        And a descriptive standard is entirely useless. The entire point of a standard is that implementors agree on a design definition, then implement it, and it stays consistent, forever. If you look at standards that work and fail, you’ll quickly notice a pattern. Prescriptive are Metric, the A-series of paper, the entire SI system, most open standards, etc. Descriptive are the imperial / US standard, Letter paper, Microsoft "Open" XML, etc. And before you complain that prescriptive standards are useless because you can never change legacy systems: Several countries have prescriptive language design, with legal authorities how the language has to be used, and they manage to deal with centuries of legacy data.
        10y ago
  - deleted 10y ago
    [deleted]

chris_wot 10y ago

I guess I've never really understood the need for ePub when PDF is now a standard. I'm sure I'm missing something, the question is: what is that thing?

cicero 10y ago
The big thing is that PDF is page oriented and ePub is flow oriented. An ePub book can be reformatted for different page and font sizes. A PDF book is difficult to read if the screen is not large enough.
jck 10y ago
EPUBs have reflowable text(HTML).
- deleted 10y ago
  [deleted]
chx 10y ago
If you are reading an ePub format book on your Kobo and zoom in then it'll work as expected. If you are reading a PDF format book then after zooming in you will need to move the page around making reading incredibly awkward / impossible. In other words, ePub cares about where the chapters are and such, it is structured text, while PDF is a page description and what's on a single page will always be on a single page.
- hollander 10y ago
  Aside from zooming, most ereaders offer the option to use a bigger font. That will result in a different text flow, which usually works. But it can break up text flow within a paragraph, within a sentence and even within a word. I've seen words break up into single letters, each letter one line.
JustSomeNobody 10y ago
PDF sucks on mobile and ebook readers. Seriously sucks. I apologize for the language but I find no other words that work.

jathu 10y ago

When I was making a simple EPUB app for my own use [1], I found it surprising that many publishers don't follow IDPF standards. Most do, but there are a significant amount that mix and match all sorts of rules. [1] http://jathu.me/bisheng/ http://jathu.me/bisheng/

protomyth 10y ago
Any pattern to it or anything in particular that struck you?
- matwood 10y ago
  The problem is two fold. The first is that most authors and publishers are not very technical. The second is tools like InDesign created EPUBs that would fail the idpf epubcheck tool with errors [1]. Adobe has fixed some of these issues in later versions, but it's expensive for a publisher to re-export all their books. What this leads to is basically fixing random, one off issues depending on publisher and book. I would definitely suggest not writing your own reader and instead looking at something like Readium (and contribute if you have time!). [1] http://mademers.com/two-more-indesign-cs5-export-to-epub-bugs-to-report/ http://mademers.com/two-more-indesign-cs5-export-to-epub-bug...
  - Finnucane 10y ago
    I oversee the epub production for an academic publisher, and the epub conversions are created by our typesetter at the end of production. They do indeed do a bit of custom programming (and sometimes manual labor) to make the files come out decent. They're supposed to run epubcheck on every file before delivery. I'm the guy who ends up fixing all those little random errors, so I have to insist that the code be reasonably clean and orderly (they work to a spec document that I prepared). Plus, accessibility is a concern. Poorly coded and disorganized files don't play well for people who need assistive reading systems.

nivals 10y ago

This is good news. Making fully baked ePubs for the first few versions of the B&N Nook was more art than science due to some of the problem with ePubs.