ConTeXt and the ballistics of design

In September 2013 writer, developer, freestyle rapper and poet John Haltiwanger joined the ConTeXt user meeting in Brejlov (Czech Republic) ¹ to present his ideas on Subtext, 'A Proposed Processual Grammar for a Multi-Output Pre-Format'. The interview started as a way to record John's impressions fresh from the meeting, but moved into discussing the future of layout in terms of ballistics.

It was in Brejlov, which apparently might not even be a town or city. It might specifically be a hotel. But it has its own ... it's considered a location, I guess. But arriving was already kind of a trick, because I was under the impression there was a train station or something. So I was asking around: Where is Brejlov? What train do I take to Brejlov? But nobody had any clue, that this was even something that existed. So that was tricky. But it was really a beautiful venue. How I ended up at the conference specifically? That's a good question. I'm not an incredibly active member on the ConTeXt mailing list, but I pop up every now and again and just kind of express a few things that I have going on. So initially I mentioned my thesis, back in January or maybe March, back when it was really unformulated. Maybe it was even in 2009. But I got really good responses from Hans. ² Originally, when I first got to the Netherlands in 2009 in August, the next weekend was the third annual ConTeXt meeting. I had barely used the software at that point, but I had this sort of impulse to go. Well anyway, I did not have the money for it at that time. So the fact that there was another one coming round, was like: Ok, that sounds good. But there was something ... we got into a conversation on the mailing list. Somebody, a non-native English speaker was asking about pronouns and gendered pronouns and the proper way of 'pronouning' things. In English we don't have a suitable gender neutral pronoun. So he asked the questions and some guy responded: The proper way to do it, is to use he. It's an invented problem. This whole question is an invented question and there is no such thing as a need for considering any other options besides this. ³ So I wrote back and said: That's not up to you to decide, because if somebody has a problem, than there is a problem. So I kind of naively suggested that we could make a Unicode character, that can stand in, like a typographical element, that does not necessarily have a pronounciation yet. So something that, when you are reading it, you could either say he or she or they and it would be sort of [emergent|dialogic|personalized]. Like delayed political correctness or delayed embraciveness. But, little did I know, that Unicode was not the answer.

Well, Arthur actually wrote back ⁴, and he knows a lot about Unicode and he said: With Unicode you have to prove that it's in use already. In my sense, Unicode was a playground where I could just map whatever values I wanted to be whatever glyph I wanted. Somewhere, in some corner of unused namespace or something. But that's not the way it works. But TeX works like this. So I could always just define a macro that would do this. Hans actually wrote a macro ⁵ that would basically flip a coin at the beginning of your paper. So whenever you wanted to use the gender neutral, you would just use the macro and then it wouldn't be up to you. It's another way of obfuscating, or pushing the responsibility away from you as an author. It's like ok, well, on this one it was she, the next it was he, or whatever.

Right. And then I was just like, that's something we should talk about at the meeting. I guess I sent out something about my thesis and Hans or Taco, they know me, they said that it would great for you to do a presentation of this at the meeting. So that's very much how I ended up there.

No. You and Pierre were the only people I knew, that have been using it, besides me, at the time. It was interesting in that way, it was really ... I mean I felt a little bit ... nervous isn't exactly the word, but I sort of didn't know what exactly my positon was meant to be. Because these guys ... it's a users' meeting, right? But the way that tends to work out for Open Source projects is developers talking to developers. So ... my presentation was saturated ... I think, I didn't realise how quickly time goes in presentations, at the time. So I spent like 20 minutes just going through my attack on media theory in the thesis. And there was a guy, falling asleep on the right side of the room, just head back. So, that was entertaining. To be the black sheep. That's always a fun position. It was entertaining for me, to meet these people and to be at the same time sort of an outsider. Not a really well known user contrasted with other people, who are more like cornerstones of the community. They were meeting everybody in person for the first time. And somehow I could connect. So now, a month and a half later we're starting this ConTeXt group, an international ConTeXt users' group and I'm on the board, I'm editing the journal. So it's like, it ...

