Re: Goal of this group?

Sorry Arved – regarding "has anyone actually even stepped back and clinically examined EPUB, for example?”

Why, yes. As a matter of fact. I have. It’s actually part of my day job to know EPUB pretty well. You should also know that following the 80/20 rule, about 80% of the EPUB books in the world are not intended to have specific page layouts and are not designed to be printed, but instead are designed to be displayed in some way on some device which the implementor will not know in advance. EPUBs aren’t intended to replace PDFs or other ways of getting page layout algorithms onto printed pages. We already have plenty of standards about those particular subjects.

EPUB was designed to build on existing standards, BTW. HTML, CSS, and ZIP compression being the primary examples of the “don’t reinvent the wheel” approach.

In places where some would argue that EPUB does reinvent the wheel, I recommend digging deeper. If you talk to someone who was involved in one of the areas that have been accused of going where specs already exist (for example, the Canonical Fragment Identifier (CFI) specification – which looks like it could be solving use cases very similar to those solved by Xlink and XPATH), the conversation may reveal that existing specifications were carefully evaluated for use before the decision to strike out in a different direction was made. We had such a conversation very recently in an Open Annotations Working Group telecon regarding the CFI spec.

<opinion>The argument of “you should’ve used ‘X existing specification’” can turn into a holy war conversation within in any standards group, however. There are ongoing attempts outside of the IDPF to simplify what some people have declared to be overly complex. Some of these efforts are truly made in earnest, others are less well intentioned, and some people are just, well… crabby and refuse to be pleased. In short, you don’t have to look very hard for a cat fight, no matter what letters are at the top of the cover page… err… reflowable screen.</opinion>

The fact that EPUB titles are intentionally reflowable to fulfill many digital publishing use cases has been an issue that has come back to the IDPF often enough that the specification has been expanded to “pave over existing cow paths” (to borrow a phrase from the WHAT WG).

What cow paths? Here’s an example: Apple iBooks came up with a fixed page layout implementation a few iterations of iBooks before Apple released iBooks Author and the proprietary .ibooks format (which is not EPUB, Apple continues to support EPUB, too, but .ibooks are different). The fixed page layout implementation is not PDF based, and gets around the fact that if you look at an 8.5 x 11 inch PDF page on a 7 inch device, you aren’t going to be a happy reader even if you have eagle eye vision. Instead, the fixed page  layout implementation means that users can read books with actual pages on both an iPad and an iPad Mini without the requirement to zoom in (or out), and that things like aspect ratios and absolute object positioning on the page is preserved. Apple’s fixed page layout implementation was eventually refined with the IDPF and turned into the Fixed Layout portion of the EPUB specification. There’s also a bit more to it than just fixed layout pages, since other parts of the markup that support fixed layout pages are also designed to support things like media overlays (read to me features of children’s books) and put in some places to associate interactivity (web like interactivity – CSS animations, touch interactions, etc.) with the fixed pages. Stuff that you can’t or wouldn’t want to do in a PDF.

Other IDPF initiatives have been put out there to support other digital publishing cow paths involving Manga, Comics, Advanced Hybrid layouts (a combination of fixed page and reflowable page layouts in the same publication) and multiple renditions of the same book out of one file (why would anyone want to do this? Think accessibility. You could potentially have one book with 2 renditions – one which is accessible to people who need to use alternative reading technologies, whatever they may be).

Note: I am not personally involved with any of the working groups other than Indexing, EDUPUB, and the Open Annotations working groups, and the EDUPUB and OA working groups are just starting up now. Therefore, I am not totally up on the rationale behind decisions made on how the IDPF came about decisions regarding fixed layout, Manga, comics, Advanced Hybrid Layouts, or multiple renditions. Most of the work I do personally involves reflowable titles, and content architecture for educational publishing within the context of EPUB (EDUPUB). The company I work for does a significant amount of fixed layout EPUB conversion work for children’s and cookery titles for a variety of publishers. I am occasionally called upon to clarify how something is done in a fixed layout title by our production team. I am also known to occasionally swear at my ipad/google/kindle/nook/kobo tablet because things don’t always work to my own interpretation of the spec or how things should work, too. This is also part of the job. I like to think of the troubleshooting task of discovering some of the more esoteric solutions akin to completing a level in Tomb Raider, or some such. :)

