(Current) Fixed Layout eBooks Considered Harmful

UPDATE 2016-05-21

On the same theme, please read this post by Johan Van Der Knijff, Researcher at the National Library of the Netherlands and the Issues and workarounds section (page 15) of this PDF file from the Accessible Book Consortium.

Original Post

This post will probably result highly unpleasant for many readers. Feel free to disagree, but please read it with an open mind.

Fixed Layout eBooks vs Print Replica Formats

A question I often got from publishers (and it appears I am not alone) is:

What are the advantages of a FXL eBook over the corresponding PDF?

From a commercial point of view, very few important stores sell PDF files: either they force you to upload FXL files, or they let you upload PDFs and "convert" them for you. Of course, this is not a satisfactory answer from the technical point of view.

Someone says the main difference is the ability to use embedded audio, video and scripting — but this is only partially true, as the PDF format has allowed those functions for years (although with the well known standardization/support problems due to its "abusive" father — does it sound familiar?).

The really interesting answer here is that (EPUB) FXL, being built with Web technologies (HTML, CSS, JavaScript), allows the author/publisher to semantically tag the contents, which in turn allows the user to personalize the "reading" experience according to her needs.

That is true, in theory.

In fact, almost all the FXL files currently on the market are not really fulfilling that vision. Even worse, they are limiting the user freedom, rather than augmenting it. Sometimes they are even inferior to their PDF version.

Who/what is to blame? A big share goes to the reading systems, which are not really enabling those "semantic" manipulations, as I have said/written a tedious number of times.

But, in the FXL case, another big portion of responsibility goes to the authoring decisions and processes.

(Note: in what follows I will identify "FXL" and "EPUB 3 FXL", since all the "clones", like Kindle KF8, are similar from the technical point of view.)

Two Problems with Current FXL eBooks

Problem #1: people use FXL even when they should not

An example? Consider cookbooks: sure, many have floating boxes and large images, but nothing impossible to achieve in reflow mode with a proper design.

Note that choosing flowing text instead of FXL would automatically bring a whole batch of desirable features: font customizable by the reader, perfect screen reader support (which is nice if you are cooking using the cookbook!), searchability, "semantically" described information allowing the user to select the recipe depending on the ingredients you have in your kitchen now, etc., just to name a few.

I explain this aberration with three main causes:

1. print publishing tools (i.e., Adobe InDesign) can "export" a FXL eBook that looks (almost) identical to the print/PDF version, at no additional cost and with no additional labor. Similarly, there are several services that can automatically "convert" a PDF file into a FXL file, for cheap (or even for free);
2. the "enhanced eBook" label is way more marketing-friendly than "properly designed (reflowable) eBook", and it seems quite effective at convincing people to pay more for the same "amount" of contents;
3. contrary to the common belief, reliably displaying FXL is easier than properly displaying reflowable contents. Combine this with the "earning more dollars per asset" of the previous point, and you will understand why certain features, like EPUB 3 Media Overlays or JavaScript, are better supported by reading systems in FXL mode than in reflowable mode. In turn, many publishers opt for FXL just because otherwise they could not "add" certain functions to their books.

A digression on the third point. I hear it a lot and it is very close to my heart, because my company produces Audio-eBooks, that are, EPUB 3 eBooks where text and audio are synchronized using Media Overlays. Since we mainly do long text works, our Audio-eBooks are reflowable, feature which sets us apart from all other "audio + text + sync" EPUB eBooks out there, which are done in FXL.

One major problem we faced so far has been the lack of good support for EPUB 3 Media Overlays (MO) in reflowable eBooks in the reading systems, especially mobile apps. For example, iBooks does not support MO in reflowable EPUB 3 files (I wrote a JS workaround, although more as a proof-of-concept than an actual viable commercial tool). A lot of other apps have some support for MO + reflow, but they either struggle when loading very large eBooks, or they do not offer the proper GUI controls to the user (tap-to-play, track slider, playlist, etc.).

Eventually, we had to develop our own app to "support" our Audio-eBooks, despite them being 100% standard EPUB 3.

We could have mitigated the problem by producing our Audio-eBooks in FXL. From a purely commercial point of view, just being able to have them "working properly" in iBooks could have been a big plus. However that strategy would have meant producing a much inferior product, a compromise that, as a professional caring about the satisfaction of my customers more than my pockets, I have never accepted and I will never do.

Problem #2: the content of current FXL eBooks is (almost always) junk

The XHTML code inside almost all FXL eBooks currently out there is a soup of absolute positioned elements that look like this (click to enlarge):

(Some tools have the decency of using a code prettifier and/or CSS rules instead of inline <style>s, which makes the code readable (debuggable?) by the human eye, but prettifiers do not solve the root problem: the code remains a soup of absolute positioned elements.)

That is the kind of code output by InDesign, PDF-to-FXL services, and friends. Sure, it looks fine, but I would be ashamed of calling that junk "an enhanced eBook".

Indeed, it might even be inferior to the PDF from which it has been generated. For example, look at the words that are split into two different elements since they occur at the line break (e.g., "frigo-" and "rifero", instead of "frigorifero"), which makes processing the text harder (impossible?). Once I had the <irony>pleasure</irony> of examining a FXL "converted" from a PDF file: the hyphenated words were searchable in the PDF, but not in the FXL. Not to mention that PDF readers are available on almost anything with a CPU, while FXL…

If this is the kind of code a vast majority of people is happy to put in their eBooks, I find quite difficult to agree with those arguing that EPUB FXL files are more powerful than PDFs because they allow semantic content manipulation and adaptability to the needs of the user.

To me, most FXL eBooks look like the first commercial (reflow) EPUBs, full of OCR errors and without linked TOC and metadata.

And note that I have not even touched themes like cross-platform compatibility (e.g., iBooks vs Kobo vs Gitden, etc.) and the toxic role of proprietary clones/platforms (e.g., iBA format and its widget-zadry).

Open Problems and Future Work

Let me clarify that I do not consider FXL harmful per se. Of course there are works (e.g., children books or comics) where absolute positioning seems natural. In this post I just wanted to note that

FXL is harmful as it is done now

Specifications like Multiple Renditions might favor a more conscious use of FXL, and discourage the use of tools which do not generate decent code. To be honest, I do not hold my breath for that.

As I said a considerable number of times, to get better eBooks we also need better reading systems, and again I am not expecting breakthroughs soon.

How do you feel after reading this post? (BTW, thank you for staying with me till the end!)

What do you think about FXL?

You can reach me via email or on Twitter (@acutebit).