To a certain extent the NTG, which is the Netherlands TeX Group, had sort of been consumed from the inside by the heavyness of ConTeXt, specifically in the Netherlands. The discussion started to shift to be more ConTeXt. Now the journal, the MAPS journal, there are maybe 8 or 10 articles, two of which are not written by either Hans or Taco, who are the main developers of ConTeXt. And there is zero on anything besides ConTeXt. So the NTG is almost presented as ok, if you like ConTeXt or if you wanna be in a ConTeXt user group, you join the NTG. Apparently the journal used to be quite thick and there are lots of LaTeX users, who are involved. So partially the attempt is sort of ease that situation a little bit.

Yeah, and not in any way like fast or abrupt fashion. We're trying to be very conscious about it. I mean, it's not ConTeXt's fault that LaTeX users are not submitting any articles for the journal. That user group will always have the capacity, those people could step up. The idea is to setup a more international forum, something that has more of the sense of support for ... because the software is getting bigger and right now we're really reliant on this mailing list and if you have your stupid question either Hans, Taco or Wolfgang will shoot something back. And they become reliant on Wolfgang to be able to answer questions, because there are more users coming. Arthur was really concerned, among other people, with the scalability of our approach right now. And how to set up this infrastructure to support the software as it grows bigger. I should forward you this e-mail that I wrote, that is a response to their name choices. They were contemplating becoming a group called 'cows'. Which is clearly an inside joke because they loved to do figure demonstrations with cows. And seeing ConTeXt as I do, as a platform, a serious platform, for the future, something that ... it's almost like it hasn't gotten to its ... I mean it's in such rapid development ... it's so undocumented ... it's so ... like ... it's like rushing water or something. But at some point ... it's gonna fill up the location. Maybe we're still building this platform, but when it's solid and all the pieces are ... everything is being converted to metric, no more inches and miles and stuff. At that point, when we have this platform, it will turn into a loadable Lua library. It won't even be an executable at that point.

It is interesting how quickly you have become part of this community. From being complete outsider not knowing where to go, to now speaking about a communal future.

To begin with, I guess I have to confront my own seemingly boundless propensity for picking obscure projects ... as sort of my ... like the things that I champion. And ... it often boils down to flexibility.

You think that obscurity has anything to do with the future compatibility of ConTeXt?

Well, no. I think the obscurity is something that I don't see this actually lasting for too long in the situation of ConTeXt. As it gets more stable it's basically destined to become more of a standard platform. But this is all tied into to stuff that I'm planning to do with the software. If my generative typesetting platform ... you know ... works and is actually feasible, which is maybe a 80% job.

Yes, although I'm kind of hovering over it or sort of superceeding it as an interface. You have LaTeX, which has been at version 2e since the mid-nineties, LaTeX 3 is sort of this dim point on the horizon. Whereas ConTeXt is changing every week. It's converting the entire structure of this macro package from being written in TeX to being written in Lua. And so there is this transition from what could be best described as an archaic approach to programming, to this shiny new piece of software. I see it as being competitive strictly because it has so much configurability. But that's sort of ... and that's the double edged sword of it, that the configuration is useless without the documentation. Donald Knuth is famous for saying that he realises he would have to write the software and the manual for the software himself. And I remember in our first conversation about the sort of paternalistic culture these typographic projects seem to have. Or at least in the sense of TeX, they seem to sort of coagulate around a central wizard kind of guy.

You think ConTeXt has potential for the future, while TeX and LaTeX belong ... to the past?

I guess I share some of your excitement, but also have doubts about how far the project actually is away from the past. Maybe you can describe how you think it will develop, what will be that future? How you see that?

Right. That's a good way to start untangling all the stuff I was just talking about, when I was sort of putting the cart before the horse. I see it developing in some ways ... the way that it's used today and the way that current, heavy users use it. I think that they will continue to use in it in a similar way. But you already have people who are utilising LuaTeX... and maybe this is an important thing to distinguish between ConTeXt and LuaTeX. Right now they're sort of very tied together. Their development is intrinsic, they drive each other. But to some extent some of the more interesting stuff that is been being done with these tools is ... like ... XML processing. Where you throw XML into Lua code and run LuaTeX kerning operations and line breaking and all this kind of stuff. Things that, to a certain extent, you needed to engage TeX on its own terms in the past. That's why macro packages develop as some sort of sustainable way to handle your workflow. This introduction of LuaTeX I think is sort of ... You can imagine it being loaded as a library just as a way to typeset the documentation for code. It could be like this holy grail of literate programming. Not saying this is the answer, but that at least it will come out as a nice looking .pdf.

Yeah. It takes sort of the essence of TeX. And this is, I guess, the crucial thing about LuaTeX that up until now TeX is both a typesetting engine and a programming language. And not a very good one. So now that TeX can be the engine, the Tschicholdian algorithms, the modernist principles, that, for whatever reason, do look really good, can be utilised and connected to without having to deal with this 32 year old macro programming language. On top of that and part of how directly engaging with that kind of movement foreward is ... not that I am switching over to LuaTeX entirely at this point ... but that this generative typesetting platform that was sort of the foundation of this journal proposal we did. Where you could imagine actual humanity scholars using something that is akin to markdown or a wiki formatting kind of system. And I have a nice little buzzword for that: 'visually semantic markup'. XML, HTML, TeX, ... none of those are visually semantic. Because it's all based around these primitives 'ok, between the angle brackets'. Everything is between angle brackets. You have to look what's inside the angle brackets to know what is happening to what's between the angle brackets. Whereas a visually semantic markup ... OK headers! OK so it's between two hashmarks or it's between two whatever ... The whole design of those preformatting languages, maybe not wiki markup, but at least markdown was that it could be printed as a plaintext document and you could still get a sense of the structure. I think that's a really crucial development. So ... in a web browser, on one half of the browser you have you text input, on the other half you have an real-time rendering of it into HTML. In the meantime, the way that the interface works, the way that the visually semantic markup works, is that it is a mutable interface. It could be tailored to your sense of what it should look like. It can be tailored specifically to different workflows. And because there is such a diversity within typographic workflows, typesetting workflows ... that is akin to the separation of form and content in HTML and CSS, but it's not meant to be ... as problematic as that. I'm not sure if that is a real goal, or if that goal is feasible or not. But it's not meant to be drawing an artificial line, it's just meant to make things easier.

So by pulling apart historically grown elements, it becomes ... possibly modern?

Yes. Part of this idea, the trick ... This software is called 'Subtext' and at this point it's a conceptual project, but that will change pretty soon. Its trick is this idea of separation instead of form and content, it's translation and effect. The parser itself has to be mutable, has to be able to pull in the interface, print like decorations basically from a YAML configuration file or some sort of equivalent. One of this configuration mechanisms that was designed to be human readable and not machine readable. Like, well both, striking that balance. Maybe we can get to that kind of ... talking about agency a little bit. Its trick to really pull that out so that if you want to ... for instance now in markdown if you have quotes it will be translated in ConTeXt into \quotation. In ConTeXt that's a very simple switch to turn it into German quotes. Or I guess that's more like international quotes, everything not English. For the purposes of markdown there is no, like really easy way, to change that part of the interface. So that when I'm writing, when I use the angle brackets as a quote it would turn into a \quotation in the output. Whereas with 'Subtext' you would just go into the interface type like configuration and say: These are converted into a quote basically. And then the effects are listed in other configuration files so that the effects of quotes in HTML can be ...

Yes. Maybe have specific CSS properties for spacing, that kind of stuff. And then in ConTeXt the same sort of ... both the environmental setup as well as the raw 'what is put into the document when it's translated'. This kind of separation ... you know at that point if both those effects are already the way that you want them, then all you have to do is change the interface. And then later on typesetting system, maybe iTeX comes out, you know, Knuth's joke, anyway. ⁶ That kind of separation seems to imply a future proofing that I find very elegant. That you can just add later on the effects that you need for a different system. Or a different version of a system, not that you have to learn 'mark 6', or something like that ...

Back to the future ... I wonder about ConTeXt being bound to a particular practise located with two specific people. Those two are actually the ones that produce the most complete use cases and thereby define the kind of practise that ConTeXt allows. Do you think this is a temporary stage or do you think that by inviting someone like you on the board, as an outsider, that it is a sign of things going to change?

Right. Well, yeah, this is another one of those put-up or shut-up kind of things because for instance at the NTG meeting on Wednesday my presentation was very much a user presentation in a room of developers. Because I basically was saying: Look like this is gonna be a presentation -- most presentation are about what you know -- and this presentation is really about what I don't know ... but what I do know is that there is a lot of room for teaching ConTeXt in a more practical fashion, you could say. So my idea is to basically write this documentation on how to typeset poetry, which gets into a lot of interesting questions, just a lot of interesting things. Like you gonna need to write your own macros just at the start ... to make sure you have not to go in and change every width value at some point. you know, this kind of thing like ... really baby steps. How to make a cover page. These kinds of things are not documented.

Documentation is let's say an interesting challenge for ConTeXt. How do you think the ConTeXt community could enable different kinds of use, beyond the ones that are envisioned right now? I guess you have a plan?

Yeah ... that's a good question. Part of it is just to do stuff, like to get you more involved in the ConTeXt group for instance, because I was talking to Arthur and he hadn't even read the article from V/J10 . I think that kind of stuff is really important. It's like the whole Blender Foundation kind of impulse. We have some developers who are paid to do this and that's kind of rare already in an Open Source/Free Software project. But then to kind of have users pushing the boundaries and hitting limits. It's rare that Hans will encounter some kind of use case that he didn't think of and react in a negative way. Or react in a way like I'm not gonna even entertain that possibility. Part of it is moving beyond this ... even the sort of centralisation as you call it ... how to do that directly ... I see it more as baby steps for me personally at this point. Just getting a tutorial on how to typeset a cd booklet. Just basically what I'm writing. That at the same time, you know, gets you familiar with ConTeXt and TeX in general. Before my presentation I was wondering, I was like: how do you set a variable in TeX. Well, it's a macro programming language so you just make a macro that returns a value. Like that kind of stuff is not initially obvious if you're used to a different paradigm or you know .. So these baby steps of kind of opening the field up a little bit and then using it my own practise of guerilla typesetting and kind of putting it out there. and you know ... And people gonna start being like: oh yeah, beautiful documents are possible or at least better looking documents are possible. And then once we have them at that, like, then how do you we take it to the next level. How do I turn a lyric sheet from something that is sort of static to ... you know ... two pages that are like put directly on the screen next to each other. Like a screen based system where it's animated to the point ... and this is what we actually started to karaoke last night ... so you have an English version and a Spanish version -- for instance in the case of the music that I've been doing. And we can animate. We can have timed transitions so you can have a 'current lyric indicator' move down the page. That kind of use case is not something that Pragma ⁷ is ever going to run into. But as soon as it is done and documented then what's the next thing, what kind of animations are gonna be ... or what kind of ... once that possibility is made real or concrete ... you know, so I kind of see it as a very iterative process at this point. I don't have any kind of grand scheme other than 'Subtext' kind of replacing Microsoft Word as the dominant academic publishing platform, I think. (laughs)

You talked about manuals for things that you would maybe not do in another kind of software ...

Manuals that not just explain 'this is how you do it' but also 'this is the kind of user you could be'.

I'm not sure if instructions for how to produce a cd cover would draw me in, but if it helped me understand how to set a variable, it would.

You were saying that ConTeXt should replace Microsoft Word as the standard typesetting tool for academic publishing. You are thinking about the future for ConTeXt more in the context of academic publishing than in traditional design practise?

Yes. In terms of 'Subtext', I mean the origins of that project, very much ... It's an interesting mix because it's really a hybridity of many different processes. Some, much come directly from this obscure art project 'the abstraction'. So I have stuff like the track changes using Git version control and everything being placed on plaintext as a necessity. That's a holdover from that project as well as the idea of gradiated presence. Like software enabling a more real-time peer review, anonymous peer review system. And even a collaborative platform where you don't know who you're writing with, until the article comes out. Someting like out that. So these interesting tweaks that you can kind of make, those all are holdovers from this very, very much maybe not traditional design practise but certainly like ... twisted artistic project that was based around hacking a hole from signified to siginifier and back again. So ... In terms of its current envisionment and the use case for which we were developing it at the beginning, or I'm developing it, whatever ... I'll say it the royal way, is an academic thing. But I think that ... doesn't have to stop there and ...

At some point at OSP we decided to try ConTeXt because we were stuck with Scribus for page layout as the only option in Free Software. We wanted escape that kind of stiffness of the page, or of the canvas in a way. But ConTeXt was not the dream solution either. For us it had a lot to do, of course, with issues of documentation ... of not understanding, not coming from that kind of automatism of treating it as another programming language. So I think we could have had much more fun if we had understood the culture of the project better. I think the most frustrating experience was to find out how much the model of typesetting is linked to the Tschichold universe, that at the moment you try to break out, the system completely looses all flexibility. And it is almost as if you can hear it freeze. So if we blame half of our troubles with ConTeXt on our inability to actually understand what we could do with ConTeXt, I think there is a lot also in its assumption what a legible text would look like, how it's structured, how it's done. Do you think a modern version of ConTeXt will keep that kind of inflexibility? How can it become more flexible in it's understanding of what a page or a book could be?

That's an interesting question, because I'm not into the development side of LuaTex at all, but I would be surprised if the way that it was being implemented was not significantly more modular than for instance when it was written in Pascal, you know, how that was. Yeah, that's a really interesting question of how swappable is the backend. How much can we go in and kind of ... you know. And it its an inspirational question to me, because now I'm trying to envision a different page. And I'm really curious about that. But I think that ConTeXt itself will likely be pretty stable in its scope ... in that way of being ... sort of ... deterministic in its expectations. But where that leaves us as users ... first I'd be really surprised if the engine itself, if LuaTeX was not being some way written to ... I feel really ignorant about this, I wish I just knew. But, yeah, there must be ... There is no way to translate this into a modern programming language without somehow thinking about this in terms of the design. I guess to certain extent the answer to your question is dependent on the conscientiousness of Taco and the other LuaTex developers for this kind of modularity. But I don't ... you know ... I'm actually feeling very imaginatively lacking in terms of trying to understand what you're award-winning book did not accomplish for you ... Yeah, what's wrong with that?

I think it would be good to talk with Pierre, not Pierre Marchand but Pierre ...

Yeah. We have been talking about 'rivers' as a metaphor for layout ... like were you could have things that are ... let's say fluid and other things that could be placed and force things around it. Layout is often a combination of those two things. And this is what is frustrating in canvas based layout that it is all fixed and you have to make it look like it's fluid. And here it's all fluid and sometimes you want it to be fixed. And at the moment you fix something everything breaks. Then it's up to you. You're on your own.

The experience of working with ConTeXt is that it is very much elastic, but there is very little imagination about what this elasticity could bring.

It's all about creating universally beautiful pages, in a way it is using flexibility to arrive at something that is already fixed.

Right. That's an interesting point. I would be actually suprised ... I know that there is something called ... there is all sorts of weird stuff in ConTeXt that ... it's one of this rabbit holes but I know there is for instance grid layout ... which I think maybe adresses a few of those ... but it's also ... the documentation is ... is like ...

Well, there is a lot more possible than we ever tried, but ... again ... this goes back to the sort of centralist question: If those possibilities are mainly details in the head of the main developers than how will I ever start to fantasize about the book I would want to make with it?

