Wiki-to-pdf: Difference between revisions

From titipi
Jump to navigation Jump to search
No edit summary
No edit summary
Line 27: Line 27:
These are just the first examples that come to mind, but the range of experiments and attempts that have been tried is much larger. All these projects have been informed by previous efforts in a certain sense, and working on them is a sort of delayed collaboration. Sometimes one can see pieces of code from a project reappearing in another iteration of such a system later on, CSS styles floating one project to another.
These are just the first examples that come to mind, but the range of experiments and attempts that have been tried is much larger. All these projects have been informed by previous efforts in a certain sense, and working on them is a sort of delayed collaboration. Sometimes one can see pieces of code from a project reappearing in another iteration of such a system later on, CSS styles floating one project to another.
The shared free-software ground of these projects allows for a compatibility between heterogeneous elements, and in each of these transmutations the subjective taste-for-systems of the developers results in adding or removing elements according to their inclinations, modifying workflows and interfaces, each time re-structuring "the system" along a different recipe.
The shared free-software ground of these projects allows for a compatibility between heterogeneous elements, and in each of these transmutations the subjective taste-for-systems of the developers results in adding or removing elements according to their inclinations, modifying workflows and interfaces, each time re-structuring "the system" along a different recipe.
The insistence on some of these systems results in every time being a little bit more comfortable with the frictions and obstacles that each of these software systems would present, especially when their functioning is pushed into territory they were not designed for (such as producing pdf publications!).
In this series of recombinations of a wide range of software, there is some sort of slight variation of the free-software community mode of making software. The insistence on some of these systems results in every time being a little bit more comfortable with the frictions and obstacles that each of them present, especially when their functioning is pushed into territory they were not designed for (such as producing pdf publications!).

Revision as of 17:44, 2 December 2021

how was this made

This publication ( whether you are holding it in its paper format or looking at it on a screen ) has been written and laid out with a wiki-to-pdf system installed at http://titipi.org/wiki-to-pdf. The code and ongoing documentation of the system is hosted at https://gitlab.constantvzw.org/titipi/wiki-to-pdf

wiki-to-pdf

wiki-to-pdf is a contraption for ongoing publication efforts. It combines the collaborative editing possibilities of Mediawiki with the pdf-in-the-browser approach of the pagedjs library to produce paginated, elastic, malleable and re-editable publications for printing and on-line reading.

The system proposes a hybrid publishing toolkit that blurs the boundary between digital and printed publication. It enables different workflows and labour division that divert from the traditional publishing models in which textual and visual material are submitted to a designer that carefully works towards a final layout of the materials. In wiki-to-pdf the work on content and design happens in parallel on the very same system: the CSS files that set the style for the publication are stored in a wiki page, just like all the texts and images that compose the book content. This allows continuous re-editions - diverse in content and design - of ongoing research. Individual articles can keep being edited even after a publication is released, and they can be included in multiple publications on the same system.

The system is composed of:

  • Mediawiki, that allows collaborative text writing and editing, using a simple and accessible markup and holding a history of all the different versions of a text.
  • Pagedjs, a Javascript library that expands the possibilities of web-browser CSS styles to include pagination and printing tasks, allowing to act on non-screen issues such as page numbers, crop marks, sheet sizes.
  • Flask, a framework to make web-pages with python, that can join together in one system the output of mediawiki and the processing made by pagedjs.

'Unfolding:' continuum

wiki-to-pdf is just the latest iteration of a continuity of diverse efforts to patch together collaborative writing practices with hybrid approaches to design... Each of the components of this system has been seen in action before, in one of the different projects brought about by a network of inter-dependent groups of people, tools and situations. To give an idea of this continuum, here are a few related projects that have been fundamental to the development of wiki-to-pdf:

  • Open Source Publishing's html-to-print efforts, starting in 2014 and going through a wide range of situations, from workshops with design students to large-scale publishing efforts such as the Medor magazine. A starting point to design printed matter by the simple use of CSS @print styles, using etherpad to work collaboratively on files;
  • Mondotheque, a wiki-based publication made between 2014 and 2016, for which André Castro and Alexia de Visscher developed a system based on Semantic Mediawiki and weasyprint to produce a printable pdf from a wiki system;
  • Diversions, for which Gijs de Heij and Sarah Magnan came up with a way to Unfold a set of mediawiki pages into HTML files, to which pagedjs could be added to allow more precise work on pagination;
  • Volumetric Regimes book, in which Manetta Berends brought in Flask to combine together all these elements in yet another setup.

Just Free-software?

These are just the first examples that come to mind, but the range of experiments and attempts that have been tried is much larger. All these projects have been informed by previous efforts in a certain sense, and working on them is a sort of delayed collaboration. Sometimes one can see pieces of code from a project reappearing in another iteration of such a system later on, CSS styles floating one project to another. The shared free-software ground of these projects allows for a compatibility between heterogeneous elements, and in each of these transmutations the subjective taste-for-systems of the developers results in adding or removing elements according to their inclinations, modifying workflows and interfaces, each time re-structuring "the system" along a different recipe. In this series of recombinations of a wide range of software, there is some sort of slight variation of the free-software community mode of making software. The insistence on some of these systems results in every time being a little bit more comfortable with the frictions and obstacles that each of them present, especially when their functioning is pushed into territory they were not designed for (such as producing pdf publications!).