For those of you who aren’t up on the gory details… current major EPUB implementations include Adobe Digital Editions (which is not the same as Adobe Reader, although it can read PDF files with DRM applied), Apple iBooks, Google Play Books, Kobo Books, and Nook Media (Google, Kobo, and Nook all base their implementations on what is possible with the SDK made available for DRM supplied by Adobe and used by Adobe Digital Editions). If anyone is throwing wrenches at EPUB as a standard for eBooks however, it’s Amazon. But no one should be too surprised about that. Amazon’s Kindle books are similar to EPUBs, and even use some of the same underlying XML concepts, but the overall packaging and end result is very definitely not EPUB. Oh… And Amazon tends to do things with heuristics that people who work with EPUB do with markup (e.g., page-list functionality to support references to physical print pages from a specific version of a title at the same point in a reflowable digital book).

All of that said, what does EPUB have to do with the W3 Print and Page Layout Community Group? Nothing on the print side of things, since by definition, EPUBs are not intended to be printed, or replace printed materials, or even for that matter, replace PDF files (they serve different use cases than PDF files do). On the page layout side of things? Well, that’s where things get a bit more complicated. The W3C Digital Publishing Interest Group (http://www.w3.org/dpub/) is currently charged with collecting use cases around digital publishing in general, which includes digital page layout use cases and lots of those page layout cases come from the history of the printed book. There are at least 3 people in this particular forum (Jirka, Liam, and myself) who are currently involved in the W3C Digital Publishing Interest Group. I’m happy to present any page layout use case this group thinks should be reviewed by the DPUB IG. Here is a list of some of the Latin-based page layout use cases that have been identified to date: http://w3c.github.io/dpub-pagination/  The group is considering other page layout use cases for Asian and Indic languages, too. Some of those use cases are documented elsewhere and were part of other W3C IG/WG efforts. I believe there is consensus in the DPUB IG to not reinvent, or re-document use cases already documented by others, wherever possible.

Please let Liam, Jirka, or myself know any further questions about the W3C Digital Publishing Interest Group. Please let me know any specific questions about the IDPF or EPUB working groups. I may not be able to answer your question directly, but I can certainly carry the question to the people who can.

Thanks,

Jean Kaplansky
Digital Content Solutions Architect, Aptara

Invited Expert Member  l  W3C Digital Publishing Interest Group
Task Force Lead  l  W3C Digital Publishing MathML/STM Interest Group
Member  l  IDPF Indexing and Open Annotations EDUPUB Working Groups,
BISG Content Structure Committee, STC, and SSP

jean.kaplansky@aptaracorp.com<mailto:jean.kaplansky@aptaracorp.com>
+1.518.487.9670
Skype: JeanKaplansky
Twitter: @JeanKaplansky

[cid:64B95D20-559A-4411-8F51-4C19BB04A89A]

From: Arved Sandstrom <asandstrom2@eastlink.ca<mailto:asandstrom2@eastlink.ca>>
Date: Sunday, December 29, 2013 at 2:38 PM
To: "public-ppl@w3.org<mailto:public-ppl@w3.org>" <public-ppl@w3.org<mailto:public-ppl@w3.org>>
Subject: Re: Goal of this group?
Resent-From: <public-ppl@w3.org<mailto:public-ppl@w3.org>>
Resent-Date: Sunday, December 29, 2013 at 2:38 PM

An emerging consensus seems to be that we adhere to the name of the
group and discuss all publishing possibilities. Including your approach.

I sincerely hope we don't develop a new standard - there are too many
now, and there is way too much NIH going on. There is also evidently no
improvement happening - has anyone actually even stepped back and
clinically examined EPUB, for example? Maybe it's just me, but if the
specs and related docs produced by the IPDF are substantially easier to
understand than the XSLT+XSL-FO specs, or the PDF specs + docs for a
typical library that generates PDF, I'll eat my shorts. Stuff like this
(http://www.idpf.org/epub/30/spec/epub30-publications.html) is plain dreck.

Discussing current implementations? Sure, to the extent that we figure
out how they can be improved. As you can tell from my above mini-rant, I
dislike re-inventions of the wheel.

Arved

On 12/29/2013 06:15 AM, Patrick Gundlach wrote:
Hi,

is there any consensus on the goal of this group? Developing a new standard? Discussing current implementations?

I am currently lost on what we are doing here :)

Regards

   Patrick


Patrick Gundlach
speedata
Berlin, Germany
+49 30 57705055
http://speedata.github.io/publisher/