I don't even need access to all the details. Because once I have a sort of sense of what I want to do, I can figure it out. Right now you're sort of in the dark about the endless possibilities ...

Its existence is very opaque in some ways. The way that it's implemented, like everything about it is sort of ... looking at the macros that they wrote, the macros that you invoke ... like ... that takes ... flow control in TeX is like ... I mean you might as well write it in Bash or ... I mean I think Bash would even be more sensible to figuring out what's going on. So, the switch to Lua there is kind of I think a useful step just in being more transparent. To allow you to get into becoming more intimate with the source or the operation of the system ... you know ... without having to go ... I mean I guess ... the TeX Book would still be useful in some ways but that's ... I mean ... to go back and learn TeX when you're just trying to use ConTeXt is sort of ... it's not ... I'm not saying it's, you know ... it's a proper assumption to say oh yeah, don't worry about the rules and the way TeX is organised but you're not writing your documents in ConTeXt the way you would write them if you're using plain TeX. I mean that's just ... it's just not ... It's a different workflow ... it has a completely different set of processes that you need to arrange. So it has a very distinct organisational logic ... that I think that ... yeah ... like being able to go into the source and be like oh OK, like I can see clearly this is ... you know. And then you can write in your own way, you can write back in Lua.

It's kind of strange paradox in the TeX community. At one hand you're sort of supposed to be able to do all of it. But at the same time on every page you're told not to do it, because it's not for you to worry about this.

With ConTeXt there is this strange sense of very much wanting to understand the way the logic works, or ... what the material is, you're dealing with. And at the same time being completely lost in the labyrinth between the old stuff from TeX and LaTeX, the newer stuff from LuaTex, Mark 4, 3, 5, 6 ...

So that was sort of my idea with the cd typesetting project, is not to say, that that is something that is immediately interesting to anybody who is not trying to do that specifically, right? But at the same time if I'm ... if it's broken down into 'How to do a bitmap cover page' (=Lesson 1).
Lesson 2: 'How to start defining you own macros'. And so you know, it's this thing that could be at one point a very ... because the documentation as it stands right now is ... I think it's almost ... fixing that documentation, I'm not sure is even possible. I think that it has to be completely approached differently. I mean, like a real ConTeXt manual, that documents ... you know ... command by command exactly what those things do. I mean our reference manual now just shows you what arguments are available, but doesn't even list the available arguments. It's just like: These are the positions of the arguments. And it's interesting.

What is the difference between your plans for 'Subtext' and a page layout program like Scribus?

You mentioned 'Subtext' coming from a more academic publishing rather than a design background. I think that this belies where I have come into typesetting and my understanding of typography. Because in reality DTP has never kind of drawn me in in that way. The principle differences are really based on this distribution of agency, in my mind. That when you're demanding the software to be 'what you see is what you get' or when you place that metaphor between you and your process. Or you and your engagement, you're gaining the usefulness of that metaphor, which is ... it's almost ... I hope I don't sound offensive ... but it's almost like child's play. It's almost like point, click, place. To me it just seems so redundant or ... time-consuming maybe ... to really deal with it that way. There are advantages to that metaphor. For instance I don't plan on designing covers in ConTeXt. Or even a poster or something like that. Because it doesn't really give affordances for that kind of creativity. I mean you can do generative stuff with the MetaFun package. You can sort of play around with that. But I haven't seen a ConTeXt generated cover that I liked, to be honest.

OK. Principle differences. I'm trying to ... I'm struggling a little bit. I think that's partially because I'm not super comfortable with the layout mechanism and stuff yet. And you have things like \blank in order to move down the page. Because it has this sort of literal sense of a page and movement on a page. Obviously Scribus has a literal idea of a page as well, but because it's WYSIWYG it has that benefit where you don't have to think OK, well, maybe it should be 1.6 ems down or maybe it should be 1.2 ems down. You move it until it looks right. And then you can measure it and you're like ok, I'm gonna use this measurement for the further on in my document. So it's that whole top-down vs. bottom-up approach. It really breaks down into the core organisational logics of those softwares.

