% ----------- % _/00100.png % FLOIN: Today I want to talk about a project that I've been working on lately. % ----------- % _/00150.png % _/00206.png % FLOIN: % It's a book % to explore ways % how to make a book. 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. % ----------- % _/00250.png % _/00252.png % _/00254.png % _/00256.png % _/00258.png % _/00262.png % _/00264.png % _/00266.png % _/00268.png % _/00270.png % _/00280.png % _/00284.png % _/00286.png % _/00290.png % _/00300.png % _/00302.png % _/00312.png % _/00318.png % _/00320.png % _/00324.png % _/00326.png % _/00338.png % _/00342.png % _/00350.png % _/00352.png % FLOIN: Unfortunately it is not completely finished right now. These are images from the first proof. % ----------- % _/00390.png % FLOIN: 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. % ----------- % _/00400.png % FLOIN: 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. % ----------- % _/00410.png % _/00412.png % FLOIN: **BUT**: It should be a little bit different to read and write. (_Still finding out what this means exactly_) % ----------- % _/00415.png % FLOIN: **AND**: It should work for print. % ----------- % _/00420.png % FLOIN: About 2 years ago I wrote a little `etherpad2pdf` utility. % ----------- % _/00450.png % _/00454.png % FLOIN: Basically a more or less standard `pandoc` procedure. % ----------- % _/00458.png % FLOIN: _to not forget this completely as I will mention more often:_ [PANDOC IS A HASKELL LIBRARY FOR CONVERTING FROM ONE MARKUP FORMAT TO ANOTHER, AND A COMMAND-LINE TOOL THAT USES THIS LIBRARY.](http://freeze.sh/man/pandoc) % ----------- % _/00459.png % FLOIN: It became clear that this was going into the right direction. % ----------- % _/00460.png % FLOIN: Direction means: - a lightweight markup language that is easy to read and edit in its raw form - this simple markup will be translated in the next step into a more powerful and complex markup language (as LaTeX) - this more complex markup should be a widespread standard to have access and support for a bigger range of tools. **BUT**: I had the ambition for a little more complexity than what seemed possible with standard markdown. % ----------- % _/00500.png % FLOIN: 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: - to describe something - to remember something - to disable parts without deleting % ----------- % _/00595.png % _/00605.png % FLOIN: Unfortunately standard markdown has no comments... % ----------- % _/00700.png % FLOIN: ...so I decided to add the possibility to have comments just as some plugged-on functionality. % ----------- % _/00705.png % FLOIN: This meant: instead of processing the markdown source directly... % ----------- % _/00715.png % FLOIN: ...all lines starting with a `%` sign have to be removed first. % ----------- % _/00720.png % FLOIN: 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. % ----------- % _/00760.png % FLOIN: 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. > [*](https://en.wikipedia.org/wiki/Markup_language) % ----------- % _/00765.png % FLOIN: **or shorter**: instructions describing the form of the content are written along the content as comments. % ----------- % _/00770.png % _/00775.png % FLOIN: 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?_ % ----------- % _/00800.png % FLOIN: 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. % ----------- % _/00850.png % FLOIN: % IMPORTANT: the vocabulary is not final, % the dictionary is never finished. % ----------- % _/00952.png % FLOIN: 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. % ----------- % _/00870.png % _/00980.png % _/00975.png % FLOIN: 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. % ----------- % _/01000.png % _/01005.png % _/01010.png % _/01012.png % _/01016.png % _/01021.png % FLOIN: 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. % ----------- % _/01025.png % FLOIN: Different dictionaries allow different translations. In the beginning the dictionaries were intended to extend and change the vocabulary on-the-fly... % ----------- % _/01026.png % FLOIN: ...but they proofed quite practical to support different output formats. % ----------- % _/01028.png % _/01030.png % FLOIN: 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. % ----------- % _/01050.png % FLOIN: Other instructions were created with a specific output in mind. A very targeted behaviour for example is everything related to pages. % ----------- % _/01100.png % FLOIN: 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. % ----------- % _/01110.png % FLOIN: % _/01120.png 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. % HTMLIN: