 This is a project that I've been working on lately. In a way it's a book to explore ways how to make a book. And this book collects documentation and ideas and software and graphic design and experiments made with free software between 2008 and 2016. So here you see some images from what has been printed. And along this material there are inspirational writings on different aspects of digital culture which were generally made available by the authors under copy left licenses and so I could include them in the book so far for the images. Unfortunately it is not completely finished right now so the book is currently called How I Learned to Stop and Love the Draft. Setup for this project is connected to an ongoing attempt which is to find a personal approach to layout. The setup for this project is connected to an ongoing attempt which is to find a personal approach to do layout. This in the sense of developing a practice that also may include the questioning of the current status quo from and within digital publishing. There are some references or I'd better call them preferences I had in mind when starting this. One of them is definitely HTML which warps for me like the first exposure to the possibilities to write code to create visual form. Something I've been excited about since then actually and has been some years. But I wanted something that's a little bit different to read and write where I'm still finding out what this means exactly. And it should work for print. About two years ago I wrote a little Etherpad to be the F-cutility for a workshop of the Linz with Davos which was basically a more or less standard Pondock procedure and to not completely skip this also I will not go deep into technical details from the Pondock 1 page. Pondock is a Haskell library for converting from one markup format to another and a comment line tool that uses this library. Okay, then back in my presentation. It became clear that this combination and use of Pondock was going for me in general in the right direction. This means a lightweight markup language that is easy to read and edit in its raw form. And the next day this markup will be translated to a more complex markup languages as for example Leitech. And for the second markup language there should be a wide range of tools and therefore it was like a prerequisite that it's a widespread and too exotic to second markup language. But I had the ambition for a little more complexity than what seemed possible with standard markdown. One thing, for example, I was really missing when using markdown was the possibility to have comments. Comments are more or less standard for all kinds of source code except markdown. This means you may have some kind of information written within the text which is not part of the actual output. Normally I use comments to describe something or to remember something or to disable parts without deleting them. Unfortunately markdown has no standard comments as far as I know so I decided to add this possibility to have comments just as some plucked on functionality. This meant instead of processing the markdown source directly in my case sending to Pondock all lines starting with a presented sign which I chose as a comment character have to be removed first. So it's actually just adding one line of code in this whole setup. This little hack also gave me a first idea about how things might work. Motivated by the simplicity of the comment option I had the idea to pick up another original idea of markup which is described on Wikipedia as 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 printers 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 pass the manuscript to others for typesetting their hand. This is an example of such a markup printed proof and so if you would like to describe it shorter it would be instruction describing the form of the content are written along the content as comments and so my idea is directly derived from this as I wasn't planning to pass the manuscript to others for typesetting my hand I had to deal with the question how will this additional instruction be understood and handled. Then a rough translation of what is happening the basic translation from markdown to latech is provided by pandog the translation of the instruction need to be handled separately I decided to do this by creating a dictionary where you could look up the instructions important, the vocabulary is not final the dictionary is never finished it 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 right when they were needed this is an example from the conversations book last year and some of these instructions made more sense and were used quite often others were too specific or unflexible and just disappeared after a while so that's what produces the output we had in the audio transcription just to note what was happening in the background and we thought it would be nice to actually include this and then needed to find a typographic solution how to do this and that's what the meanwhile instruction produced some more examples for example the graphic comment was quite needed to include images within the text this example is from another book where we are at a need opportunity to include page spreads so images that take over two pages here you can see it's one, two, three so the double page spread is one before clear to write something I will come back later and include and just references a different source this is a list of instructions made until today some with more telling name, that's the ideal case some of them more cryptic okay, I try to sum it up shortly different dictionaries allow different translation in the beginning the dictionaries were intended to extend and change the vocabulary on the fly but it proved quite practical to support different output formats different dictionaries define instructions according to the requirements of the output format some instructions should produce a similar effect although they may happen different things in the background for example we have one is the thing that's described in the dictionary for HTML when the graphic instruction appears and the other one is for PDF output other instructions were created with quite specific output in mind a very targeted behavior for example is everything related to pages because for example with the clear to write instruction there are no and left right pages in HTML when defining the dictionary for HTML output the clear to write instruction which pushes the content to the next right page when making a book could be either ignored or I can think about the wanted effect of clear to write and try to find an equivalent for example insert vertical space and again dictionary may be changed extended while writing so it could be either vertical space or something else that is more better in this moment so shared source code translated according to different dictionaries leading to different output shared sort code means that sources can and are shared for different output in parts but not necessarily as a whole functionality prerequisite for the shared source approach is to include instruction wish as it says allows to include parts of a source file local and remote based on line numbers this allows to store a resource once yet distributing it for use in multiple documents which is quite an old idea for hypertext for example but has been or is missing in a lot of environments today problems I will hurry up with 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 with in collaborative settings but there is something like a happy accident at least something that was not planned from the beginning but seems more and more crucial to make the whole setup work since using mostly remote sources from Etherpad and Git it really makes no difference if I refer to a file or to a file as it was in a specific moment and this can be mixed there should be like a slide of all the complicated connections with in referencing to versions in time and the latest state has not yet been made so this is the source for the images you have seen before it's distributed across the network and frozen in time to this references to versions from making a book making workflow I came in more and more towards imagining a source format which is in a way disconnected from exactly how it will be processed I've written everything as best scripts but there may be better solutions or just for different tastes different solutions I skipped these two examples which were developed one is utility to convert from LibreOffice to my custom markdown format and the one was like a visual approach to select huge collections of posters and derive source code from this so it's an interface based on hot glue made for the very specific task to sort and select posters from a huge collection while it is a visual approach it is not with the wig from the visual selection source code is generated which is defined by the relations created visually within both approaches plain text still plays a central role but it's not so much for editing as an intermediate format how much time? one minute? it can slow down that's where I'm coming back to my title 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 the possibility to move through and create layers of different complexities and that's a thing I've learned while using Knus, Bornig and Schell