I think it's too easy to make the difference based on the fact that there is a metaphorical layer or not. I think there is a metaphorical layer in ConTeXt too ...

And they come at a different moment and they speak a different language. But I think that we can agree that they're both there. So I don't think it's about the one being without and the other being with. Of course there is another sense of placing something in a canvas-based software than in a ... how would you call this?

So I guess it is either 'declarative' or 'sequence' based. You could say generative in a way ... or compiled or ... I don't even know. That's a cool question.

What is the difference really and why would you choose the one or the other? Or what would you gain from one to the other? Because it's clear that posters are not easily made in ConTeXt. And that it's much easier to typeset a book in ConTeXt than it is in Scribus, for example.

So, there's hierarchy. There's direction. There's an assumption about structure being good or bad.

What is exciting in something like this is that placement is relative always. Relative to a page, relative to a chapter, relative to itself, relative to what's next to it. Where in a canvas based software your page is fixed.

This is very different from a system where you make a change, then you compile and then you look at it and then you go back into your code. So where there is a larger distinction between output and action. It's almost gestural ...

It's like two different ways of having a conversation. Larry Wall has this really great metaphor. He talks about 'ballistic design'. So when you're doing code, maybe he's talking more about software design at this point, basically it's a 'ballistic practise' to write code. Ballistics comes from artillery. So you shoot at a thing. If you hit it, you hit it. If you miss it, you change the amount of gun powder, the angle. So code is very much a 'ballistic practise'. I think that filters into this difference in how the conversation works. And this goes back to the agencies where you have to wait for the computer to figure out. To come with its into the conversation. You're putting the code in and then the computer is like ok; this is what the code means and then is this what you wanted? Whereas with the WYSIWYG kind of interface the agency is distributed in a different way. The computer is just like ok, I'm a canvas; I'm just here to hold what you're putting on and I'm not going to change it any way or affect it in any way that you don't tell me to. I mean it's the same way but I ... is it just a matter of the compilation time? In one you're sort of running a experiment, in another you're just sort of painting. If that's a real enough distinction or if that's ... you know ... it's sort of ... I mean I kind of see that it is like this. There is ballistics vs. maybe fencing or something.

I understand that there's lots of childish way of solving this need to make the computer dissapear. Because if you are not wrestling ... you're dancing, you know.

But I think it's interesting to see that ballistics, that the military term of shooting at something, is the kind of metaphor to be used. Which is quite different than a creative process where there is a direct feedback between something placed and the responses you have.

And it's not always about aiming, but also sometimes about trying and about kind of subtle movements that spark off something else. Which is very immediate. And needs an immediate connection to ... let's say ... what you do and what you get. It would be interesting to think about ways to talking about 'what you see is what you get' away from this assumption that is always about those poor users that are not able do it in code.

Because I think there is essential stuff that you can not do in a tool like this -- that you can do in canvas-based tools. And so ... I think it's really a pity when ... yeah ... It's often overlooked and very strange to see. There is not a lot of good thinking about that kind of interaction. Like literal interaction. Which is also about agency with the painter. With the one that makes the movement. Where here the agency is very much in this confrontational relation between me aiming and ...

So yeah, when we put it in those metaphors. I'm on the side with the painting, because ...

But I mean it's difficult to do a book while wrestling. And I think that's why a poster is very difficult to do in this sort of aiming sense. I mean it's fun to do but it's a strange kind of posters you get.

I wondered to what extent, if it were updated in real time, all the changes you're making in the code, if compilation was instantaneous, how that would affect the experience. I guess it would still have this ballistic aspect, because what you are doing is ... and that's really the side of the metaphor ... or a metaphorical difference between the two. One is like a translation. The metaphor of ok this code means this effect ... That's very different from picking a brush and choosing the width of the stroke. It's like when you initialise a brush in code, set the brush width and then move it in a circle with a radius of x. It's different than taking the brush in Scribus or in whatever WYSIWYG tool you are gonna use. There is something intrinsically different about a translation from primitives to visual effect than this kind of metaphorical translation of an interaction between a human and a canvas ... kind of put into software terms.

