Today I want to talk about a project that I’ve been working on lately.
The book collects documentation, ideas, software, graphic design and experiments made with free software between 2008 and 2016. This collection is complemented by inspirational writings on different aspects of free culture generously made available by their authors under copyleft licenses.
Unfortunately it is not completely finished right now. These are images from the first proof.
The setup for this project is connected to an ongoing attempt, which is to find a personal approach to do layout in the sense of developing a practise that may include questioning the current status quo from and within digital publishing.
There were some references (or better preferences) I had in mind when starting this. I was imagining something not too different from HTML. HTML has been for me the first exposure to the possibilities to write code to create visual form. Something I’ve been excited about since then.
BUT: It should be a little bit different to read and write. (Still finding out what this means exactly)
AND: It should work for print.
About 2 years ago I wrote a little etherpad2pdf utility.
Basically a more or less standard pandoc procedure.
to not forget this completely as I will mention more often:
It became clear that this was going into the right direction.
Direction means:
BUT: I had the ambition for a little more complexity than what seemed possible with standard markdown.
The first thing I was really missing when using markdown was the possibility to have comments. Comments are more or less standard for most types of source code. This means you may have some kind of information written within the text which is not part of the actual output. Normally I’d use comments:
Unfortunately standard markdown has no comments…
…so I decided to add the possibility to have comments just as some plugged-on functionality.
This meant: instead of processing the markdown source directly…
…all lines starting with a % sign have to be removed first.
This hack also gave me a first idea about how things might work. Motivated by the simplicity of this comment option, I decided to pick up an original idea of markup.
As described on wikipedia:
The term markup is derived from the traditional publishing practice of “marking up” a manuscript, which involves adding handwritten annotations in the form of conventional symbolic printer’s instructions in the margins and text of a paper manuscript or printed proof. For centuries, this task was done primarily by skilled typographers known as “markup men” or “copy markers” who marked up text to indicate what typeface, style, and size should be applied to each part, and then passed the manuscript to others for typesetting by hand. *
or shorter: instructions describing the form of the content are written along the content as comments.
As I was not planning to pass the manuscript to others for typesetting by hand I had to deal with the question:
How will the instructions be understood and handled?
The basic translation from markdown to LaTeX is handled by pandoc. The translation of the instructions needs to be done separately. I decided to handle this by creating a dictionary, where 'whoever is in charge' could look up what should be done.
The vocabulary may be extended by adding new instructions to the dictionary just as needed. Instructions that don’t exist in the dictionary will be ignored.
Most instructions were not developed in advance, but written as they were needed. Some of these instructions made more sense and where used quite often. Others were too specific or unflexible and just disapeared.
This is a list of instructions/functions made until today. Some of them have telling names, that’s the more ideal case. Some of them are more cryptic.
Different dictionaries allow different translations. In the beginning the dictionaries were intended to extend and change the vocabulary on-the-fly…
…but they proofed quite practical to support different output formats.
Different dictionaries define instructions according to the requirements of different output formats. Some instructions should produce a similar effect, although there may happen quite different things in the background.
Other instructions were created with a specific output in mind. A very targeted behaviour for example is everything related to pages.
E.g. the % CLEARTORIGHT instruction pushes the content to the next right page when making a book. But there are no left and right pages in HTML.
When defining the dictionary for the HTML output % CLEARTORIGHT could be either ignored or I can think about the wanted effect of % CLEARTORIGHT and try to find an equivalent e.g. insert vertical space.
AND AGAIN: the dictionary may changed or extended while writing. There is no definitive vocabulary, there is no definitive meaning.
WHAT DO WE HAVE?
Shared source code means that sources may be and are shared for different output formats, in parts but not necessarily as a whole.
A core functionality and prerequisite for the ‘shared source’ approach is the % INCLUDE instruction, which, as it says, allows to include parts of source files, based on line numbers (btw: this is far from new). This allows to store a resource once, yet distributing it for reuse in multiple documents.
To include by line numbers is actually a big potential problem, because it presumes that the source does not change. This is not so nice (and close to impossible to ensure) when working within collaborative settings.
But there is something like an happy accident, at least something that was not planned from the beginning, but seems more and more crucial to make the whole thing work. (+ it makes it much more interesting)
Since using mostly remote sources from etherpad and git …
… it really makes no difference if I refer to a file or to a specific version of a file.
This can be mixed. There can be material which is always at its latest state, with the advantage and disadvantage that it can change. And there can be material as it was at a specific moment in time. To make it even more complex: versions in time may refer to versions in time. This works basically for anything in a git repository.
What you can see here is the current source for the book.
Distributed across the network …
…frozen in time.
From making a bookmaking workflow…
…I moved more and more towards imagining a source format…
…which is in a way disconnected from how it will exactly be processed.
To round this up I want to show 2 practises that developed along the imagined .mdsh source format.
Number one is the use of the Libre Office as a WYSIWYG interface to create and edit the source files. While the idea was primarily to not force the editors into my workflow, it also easified versioning and inclusion within the rest of the setup. Libre Office became one more player within the workflow. It was added as an interface, but not meant to replace anything.
The second idea is inspired by discussions about the dominance of plain text culture. It’s a interface based on hotglue made for the very specific task to sort and select posters from huge collections. While it is a visual approach, it is not WYSIWYG. Plain text is generated according to relations created visually.
Within both approaches plain text still plays a central role, but not so much for editing but as an intermediary format. And that’s where I’m coming back to the title of this talk and I will try to add some explanation. Instead of searching or even programming the one killer application…
…my biggest interest at the moment is to create and move through layers of different complexities.
And that’s a thing I’ve learned while using GNU’s Bourne-Again-SHell.
