Fidus Writer has been without good PDF output support for several weeks after a rather dramatic showdown among the big players in the the world of browsers. Luckily we were able to fix this issue with a solution that is also compatible with Firefox. Complete Firefox support is now closer than ever!
Although most texts are written on computers in 2014, there are still two very different worlds of tools for publishing: One for printed material and another for things that will be displayed in digital form — in ebooks or on the web. The tools that are good for one, are usually not good for the other. For digital content, it HTML is the format to follow. While for printed material it can either be LaTeX or one of the Adobe desktop publishing tool formats.
I was therefore quite excited when during one year 2012-13, the Czech NGO Sourcefabric asked me to created a system to use HTML content in a print environment for their book authoring software Booktype. I was to get a chance to try to combine the two world and make texts prepared for the web be usable within the print world! The result of this was BookJS: A Javascript library that would format a website so that it would look like a book. I spent a year adding a large number of advanced features — everything from footnotes over margin notes to top floats.
The rise and fall of CSS Regions
What really helped me at my task was the fact that Adobe was just working on converting its tools to be web based and as part of that introduced a technology known as CSS Regions that would help content flow from page to page. They had a team working on adding support for this to Safari and Chrome, which at the time were still working on the same codebase. For many months I had quite a lot of exchange with their team and they helped me along wherever they could.
However, building something on an experimental technology is never a good idea. With time it turned out that David Baron, the gatekeeper of technologies entering Firefox, as well as Håkon Wium Lie, CTO of Opera and chairman of a company selling a product that lets users convert HTML pages into PDFs, were strongly opposed to CSS Regions. In the end, also the Chrome team decided that CSS Regions were not compatible with their 2014 goal of getting Chrome to be the fastest browser on mobile phones.
From Booktype to Fidus Writer
Fidus Writer does not have the same goal as Booktype. Booktype is a general book printing platform, whereas Fidus Writer is specialized for academic writing of both articles and entire books or compilations. Nevertheless, we initially considered using Booktype as a base and add the academic features. Unfortunately it turned out that Booktype has a number of serious structural problems due to a changing technological landscape and unfortunate management decisions in the past and will have to be rewritten entirely at some point of time. We therefore decided to write Fidus Writer from the ground up.
The one component we could use as well was BookJS (or so we thought). Whereas Booktype uses BookJS to create PDFs on the server, Fidus Writer would use BookJS within the editor itself so that the user would write directly on a page, just like Google Docs. It looked nice, but it would only work in Chrome and Safari — until Chrome removed its support for CSS Regions.
Beyond CSS Regions
A few weeks ago I finally found some time to try to replace BookJS. And the result looks astonishingly good! A new Javascript program is used to slice up the text and put it on pages to look good when printed. The disadvantage: it only works in final output (one cannot write directly on the page any more). The advantage: It’s working in Safari, Chrome and Firefox and could probably also be adapted to work in Internet Explorer. And it is not using any experimental technologies, so there is much less to worry about.
What that means in practice is that while editing, footnotes are placed to the right of the place where they are inserted. Only when one clicks CTRL+P (or selected “print” from the file menu inside Fidus Writer), the footnotes are moved to the bottom of the page. Maybe this is not quite as cool, but it may actually make it easier to verify footnotes while editing without having to scroll up and down for a while.
A somewhat different print view can be seen when creating a PDF of a book — a table of contents and a front page are added at the start, and the page numbers of chapter starts are moved to the middle. At the top of the pages headings are added, reflecting the current chapter and book section.
Enemies or partners?
Fidus Writer was helped along initially by the existence of BookJS. Now they can use our new solution to put it into Booktype. Yet, we are not officially cooperating. The beauty of open source technologies is that it makes it possible to both compete and cooperate simultaneously, whenever it makes sense. Even if we should not be able to make it with Fidus Writer, Booktype or others may decide to base the rewrite of their software on our Fidus Writer code. The developer part of me is glad that this minimizes the chance of having spent a lot of time on writing code that will not be used later on.
What now?
Fidus Writer has been moving along nicely. We have seen a lot of interest and support from the community. Unfortunately there is one very vocal part of the community which seems to think we are either so rich that we don’t need to earn any money or that surely we are financed through some government program and are therefore responsible for fixing all the bugs and adding all the features they request.
In the long run, efforts like Fidus Writer can only survive if there is funding available for this to exist. If the European Union is worried about the Google Docs documents of European users being spied upon and they want an alternative one can install on one’s own server or if university publishers are serious about needing a web-based tool for publishing academic texts, it is not enough for them to wait for us to create those features for free. The good part is: There is only four of us, so several continents with hundreds of millions of inhabitants should seem to be able to find the financing to make us be able to continue.
One thing always missing from the web-based solutions is raw typographic quality; the sort you see in well-designed TeX implementations. Well-produced books rely on those details.
Is that a necessary trade-off, or possible to address that at some point?
I think it is a necessary trade-off. Browser makers are keen on making their rendering engines work well on small and mobile devices. They are not made for PDF creation. The Chrome team just removed CSS Regions precisely for that reason, and they would have not have minded removing multi-column support as well. We are using some loopholes to still make nice page rendering possible and the result looks a lot better than using for example Ms Word to design a book. But it will never reach the sophistication of Latex which can take minutes or even half an hour to compile a long document. Lucky for you, we have included a Latex export filter and because it is a semantic editor, there should not be any loss of information in that conversion either. For high end production, that’s what we would recommend. For 99.9% of books that is much more than what is needed.