But there is a translation from me, the human, to the machine, to my human eye again, which is hard to grasp. Without wanting it to be made invisible somehow. Or to assume that it is not there. This would be my dream tool that would allow you to sense that kind of translation without losing the ... canvasness of the canvas. Because it's frustrating that the canvas has to not speak of itself to be able to work. That's a very sad future for the canvas, I think.

But when it speaks of itself it's usually seen as buggy or it doesn't work. So that's also not fair to the canvas. But there is something in drawing digitally, which is such a weird thing to do actually, and this is interesting in this sort of cyborgs we're becoming, which is all about forgetting about the machine and not feeling what you do. And it's completely a different world in a way than the ballistics of ConTeXt, LaTeX or whatever typesetting platform.

Yeah, that's true. And it's something that my students were forced to confront and it was really interesting because that supposed invisibility or almost necessitated invisibility of the software. As soon as they're in Inkscape instead of Illustrator they go crazy. Because it's like they know what they want to do, but it's a different mechanism. It's the same underlying process which itself is only just meant to give you a digital version of what you could easily do on a piece of paper. Provided you have the right paints and stuff. So perhaps it's like the difference between moving from a brush to an air brush. It's a different ... interface. It's a different engagement. There is a different thing between the human and the canvas. You engage in this creative process where it's like ok, we'll now have an airbrush and I can play around to see what the capacities are without being stuck in well I can't get it to do my fine lines the same way I can when I have my brush. It's like when you switch the software out from between the person and the canvas. It's that sort of invisibility of the interface and it's intense for people. They actually react quite negatively. They're not gonna bother to learn this other software because in the end they're doing less. The reappearance of this software ... of software between them and their ideas is kinda too much. Whereas people who don't have any preconceived notions are following the tutorials and they're learning and they're like ok, I'm gonna continue to play with this. Because this software is starting to become more invisible.

But on a sort of theoretical level the necessitated invisibility, as you said it nicely, is something I would always speak against. Because that means you hide something that's there. Which seems a stupid thing to do, especially when you want to find a kind of more flexible relation to your tools. I want to find a better word for describing that sort of quick feedback. Because if it's too much in the way, then the process stops. The drawing can not be made if I'm worried too much about the point of my pencil that might break ... or the ... I dont't know ... the nozzle being blocked.

Dismissing the other tools is ... I was kinda joking, but ... there is something sort of blocklike: Point. Move. This. But at the same time, like I said, I wouldn't do a cover in ConTeXt. Just like I probably wouldn't try to do something like a recreation of a Pre-Raphaelite painting in Processing or something like that. There is just points where our metaphors break down. And so ... It sounded sort of, ok, bottom-up über alles like always.

Ok, there's still painters and there's still people doing Pre-Raphaelite paintings with Pre-Raphaelite tools, but most of us are using computers. So there should be more clever ways of thinking about this.

Yeah. To borrow a quote from my old buddy Donald Rumsfeld: There are the known knowns, the known unknowns and the unknown unknowns. That actually popped into my head earlier because when we were talking about the potentials of the software and the way that we interact and stuff, it's like we know that we don't know ... other ways of organizing. We know that there are, like there has to be, another way, whether it is a middle path between these two or some sort of ... Maybe it's just tenth dimensional, maybe it's fourth dimensional, maybe it's completely hypermodern or something. Anyway. But the unknown unknowns ... It's like the stuff that we can't even tell we don't know about. The questions that we don't know about that would come up once we figure out these other ways of organising it. That's when I start to get really interested in this sort of thing. How do you even conceive of a practise that you don't know? And once you get there, there's going to be other things that you know you don't know and have to keep finding them. And then there's gonna be things that you don't know you don't know and they just appear from nowhere and ... it's fun.