<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Slvie</id>
	<title>H&amp;D Publishing Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Slvie"/>
	<link rel="alternate" type="text/html" href="https://wiki2print.hackersanddesigners.nl/wiki/Special:Contributions/Slvie"/>
	<updated>2026-04-12T20:38:01Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.39.3</generator>
	<entry>
		<id>https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Creative_Crowd&amp;diff=6050</id>
		<title>Creative Crowd</title>
		<link rel="alternate" type="text/html" href="https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Creative_Crowd&amp;diff=6050"/>
		<updated>2023-07-14T13:06:27Z</updated>

		<summary type="html">&lt;p&gt;Slvie: basic editing grammer and punctuation&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Wiki-to-print/Wiki2print/Wiki-to-pdf, and so on... ==&lt;br /&gt;
=== An (ongoing) exchange between Hackers &amp;amp; Designers and Varia about “publishing along the trails”. === &lt;br /&gt;
&lt;br /&gt;
In the following conversation, the two collectives H&amp;amp;D and Varia discuss and trace the distributed process of building and working with web-based open-source publishing tools and workflows that are referred to as Wiki-to-print, Wiki2print or Wiki-to-pdf. While prevailing monocultures of design software created conditions in which it is difficult to imagine publishing processes otherwise, the wiki-to-print experiments discussed here propose other possible socio-technical scenarios for designing and working together that are not merely utilitarian or solution-driven. Such tools nourish attitudes that challenge linearity, efficiency, and a progress-based understanding of a design process.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; We are curious about the genealogy of Wiki-to-pdf/print as it is used for collective publishing. Can you recollect what brought you to this workflow? What precisely sparked your curiosity and kept you interested in working with the MediaWiki infrastructure to edit and design publications?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; We were introduced to Wikis and the MediaWiki software in particular during our studies, at what is now called the Experimental Publishing Master at the Piet Zwart Institute. That wiki has been used since 2006 and is still used today by the students and staff to document projects, classes and How-to’s, as a shared calendar or place to prepare thesis drafts with tutors. The sociality of the wiki appears when it is part of the daily infrastructure and when it&#039;s used so intensively. The RecentChanges page, for example, has become a place where you can find out what other people have recently been working on. Hooking such social dynamics into a print workflow creates a lot of exciting possibilities when you think about it. &lt;br /&gt;
&lt;br /&gt;
Working with a &amp;quot;fresh&amp;quot; Wiki for making a book is quite different, but not less exciting. Using a Wiki in an editorial workflow is quite charming because it turns such workflow into a collective environment where everyone can follow the development of the content without imposing predefined article structures. A wiki page is &amp;quot;just&amp;quot; a page. The form and format are open. It&#039;s very different from, for example, a WordPress article, where the structure is predefined and cut up into smaller pieces (title, subtitle perhaps, author name, introduction, main text, etc). The attitude of the wiki software, to not impose a structure or format upon you, creates an interesting shift from technical protocols towards social protocols. What we mean by social protocols, is that decisions need to be made together, between people, not through a predefined technical configuration.&lt;br /&gt;
&lt;br /&gt;
This way of making publications is part of a bigger landscape of collective working environments, tools, habits and types of publications. This shift, from assembling a publication using a graphic user interface to compiling a publication through code, is super exciting to us. In our view, the biggest impact this software has is that it allows for a non-linear way of working: it makes the workflow much more continuous, and the design and editing are done in parallel. Of course, a deadline is unavoidable when working on printed matter. At some point, you need to stop editing. But this deadline is much softer compared to linear workflows where designers need to wait for the final version of the content before the design process can start. You can just make adjustments to the document style in CSS declarations, which are rendered each time you refresh the page. But they don&#039;t influence the content, which can keep changing.&lt;br /&gt;
&lt;br /&gt;
Working with Wiki software specifically is a small subsection of this landscape. There are many projects that worked with wikis for printed matter. Taking part in such a continuous timeline is super interesting to us! In 2017, Sandra Fauconnier, Cristina Cochior and Juan Gomez worked on [the potential of e-books based on Wikimedia content] (https://web.archive.org/web/20171016013843/http://www.publishinglab.nl/wiki-ebook/2017/01/27/wrapping-up-the-wiki-research/) during an INC research project at the PublishingLaband. Also, the Wikimedia Foundation has worked with [a range of different tools] (https://www.mediawiki.org/wiki/PDF_export) to add print support to the MediaWiki software and Wikipedia in particular. We had to dig a bit to find that link to PublishingLab, which thanks to the WayBack Machine, still exists online.&lt;br /&gt;
&lt;br /&gt;
This reminds us of the importance of documentation for maintaining links between the trail of wiki printing projects that has been growing in multiple directions in the last years. Code has been reused between different groups, ideas and approaches have been versioned over time, and a range of different kinds of printed publications have been based on Wiki workflows: newspapers, printed books, digital PDF files and web pages. This Wiki-to-print direction introduces Flask to dynamically connect the writing of the content and the rendering of the PDF. It is a side branch of the longer wiki printing timeline and operates in a more specific art/design context around the Netherlands and Belgium so far, but hopefully, it will continue travelling, morphing and transforming. Some projects on this trail include the following ones, but there are probably more.&lt;br /&gt;
&lt;br /&gt;
- André Castro and Alexia de Visscher&#039;s work on Mondotheque with Constant:&lt;br /&gt;
https://www.mondotheque.be/&lt;br /&gt;
https://books.constantvzw.org/home/mondotheque&lt;br /&gt;
- OSP&#039;s work on DiVersions with Constant:&lt;br /&gt;
https://diversions.constantvzw.org/&lt;br /&gt;
https://books.constantvzw.org/home/diversions-v2&lt;br /&gt;
- Manetta Berends&#039; work on Volumetric Regimes with Possible Bodies, published by Open Humanities Press in the Data Browser series: &lt;br /&gt;
https://volumetricregimes.xyz/&lt;br /&gt;
http://www.data-browser.net/db08.html&lt;br /&gt;
- Martino Morandi&#039;s work on Wiki-to-pdf with TITiPI:&lt;br /&gt;
https://titipi.org/wiki/index.php/Wiki-to-pdf&lt;br /&gt;
https://titipi.org/wiki-to-pdf/pagedjs/Infrastructural_Interactions&lt;br /&gt;
- Hackers &amp;amp; Designer&#039;s work on Making Matters:&lt;br /&gt;
https://hackersanddesigners.nl/s/Publishing/p/Making_Matters._A_Vocabulary_of_Collective_Arts&lt;br /&gt;
https://wiki2print.hackersanddesigners.nl/wiki/Publishing:Making_Matters_Lexicon&lt;br /&gt;
- Varia&#039;s work on Toward a Minor Tech with APRJA:&lt;br /&gt;
https://darc.au.dk/publications/peer-reviewed-newspaper&lt;br /&gt;
https://varia.zone/en/toward-a-minor-tech.html&lt;br /&gt;
https://cc.vvvvvvaria.org/wiki/Wiki-to-print&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; We are curious how you experienced being part of this trail. And how did it feel to see your code being reused again?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; It took some time before understanding the different pathways of this trail, how code has been forked, continued in different contexts, and developed in different directions. This process is ongoing, constantly evolving, so it&#039;s perhaps impossible to fully comprehend. There is a slowness to this process as well, and a (dispersed) collective effort, which is quite interesting. There are no feature requests or an agreement amongst these different groups and repositories for instance about predetermined outcomes. Through this slowness and also fragmentation, these tools can be questioned conceptually, technically, ethically and not necessarily conclusively ... readjusting general perceptions of what is inevitable and what is useful in conceptualizing and actualizing tools.&lt;br /&gt;
It seems it is a non-linear and somewhat unpredictable trail that has evolved over the years, that has more and less active moments. &lt;br /&gt;
H&amp;amp;D has also worked with wikis for a long time already, i.e. as a cms to our website (https://hackersanddesigners.nl/s/Publishing/p/The_making_of_hackersanddesigners.nl), which is a central place for writing and editing workshop manuals, announcements, workshop and project documentation. André Castro joined a H&amp;amp;D meetup a long time ago (maybe in 2015) and introduced us to some Wiki stuff. Similarly to what you described in the context of XPUB, Wikis became an integral part of H&amp;amp;D&#039;s collective infrastructure and ways of organizing ourselves. The Wikis are intertwined with the ways the group works together and is also reflected in the shared excitement about working with Wiki as a publishing infrastructure, that allows us to collapse processes of writing, editing, designing, and archiving. &lt;br /&gt;
&lt;br /&gt;
We made a publication in 2015 using Wiki and LaTeX https://hackersanddesigners.nl/s/Publishing/p/HDSA2015-documentation, and in 2016 we made one using Wiki and Scribus https://hackersanddesigners.nl/s/Publishing/p/HDSA2016-documentation &amp;lt;!--[super nice!]--&amp;gt; &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; What triggered the shift from LaTeX and Scribus to Wiki2print?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; It was exciting to see a layout produced more or less instantly. And it looked pretty good! Yet, the learning curve of LaTeX was quite steep. Coming from graphic design and being used to somewhat &#039;intuitive&#039; ways of working with layout software, that is, being able to &#039;see&#039; different versions of a layout very quickly, the process and outcome of using LaTex seemed rather stiff in comparison. It also seemed that LaTeX is very good at certain things – i.e. making a layout look very &#039;proper&#039; but not so good at making exciting unexpected interventions. The wiki-scribus combination was much more flexible. We basically just used the wiki to edit and structure the publication collaboratively and eventually exported and used Pandoc to convert the wiki syntax to something we could import and use in Scribus. While we could simultaneously edit in the wiki and easily update the Scribus file with the new content without losing the styling we had done, there was still this break between writing/assembling of the content on the one hand and styling it on the other. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; What triggered the shift from LaTeX and Scribus to wiki2print?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; It took us a while to move towards Wiki2print. There were various other convulsed publishing experiments in between, like heart-beat to print, and the PJ Machine from Sara Garcin. &lt;br /&gt;
&lt;br /&gt;
What is interesting about Wiki2print is indeed the workflow that is so different to what one is used to. As you mentioned before, the separations of different tasks, that are often embodied by different people inhabit (designer, writer, coder, copy editor...) are not so separate anymore. As a designer, you make different kinds of choices if you are involved in all other layers of the publishing process as well. It may seem as if less is possible in this workflow, for example in comparison to the inDesign experience... you have less control or agency over the outcome. But you could also question the so-called agency given by certain tools – the illusion of mastery they emanate. &lt;br /&gt;
&lt;br /&gt;
Wendy Hui Kyong Chun wrote about this in her text on Daemonic Interfaces (Programmed Visions: Software and Memory). The so-called intuitive user experience, dragging and dropping moves the tool to the background. One thinks about it less if one feels in control. You don&#039;t question it anymore, it enters your subconscious... In this way, tools like inDesign, become inevitable. Intuitive software also become unchallenged. Working with Wiki2print is quite edgy in comparison. The limits are very present... maybe something to hold on to, not to overcome?  &lt;br /&gt;
&lt;br /&gt;
Anyhow, in 2022 we worked on the [Making Matters](add link) publication for which we looked at the repository of Manetta for [Volumetric Regimes for Possible Bodies](add link) and Martino for [TITiPI](add link). It was super helpful to see some exciting examples and build upon what is already there. By doing so, also a feeling of response-ability evolved, to make the trail legible somehow. The writing of the colophon became an important part of making that trail more visible to ourselves and others. We added an elaborate [&#039;Note about the design of the publication&#039;](add link) in which we acknowledged the work that has already been done, and mention other relevant projects and practices that inspire us. We felt so excited to read the colophon of Minor Tech and see the trail grow and take part in it.&lt;br /&gt;
&lt;br /&gt;
As you mentioned before, part of continuing the trail is also making sure projects are well documented so that someone else can understand and reuse it. We also like the idea of contributing to the larger collective effort of improving these forms of publishing. For instance, we heard about a small issue, that we felt we could pay attention to in our next publication [First, then... repeat]. Wiki has a very useful feature to upload new versions of files. Yet, in the Paged.js preview the new version was not updating. In Making Matters we found a convoluted workaround by renaming every new file version and changing the image tag in the article. We now added an &amp;quot;overwrite images&amp;quot; check box https://wiki2print.hackersanddesigners.nl/ which replaces the image with the last uploaded version. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; Super nice to see that feature! Maybe related to the new image versions issue... We also ran into the issue that MediaWiki works with a job queue, which means that edits are held back and spread over time to make sure that the server is not overloaded. We are working around this by running the `runJobs.php` maintenance script that is shipped with the MediaWiki software, which works, but it is still a bit of a stretch.&lt;br /&gt;
&lt;br /&gt;
Speaking of features, it is nice to see custom Paged.js features appearing in other projects. Amélie Dumont is currently working on a website and book for which they work with a Javascript function to &amp;quot;keep&amp;quot; your scroll after a refresh. OMG Yes! Which is such a super useful feature to have when working on a book with many pages!&lt;br /&gt;
&lt;br /&gt;
It is nice to be reminded of the https://wiki2print.hackersanddesigners.nl/ link btw and to see the index page that you and also Martino started to work with. We decided to step away from it and integrated the index and update button(s) inside the wiki, which are two update buttons in our case: one for the text and one for the more heavier updates of media. In that way, we don&#039;t need to switch between the wiki interface and the Flask one, which felt like an interesting step towards staying within one shared environment both for writing and layout making. That is also why we totally forgot about this page actually. The page is technically still there in the version of wiki-to-print that is installed on the CC server, but it has no specific function anymore, apart from reminding us that we clicked an update button on the wiki, because it opens all the time after such click, which is probably something we could work around, but well...&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; It seems we have developed ways working on publications that are quite flexible and sometimes come with contingent and surprising outcomes. What is enjoyable about this way of working is that content production and design of publications can emerge on the go and in response to different collective conditions (i.e. different timelines, dispersed geographies, janky infrastructure). In the context of the Making Matters publication this somewhat unforeseeable collective process that we usually cherished, became quite challenging and somewhat incompatible with the material realities and ways of working of a publisher. You mentioned the softness of boundaries between designing, writing and editing. These soft boundaries can also become a bit scary when working on a publication with many pages, a large edition, involving high production costs. When changes in the beginning of the document can still affect something in the middle – potentially without us noticing. &lt;br /&gt;
There are many more tensions that can be experienced when it comes to designing for print in the browser. For instance, preparing and uploading images in high resolution seems counter intuitive in the context of web and network technologies. What are other tensions that come to mind and how do you negotiate those? Are there printing techniques that can be regarded as more compatible with wiki-to-print workflows than others? &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; Editing wiki pages in order to change how a page will look on paper feels very counter-intuitive, as well. And sometimes you forget about things that are elementary to the web, like animated GIFs. In the browser of course, you can use animated GIFs. However, before exporting PDFs we had to remove the GIFs from wiki pages, to have control over which frame would appear in print. Of course you can undo these edits after exporting and still have the GIFs on the wiki, but it still feels counter-intuitive. [It can be fun to add animations to add some purposeful contingency into a layout too. see https://chatty-pub.hackersanddesigners.nl/Scriptothek#ch-infrables :-)]&lt;br /&gt;
&lt;br /&gt;
Another important bottleneck in the wiki-to-print workflow is image placement. When we approach a page as a &amp;quot;canvas&amp;quot;: with fixed margins, columns and font size, then the positioning of images is a very painful part of the process. The placement of an image depends on its position in the flow of the text. But of course, when you place an image on a wiki page, you have no idea where it ends up on a printed page! CSS Regions was initially introduced to work around this as it allows you to position the images and let text flow around them on a page. But unfortunately CSS Regions are not supported anymore by current browsers. There are different attitudes when designing for print, or for web, and implications that come from diverging established workflows. To give every image the same fixed width seems quite brutal in print, even though it may be desirable on the web, or vice versa. But the effects of resizing images one-by-one can easily cascade and you have to think about what else is affected on following pages.&lt;br /&gt;
&lt;br /&gt;
There is also the question of design cultures and ways of thinking that come from specific software. Shifting away from tools that are based on 500+ years of book design traditions toward web environments that are based on network technologies has many implications. One thing we noticed is that there has to be an adjustment in how much time and attention is given to producing a PDF for print. The instantaneousness of the web affects understandings of how ready the PDF is for printing, or how PDF documents are build at all. The PDF may still need to be converted into CYMK colorspace, distilled for a particular PDF format or have imposition applied before it is sent to a printer. Even though you can see it rendered in a browser window immediately the print preview is a sort of illusion. You are not really looking at the final version of the PDF at all, a lot of steps need to be taken afterwards to match industrial printing standards. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; What processes do your pdfs undergo &#039;afterwards&#039; to match printing standards?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; The Volumetric Regimes book is produced on-demand and needed to be submitted in a PDF/X-3:2002 format, which is not the format that browsers provide by default. It was quite a search to find a way to turn a PDF into that format, and in the end, LaTeX was the way out here. Another big surprise that appeared during the making of the Volumetric Regimes book was the disappearance of the emoji face on [the cover](https://volumetricregimes.xyz/index.php?title=File:VRcover.png). We wanted to overprint this black emoji over the blue background gradient, which we managed to do with Ghostscript and [OSP&#039;s PDF-utils repository](https://gitlab.constantvzw.org/osp/tools.pdfutils). The PDF looked fine, the preflight software displayed the cover fine, so we were relieved! What we did not expect though, is to receive a box of books without the author names. They disappeared! The overprinting feature was applied to all elements on the cover, including the white text. Thanks to more help of the OSPs, we figured out that we can use Scribus to open the cover PDF and apply overprint only to a particular layer of the PDF. It was such a struggle!&lt;br /&gt;
&lt;br /&gt;
The Minor Tech newspaper didn&#039;t require such conversion, because we could talk with the people at Tripiti directly, who printed the newspaper for us. In that case we only converted the PDF into a grayscale colorspace, to make sure that the whole PDF was rendered in one color, which we needed because the newspaper was printed in offset with a spot colour. One thing that is not necessarily an &#039;afterwards&#039; process, but an important one, is browser choice. We worked using Mozilla Firefox for the Minor Tech newspaper up until realizing (just after midnight) that images were all in very low resolution when we pressed ctrl+P, so we had to switch to Chrome to make the final PDF. Even then, Chrome rendered the PDF slightly differently and we had to make some adjustments. These are things you hardly think about until right at the end of a design process. Luckily we caught this in time!&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; We loved reading your article about disappearing / eaten sentences: https://cc.vvvvvvaria.org/wiki/Octolog) and the hacks people invent to work around these issues, &amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt; :-))) &lt;br /&gt;
Karl brought back the Minor Tech newspaper from Transmediale. We were looking at it and were particularly impressed by the column layout! We have experienced a lot of issues with disappearing text in columns in the (printed) [First, Then... Repeat](link) publication. We felt a bit haunted by it and had agreed to NEVER use columns again! As you have experienced too text kept disappearing in the pdf, while in the browser it would still be visible! &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; Yes the disappearing sentences, oof, they were so painful. What really helped was that we were being able to reach out to Paged.js through their Mattermost chat. Julien Taquet works on Paged.js and is super present on the chat. It was through him that we could start to understand what the cause of this issue is, which was helpful and partially released some stress. But it did not solve the issue straight away, as it is a very sensitive one with close ties to the lower processing levels of Paged.js. So in the end we forced a page break on a very specific position in the text, which is a very scary thing to do, because it means that nothing else in the article can be changed anymore, not even a letter, to make sure that you don&#039;t end up with big gaps in the text. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; To come back to other tensions related to collective processes, what challenges did you encounter during the Making Matters production? What kind of changes were made in the last moment? How did this have an impact on the layout?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; A challenging element was to converge – on the one hand the expectations to make something that reflects collective experimentation, which the book spoke about in its content and on the other hand negotiate the pretty much non-negotiable linear workflow of academic publishing, very tight deadlines, and many contributors and editors that don&#039;t know each other, are dispersed and hard to reach. A more fluent reciprocal process in this context didn&#039;t seem feasible. The notion of &amp;quot;experimentation&amp;quot; as well as &amp;quot;collective&amp;quot; were taken for granted as something inherently productive, as something that leads with certainty towards results – that can be predicated and measured by the same standards and criteria as any other book. While we were interested in and open about challenging the arbitrary boundaries of what is considered professional book design and what is not there were moments our &amp;quot;expertise&amp;quot; was questioned as designers. &lt;br /&gt;
By choosing this path we had ourselves already decided that micro-typography may not be our biggest priority. Instead, we could pay attention to other exciting things. For instance, the publication accommodates non-linear reading, which is something that the flat structure of a wiki inspired us to do. Cross-references are indicated with different kinds of arrows, referring to one of the seven chapter themes. The arrows occur on the chapter introduction pages, next to the respective terms, as well as in the side-bar navigation of the respective chapter categories. This allows the reader to quickly sift through the book and find terms in different contexts. In addition, elements in the side-bar navigation subtly poke out when indicating the occurrence of a term in the text. We also worked with different colors per chapter and a subtle gradient that changes throughout the whole book to indicate that terms do not &#039;belong&#039; solely in one place but that their place is ambiguous and theory meanings spill over. The latter caused quite some pain in the pre-press process. The generated PDF had so many strange hidden elements and layers in it, that apparently showed up in the pre-press and caused a lot of troubles producing the gradient. We were not in contact with the printer directly, which made this whole pre-press process even harder. &lt;br /&gt;
&lt;br /&gt;
Making Matters was our first wiki-to-print attempt. Entering a rather large project with a publishing infrastructure that was quite new to us was exciting at first but also quite risky and stressful as there were so many moving variables. &lt;br /&gt;
&lt;br /&gt;
We had to present a pretty fixed design proposal at the beginning of the process, which we then worked towards. In a way we made a promise without knowing what is possible. On the one hand it was helpful to have a goal – something to hold on to. But it was also stressful because of unexpected quirks and impossibilities. Honestly, we did it because there was a budget for once, which gave us the possibility to finally dive into this workflow. Eventually we worked at least double of what we were paid. &lt;br /&gt;
&lt;br /&gt;
After that publication we&#039;ve been moving more and more towards a CSS editing process in the wiki CSS panel. That way, editing and styling become part of the same workflow, which also facilitates a more flexible approach to the design of the publication. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; How did you do it before having the CSS in the wiki CSS panel? It seems to have had a big shift to work within the wiki all together.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; The Making Matters book needed to be laid out on a baseline grid, which proved to be challenging in CSS. We used a more traditional web development approach for the styling using Sass and a library called Plumber that made it possible to have a baseline grid in CSS. Web fonts don&#039;t always have a consistent baseline so you need to account for that for each font using positive and negative margins. Also images needed to be scaled so that they conform to the grid vertically. Headaches! This meant that editing content and applying styles were not integrated into a unified workflow regrettably. On the other hand, since the project was so CSS heavy it made sense to work on it in a more &#039;user-friendly&#039; environment. There were so many small interventions! As mentioned before, the book is structured like a dictionary and each time there is a keyword in the text the illustration in the margin reacts to that, creating a little animation when you flip through the book. We used P5js with a SVG renderer for that so that the illustrations were usable in print. In the end we made a little front-end in the PDF view where we can play with some of the settings, change the version of the script, toggle a view of the baseline grid, separate layers for printing. It was a fun challenge but since then we have moved more and more to a single workflow, and also simpler layouts. Only the fonts are hardcoded and all other styling done in the wiki. It makes for a more collaborative workflow. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; We are curious, how to organize collective workflows around a wiki-to-print project? i.e. How many people should be involved in the workflow? How are tasks divided? Are you working in the same space or distributed/remotely? What are appropriate timelines and budgets?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; Regarding the soft deadlines, we noticed that working closely between editors and designers is really needed to make it happen. It is also important to have a shared understanding of the limitations and possibilities of wiki software, to find ways to think along with the workflow instead of going against the grain. This needs time for conversation and reflection and it is always a bit of a struggle. It&#039;s something that we are still figuring out.&lt;br /&gt;
&lt;br /&gt;
We have different experiences regarding the columns and collective conditions shaped by the workflow that also depend on the publication&#039;s content, conditions, collectivity and design choices. With Varia&#039;s occasional printed newsletter SomeTimes we were used to using columns in Octomode (a way of making PDFs from Etherpads), where all you have to worry about usually is how content flows from one column to another. [To give an idea, this is the PDF of SomeTimes, Issue 1, made in Octomode](https://varia.zone/documents/SomeTimes_number-1.pdf). The content of SomeTimes is made collectively from RSS feeds, particular hashtags on Mastodon, and posts gathered by a logbot. We have made a couple issues of it by now, and the simple design works, so we don&#039;t need to change it much. The budget is low, we produce it on A3 on a laser printer in our space in Rotterdam. Also the timelines are always short because we&#039;re already in the middle of so many other projects while working on it. In the making of this RSS workflow, we took these conditions as starting points for the design and development process.&lt;br /&gt;
&lt;br /&gt;
On the other hand, the Minor Tech newspaper was made using wiki-to-print and CSS grid during a two-day publication sprint between two people in Rotterdam and a large group that were writing and editing articles at a workshop in London. We were new to using CSS grid for paged media, and it took quite some tetris-ing to work within the constraints of the grid and a pre-determined page count. We spent a few hours before the sprint puzzling how different articles could fit, sketching in Octomode and on paper.&lt;br /&gt;
&lt;br /&gt;
![Aerial view of Varia working at our laptops in Rotterdam](https://vvvvvvaria.org/logs/toward-a-minor-tech/image/I1RSpI0hT_63HJ1giGW0Mw.jpg) &lt;br /&gt;
![Tetris-ing in Octomode](https://vvvvvvaria.org/logs/toward-a-minor-tech/image/Screenshot_from_2023-01-18_16-52-54.png) &lt;br /&gt;
![Tetris-ing on paper before the sprint](https://vvvvvvaria.org/logs/toward-a-minor-tech/image/U4vxHcdaQp-taZc_98-28Q.jpg)&lt;br /&gt;
&lt;br /&gt;
From the beginning, we had to accept the constraints of working within a rigid grid where it is impossible to flow articles from one page to another. It worked out in the case of the Minor Tech newspaper, as the texts were written with a maximum amount of 500 words. We ended up with a lot of small empty spaces though. We asked the writers for &amp;quot;cellular contributions&amp;quot; – content that would fit within the spaces of the newspaper that were left empty after our tetris-ing. The proposal for cellular contributions resulted in super nice quotes, pictures, and cute advertisements. &lt;br /&gt;
&lt;br /&gt;
![A quote included in the &amp;quot;cellular contributions&amp;quot; of the Toward a Minor Tech newspaper](https://varia.zone/archive/2023-01-Toward-a-Minor-Tech/toward-a-minor-tech-04.jpg)&lt;br /&gt;
&lt;br /&gt;
In this way, the shortcomings of working towards particular formats and scenarios, such as the typically heavy content density of a newspaper or a two-day collective production sprint, became a springboard into more experimental solutions and giving flexibility to the content and layout. This came from our choice to use CSS grid and also the availability of our collaborators during this sprint. But each publication workflow varies, and calls for different approaches. The use of CSS grid had a nice side effect, but the remote way of working during the sprint did not really help to let the production of content and layout overlap and intertwine. We would do this differently next time and prioritize being together in the same space to make sure we are in conversation with each other.&lt;br /&gt;
&lt;br /&gt;
... read the continuation of this conversation in the next bulletin&lt;/div&gt;</summary>
		<author><name>Slvie</name></author>
	</entry>
	<entry>
		<id>https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Creative_Crowd&amp;diff=6049</id>
		<title>Creative Crowd</title>
		<link rel="alternate" type="text/html" href="https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Creative_Crowd&amp;diff=6049"/>
		<updated>2023-07-14T13:04:25Z</updated>

		<summary type="html">&lt;p&gt;Slvie: basic editing grammer and punctuation&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Wiki-to-print/Wiki2print/Wiki-to-pdf, and so on... ==&lt;br /&gt;
=== An (ongoing) exchange between Hackers &amp;amp; Designers and Varia about “publishing along the trails”. === &lt;br /&gt;
&lt;br /&gt;
In the following conversation, the two collectives H&amp;amp;D and Varia discuss and trace the distributed process of building and working with web-based open-source publishing tools and workflows that are referred to as Wiki-to-print, Wiki2print or Wiki-to-pdf. While prevailing monocultures of design software created conditions in which it is difficult to imagine publishing processes otherwise, the wiki-to-print experiments discussed here propose other possible socio-technical scenarios for designing and working together that are not merely utilitarian or solution-driven. Such tools nourish attitudes that challenge linearity, efficiency, and a progress-based understanding of a design process.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; We are curious about the genealogy of Wiki-to-pdf/print as it is used for collective publishing. Can you recollect what brought you to this workflow? What precisely sparked your curiosity and kept you interested in working with the MediaWiki infrastructure to edit and design publications?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; We were introduced to Wikis and the MediaWiki software in particular during our studies, at what is now called the Experimental Publishing Master at the Piet Zwart Institute. That wiki has been used since 2006 and is still used today by the students and staff to document projects, classes and How-to’s, as a shared calendar or place to prepare thesis drafts with tutors. The sociality of the wiki appears when it is part of the daily infrastructure and when it&#039;s used so intensively. The RecentChanges page, for example, has become a place where you can find out what other people have recently been working on. Hooking such social dynamics into a print workflow creates a lot of exciting possibilities when you think about it. &lt;br /&gt;
&lt;br /&gt;
Working with a &amp;quot;fresh&amp;quot; Wiki for making a book is quite different, but not less exciting. Using a Wiki in an editorial workflow is quite charming because it turns such workflow into a collective environment where everyone can follow the development of the content without imposing predefined article structures. A wiki page is &amp;quot;just&amp;quot; a page. The form and format are open. It&#039;s very different from, for example, a WordPress article, where the structure is predefined and cut up into smaller pieces (title, subtitle perhaps, author name, introduction, main text, etc). The attitude of the wiki software, to not impose a structure or format upon you, creates an interesting shift from technical protocols towards social protocols. What we mean by social protocols, is that decisions need to be made together, between people, not through a predefined technical configuration.&lt;br /&gt;
&lt;br /&gt;
This way of making publications is part of a bigger landscape of collective working environments, tools, habits and types of publications. This shift, from assembling a publication using a graphic user interface to compiling a publication through code, is super exciting to us. In our view, the biggest impact this software has is that it allows for a non-linear way of working: it makes the workflow much more continuous, and the design and editing are done in parallel. Of course, a deadline is unavoidable when working on printed matter. At some point, you need to stop editing. But this deadline is much softer compared to linear workflows where designers need to wait for the final version of the content before the design process can start. You can just make adjustments to the document style in CSS declarations, which are rendered each time you refresh the page. But they don&#039;t influence the content, which can keep changing.&lt;br /&gt;
&lt;br /&gt;
Working with Wiki software specifically is a small subsection of this landscape. There are many projects that worked with wikis for printed matter. Taking part in such a continuous timeline is super interesting to us! In 2017, Sandra Fauconnier, Cristina Cochior and Juan Gomez worked on [the potential of e-books based on Wikimedia content] (https://web.archive.org/web/20171016013843/http://www.publishinglab.nl/wiki-ebook/2017/01/27/wrapping-up-the-wiki-research/) during an INC research project at the PublishingLaband. Also, the Wikimedia Foundation has worked with [a range of different tools] (https://www.mediawiki.org/wiki/PDF_export) to add print support to the MediaWiki software and Wikipedia in particular. We had to dig a bit to find that link to PublishingLab, which thanks to the WayBack Machine, still exists online.&lt;br /&gt;
&lt;br /&gt;
This reminds us of the importance of documentation for maintaining links between the trail of wiki printing projects that has been growing in multiple directions in the last years. Code has been reused between different groups, ideas and approaches have been versioned over time, and a range of different kinds of printed publications have been based on Wiki workflows: newspapers, printed books, digital PDF files and web pages. This Wiki-to-print direction introduces Flask to dynamically connect the writing of the content and the rendering of the PDF. It is a side branch of the longer wiki printing timeline and operates in a more specific art/design context around the Netherlands and Belgium so far, but hopefully, it will continue travelling, morphing and transforming. Some projects on this trail include the following ones, but there are probably more.&lt;br /&gt;
&lt;br /&gt;
- André Castro and Alexia de Visscher&#039;s work on Mondotheque with Constant:&lt;br /&gt;
https://www.mondotheque.be/&lt;br /&gt;
https://books.constantvzw.org/home/mondotheque&lt;br /&gt;
- OSP&#039;s work on DiVersions with Constant:&lt;br /&gt;
https://diversions.constantvzw.org/&lt;br /&gt;
https://books.constantvzw.org/home/diversions-v2&lt;br /&gt;
- Manetta Berends&#039; work on Volumetric Regimes with Possible Bodies, published by Open Humanities Press in the Data Browser series: &lt;br /&gt;
https://volumetricregimes.xyz/&lt;br /&gt;
http://www.data-browser.net/db08.html&lt;br /&gt;
- Martino Morandi&#039;s work on Wiki-to-pdf with TITiPI:&lt;br /&gt;
https://titipi.org/wiki/index.php/Wiki-to-pdf&lt;br /&gt;
https://titipi.org/wiki-to-pdf/pagedjs/Infrastructural_Interactions&lt;br /&gt;
- Hackers &amp;amp; Designer&#039;s work on Making Matters:&lt;br /&gt;
https://hackersanddesigners.nl/s/Publishing/p/Making_Matters._A_Vocabulary_of_Collective_Arts&lt;br /&gt;
https://wiki2print.hackersanddesigners.nl/wiki/Publishing:Making_Matters_Lexicon&lt;br /&gt;
- Varia&#039;s work on Toward a Minor Tech with APRJA:&lt;br /&gt;
https://darc.au.dk/publications/peer-reviewed-newspaper&lt;br /&gt;
https://varia.zone/en/toward-a-minor-tech.html&lt;br /&gt;
https://cc.vvvvvvaria.org/wiki/Wiki-to-print&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; We are curious how you experienced being part of this trail. And how did it feel to see your code being reused again?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; It took some time before understanding the different pathways of this trail, how code has been forked, continued in different contexts, and developed in different directions. This process is ongoing, constantly evolving, so it&#039;s perhaps impossible to fully comprehend. There is a slowness to this process as well, and a (dispersed) collective effort, which is quite interesting. There are no feature requests or an agreement amongst these different groups and repositories for instance about predetermined outcomes. Through this slowness and also fragmentation, these tools can be questioned conceptually, technically, ethically and not necessarily conclusively ... readjusting general perceptions of what is inevitable and what is useful in conceptualizing and actualizing tools.&lt;br /&gt;
It seems it is a non-linear and somewhat unpredictable trail that has evolved over the years, that has more and less active moments. &lt;br /&gt;
H&amp;amp;D has also worked with wikis for a long time already, i.e. as a cms to our website (https://hackersanddesigners.nl/s/Publishing/p/The_making_of_hackersanddesigners.nl), which is a central place for writing and editing workshop manuals, announcements, workshop and project documentation. André Castro joined a H&amp;amp;D meetup a long time ago (maybe in 2015) and introduced us to some Wiki stuff. Similarly to what you described in the context of XPUB, Wikis became an integral part of H&amp;amp;D&#039;s collective infrastructure and ways of organizing ourselves. The Wikis are intertwined with the ways the group works together and is also reflected in the shared excitement about working with Wiki as a publishing infrastructure, that allows us to collapse processes of writing, editing, designing, and archiving. &lt;br /&gt;
&lt;br /&gt;
We made a publication in 2015 using Wiki and LaTeX https://hackersanddesigners.nl/s/Publishing/p/HDSA2015-documentation, and in 2016 we made one using Wiki and Scribus https://hackersanddesigners.nl/s/Publishing/p/HDSA2016-documentation &amp;lt;!--[super nice!]--&amp;gt; &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; What triggered the shift from LaTeX and Scribus to Wiki2print?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; It was exciting to see a layout produced more or less instantly. And it looked pretty good! Yet, the learning curve of LaTeX was quite steep. Coming from graphic design and being used to somewhat &#039;intuitive&#039; ways of working with layout software, that is, being able to &#039;see&#039; different versions of a layout very quickly, the process and outcome of using LaTex seemed rather stiff in comparison. It also seemed that LaTeX is very good at certain things – i.e. making a layout look very &#039;proper&#039; but not so good at making exciting unexpected interventions. The wiki-scribus combination was much more flexible. We basically just used the wiki to edit and structure the publication collaboratively and eventually exported and used Pandoc to convert the wiki syntax to something we could import and use in Scribus. While we could simultaneously edit in the wiki and easily update the Scribus file with the new content without losing the styling we had done, there was still this break between writing/assembling of the content on the one hand and styling it on the other. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; What triggered the shift from LaTeX and Scribus to wiki2print?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; It took us a while to move towards Wiki2print. There were various other convulsed publishing experiments in between, like heart-beat to print, and the PJ Machine from Sara Garcin. &lt;br /&gt;
&lt;br /&gt;
What is interesting about Wiki2print is indeed the workflow that is so different to what one is used to. As you mentioned before, the separations of different tasks, that are often embodied by different people inhabit (designer, writer, coder, copy editor...) are not so separate anymore. As a designer, you make different kinds of choices if you are involved in all other layers of the publishing process as well. It may seem as if less is possible in this workflow, for example in comparison to the inDesign experience... you have less control or agency over the outcome. But you could also question the so-called agency given by certain tools – the illusion of mastery they emanate. &lt;br /&gt;
&lt;br /&gt;
Wendy Hui Kyong Chun wrote about this in her text on Daemonic Interfaces (Programmed Visions: Software and Memory). The so-called intuitive user experience, dragging and dropping moves the tool to the background. One thinks about it less if one feels in control. You don&#039;t question it anymore, it enters your subconscious... In this way, tools like inDesign, become inevitable. Intuitive software also become unchallenged. Working with Wiki2print is quite edgy in comparison. The limits are very present... maybe something to hold on to, not to overcome?  &lt;br /&gt;
&lt;br /&gt;
Anyhow, in 2022 we worked on the [Making Matters](add link) publication for which we looked at the repository of Manetta for [Volumetric Regimes for Possible Bodies](add link) and Martino for [TITiPI](add link). It was super helpful to see some exciting examples and build upon what is already there. By doing so, also a feeling of response-ability evolved, to make the trail legible somehow. The writing of the colophon became an important part of making that trail more visible to ourselves and others. We added an elaborate [&#039;Note about the design of the publication&#039;](add link) in which we acknowledged the work that has already been done, and mention other relevant projects and practices that inspire us. We felt so excited to read the colophon of Minor Tech and see the trail grow and take part in it.&lt;br /&gt;
&lt;br /&gt;
As you mentioned before, part of continuing the trail is also making sure projects are well documented so that someone else can understand and reuse it. We also like the idea of contributing to the larger collective effort of improving these forms of publishing. For instance, we heard about a small issue, that we felt we could pay attention to in our next publication [First, then... repeat]. Wiki has a very useful feature to upload new versions of files. Yet, in the Paged.js preview the new version was not updating. In Making Matters we found a convoluted workaround by renaming every new file version and changing the image tag in the article. We now added an &amp;quot;overwrite images&amp;quot; check box https://wiki2print.hackersanddesigners.nl/ which replaces the image with the last uploaded version. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; Super nice to see that feature! Maybe related to the new image versions issue... We also ran into the issue that MediaWiki works with a job queue, which means that edits are held back and spread over time to make sure that the server is not overloaded. We are working around this by running the `runJobs.php` maintenance script that is shipped with the MediaWiki software, which works, but it is still a bit of a stretch.&lt;br /&gt;
&lt;br /&gt;
Speaking of features, it is nice to see custom Paged.js features appearing in other projects. Amélie Dumont is currently working on a website and book for which they work with a Javascript function to &amp;quot;keep&amp;quot; your scroll after a refresh. OMG Yes! Which is such a super useful feature to have when working on a book with many pages!&lt;br /&gt;
&lt;br /&gt;
It is nice to be reminded of the https://wiki2print.hackersanddesigners.nl/ link btw and to see the index page that you and also Martino started to work with. We decided to step away from it and integrated the index and update button(s) inside the wiki, which are two update buttons in our case: one for the text and one for the more heavier updates of media. In that way, we don&#039;t need to switch between the wiki interface and the Flask one, which felt like an interesting step towards staying within one shared environment both for writing and layout making. That is also why we totally forgot about this page actually. The page is technically still there in the version of wiki-to-print that is installed on the CC server, but it has no specific function anymore, apart from reminding us that we clicked an update button on the wiki, because it opens all the time after such click, which is probably something we could work around, but well...&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; It seems we have developed ways working on publications that are quite flexible and sometimes come with contingent and surprising outcomes. What is enjoyable about this way of working is that content production and design of publications can emerge on the go and in response to different collective conditions (i.e. different timelines, dispersed geographies, janky infrastructure). In the context of the Making Matters publication this somewhat unforeseeable collective process that we usually cherished, became quite challenging and somewhat incompatible with the material realities and ways of working of a publisher. You mentioned the softness of boundaries between designing, writing and editing. These soft boundaries can also become a bit scary when working on a publication with many pages, a large edition, involving high production costs. When changes in the beginning of the document can still affect something in the middle – potentially without us noticing. &lt;br /&gt;
There are many more tensions that can be experienced when it comes to designing for print in the browser. For instance, preparing and uploading images in high resolution seems counter intuitive in the context of web and network technologies. What are other tensions that come to mind and how do you negotiate those? Are there printing techniques that can be regarded as more compatible with wiki-to-print workflows than others? &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; Editing wiki pages in order to change how a page will look on paper feels very counter-intuitive, as well. And sometimes you forget about things that are elementary to the web, like animated GIFs. In the browser of course, you can use animated GIFs. However, before exporting PDFs we had to remove the GIFs from wiki pages, to have control over which frame would appear in print. Of course you can undo these edits after exporting and still have the GIFs on the wiki, but it still feels counter-intuitive. [It can be fun to add animations to add some purposeful contingency into a layout too. see https://chatty-pub.hackersanddesigners.nl/Scriptothek#ch-infrables :-)]&lt;br /&gt;
&lt;br /&gt;
Another important bottleneck in the wiki-to-print workflow is image placement. When we approach a page as a &amp;quot;canvas&amp;quot;: with fixed margins, columns and font size, then the positioning of images is a very painful part of the process. The placement of an image depends on its position in the flow of the text. But of course, when you place an image on a wiki page, you have no idea where it ends up on a printed page! CSS Regions was initially introduced to work around this as it allows you to position the images and let text flow around them on a page. But unfortunately CSS Regions are not supported anymore by current browsers. There are different attitudes when designing for print, or for web, and implications that come from diverging established workflows. To give every image the same fixed width seems quite brutal in print, even though it may be desirable on the web, or vice versa. But the effects of resizing images one-by-one can easily cascade and you have to think about what else is affected on following pages.&lt;br /&gt;
&lt;br /&gt;
There is also the question of design cultures and ways of thinking that come from specific software. Shifting away from tools that are based on 500+ years of book design traditions toward web environments that are based on network technologies has many implications. One thing we noticed is that there has to be an adjustment in how much time and attention is given to producing a PDF for print. The instantaneousness of the web affects understandings of how ready the PDF is for printing, or how PDF documents are build at all. The PDF may still need to be converted into CYMK colorspace, distilled for a particular PDF format or have imposition applied before it is sent to a printer. Even though you can see it rendered in a browser window immediately the print preview is a sort of illusion. You are not really looking at the final version of the PDF at all, a lot of steps need to be taken afterwards to match industrial printing standards. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; What processes do your pdfs undergo &#039;afterwards&#039; to match printing standards?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(Varia)&#039;&#039;&#039; The Volumetric Regimes book is produced on-demand and needed to be submitted in a PDF/X-3:2002 format, which is not the format that browsers provide by default. It was quite a search to find a way to turn a PDF into that format, and in the end, LaTeX was the way out here. Another big surprise that appeared during the making of the Volumetric Regimes book was the disappearance of the emoji face on [the cover](https://volumetricregimes.xyz/index.php?title=File:VRcover.png). We wanted to overprint this black emoji over the blue background gradient, which we managed to do with Ghostscript and [OSP&#039;s PDF-utils repository](https://gitlab.constantvzw.org/osp/tools.pdfutils). The PDF looked fine, the preflight software displayed the cover fine, so we were relieved! What we did not expect though, is to receive a box of books without the author names. They disappeared! The overprinting feature was applied to all elements on the cover, including the white text. Thanks to more help of the OSPs, we figured out that we can use Scribus to open the cover PDF and apply overprint only to a particular layer of the PDF. It was such a struggle!&lt;br /&gt;
&lt;br /&gt;
The Minor Tech newspaper didn&#039;t require such conversion, because we could talk with the people at Tripiti directly, who printed the newspaper for us. In that case we only converted the PDF into a grayscale colorspace, to make sure that the whole PDF was rendered in one color, which we needed because the newspaper was printed in offset with a spot colour. One thing that is not necessarily an &#039;afterwards&#039; process, but an important one, is browser choice. We worked using Mozilla Firefox for the Minor Tech newspaper up until realizing (just after midnight) that images were all in very low resolution when we pressed ctrl+P, so we had to switch to Chrome to make the final PDF. Even then, Chrome rendered the PDF slightly differently and we had to make some adjustments. These are things you hardly think about until right at the end of a design process. Luckily we caught this in time!&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;(H&amp;amp;D)&#039;&#039;&#039; We loved reading your article about disappearing / eaten sentences: https://cc.vvvvvvaria.org/wiki/Octolog) and the hacks people invent to work around these issues, &amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt; :-))) &lt;br /&gt;
Karl brought back the Minor Tech newspaper from Transmediale. We were looking at it and were particularly impressed by the column layout! We have experienced a lot of issues with disappearing text in columns in the (printed) [First, Then... Repeat](link) publication. We felt a bit haunted by it and had agreed to NEVER use columns again! As you have experienced too text kept disappearing in the pdf, while in the browser it would still be visible! &lt;br /&gt;
&lt;br /&gt;
(Varia) Yes the disappearing sentences, oof, they were so painful. What really helped was that we were being able to reach out to Paged.js through their Mattermost chat. Julien Taquet works on Paged.js and is super present on the chat. It was through him that we could start to understand what the cause of this issue is, which was helpful and partially released some stress. But it did not solve the issue straight away, as it is a very sensitive one with close ties to the lower processing levels of Paged.js. So in the end we forced a page break on a very specific position in the text, which is a very scary thing to do, because it means that nothing else in the article can be changed anymore, not even a letter, to make sure that you don&#039;t end up with big gaps in the text. &lt;br /&gt;
&lt;br /&gt;
(varia) To come back to other tensions, those related to collective processes, we would be curious to hear more about the challenges that you encountered during the Making Matters production? What kind of changes were made in the last moment? How did this have an impact on the layout?&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) A challenging element was to converge – on the one hand the expectations to make something that reflects collective experimentation, which the book spoke about in its content and on the other hand negotiate the pretty much non-negotiable linear workflow of academic publishing, very tight deadlines, and many contributors and editors that don&#039;t know each other, are dispersed and hard to reach. A more fluent reciprocal process in this context didn&#039;t seem feasible. The notion of &amp;quot;experimentation&amp;quot; as well as &amp;quot;collective&amp;quot; were taken for granted as something inherently productive, as something that leads with certainty towards results – that can be predicated and measured by the same standards and criteria as any other book. While we were interested in and open about challenging the arbitrary boundaries of what is considered professional book design and what is not there were moments our &amp;quot;expertise&amp;quot; was questioned as designers. &lt;br /&gt;
By choosing this path we had ourselves already decided that micro-typography may not be our biggest priority. Instead we could pay attention to other exciting things. For instance the publication accommodates non-linear reading, which is something that the flat structure of a wiki inspired us to do. Cross-references are indicated with  different kinds of arrows, referring to one of the seven chapter themes. The arrows occur on the chapter introduction pages, next to the respective terms, as well as in the side bar navigation of the respective chapter categories. This allows the reader to quickly sift through the book and find terms in different contexts. In addition, elements in the side bar navigation subtly poke out when indicating the occurrence of a term in the text. We also worked with different colors per chapter and a subtle gradient that changes throughout the whole book to indicate that terms do not &#039;belong&#039; solely in one place but that their place is ambiguous and theory meanings spill over. The latter caused quite some pain in the pre-press process. The generated PDF had so many strange hidden elements and layers in it, that apparently showed up in the pre-press and caused a lot of troubles producing the gradient. We were not in contact with the printer directly, which made this whole pre-press process even harder. &lt;br /&gt;
&lt;br /&gt;
Making Matters was our first wiki-to-print attempt. Entering a rather large project with a publishing infrastructure that was quite new to us was exciting at first but also quite risky and stressful as there were so many moving variables. &lt;br /&gt;
&lt;br /&gt;
We had to present a pretty fixed design proposal at the beginning of the process, which we then worked towards. In a way we made a promise without knowing what is possible. On the one hand it was helpful to have a goal – something to hold on to. But it was also stressful because of unexpected quirks and impossibilities. Honestly, we did it because there was a budget for once, which gave us the possibility to finally dive into this workflow. Eventually we worked at least double of what we were paid. &lt;br /&gt;
&lt;br /&gt;
After that publication we&#039;ve been moving more and more towards a CSS editing process in the wiki CSS panel. That way, editing and styling become part of the same workflow, which also facilitates a more flexible approach to the design of the publication. &lt;br /&gt;
&lt;br /&gt;
(Varia) How did you do it before having the CSS in the wiki CSS panel? It seems to have had a big shift to work within the wiki all together.&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) The Making Matters book needed to be laid out on a baseline grid, which proved to be challenging in CSS. We used a more traditional web development approach for the styling using Sass and a library called Plumber that made it possible to have a baseline grid in CSS. Web fonts don&#039;t always have a consistent baseline so you need to account for that for each font using positive and negative margins. Also images needed to be scaled so that they conform to the grid vertically. Headaches! This meant that editing content and applying styles were not integrated into a unified workflow regrettably. On the other hand, since the project was so CSS heavy it made sense to work on it in a more &#039;user-friendly&#039; environment. There were so many small interventions! As mentioned before, the book is structured like a dictionary and each time there is a keyword in the text the illustration in the margin reacts to that, creating a little animation when you flip through the book. We used P5js with a SVG renderer for that so that the illustrations were usable in print. In the end we made a little front-end in the PDF view where we can play with some of the settings, change the version of the script, toggle a view of the baseline grid, separate layers for printing. It was a fun challenge but since then we have moved more and more to a single workflow, and also simpler layouts. Only the fonts are hardcoded and all other styling done in the wiki. It makes for a more collaborative workflow. &lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) We are curious, how to organize collective workflows around a wiki-to-print project? i.e. How many people should be involved in the workflow? How are tasks divided? Are you working in the same space or distributed/remotely? What are appropriate timelines and budgets?&lt;br /&gt;
&lt;br /&gt;
(varia) Regarding the soft deadlines, we noticed that working closely between editors and designers is really needed to make it happen. It is also important to have a shared understanding of the limitations and possibilities of wiki software, to find ways to think along with the workflow instead of going against the grain. This needs time for conversation and reflection and it is always a bit of a struggle. It&#039;s something that we are still figuring out.&lt;br /&gt;
&lt;br /&gt;
We have different experiences regarding the columns and collective conditions shaped by the workflow that also depend on the publication&#039;s content, conditions, collectivity and design choices. With Varia&#039;s occasional printed newsletter SomeTimes we were used to using columns in Octomode (a way of making PDFs from Etherpads), where all you have to worry about usually is how content flows from one column to another. [To give an idea, this is the PDF of SomeTimes, Issue 1, made in Octomode](https://varia.zone/documents/SomeTimes_number-1.pdf). The content of SomeTimes is made collectively from RSS feeds, particular hashtags on Mastodon, and posts gathered by a logbot. We have made a couple issues of it by now, and the simple design works, so we don&#039;t need to change it much. The budget is low, we produce it on A3 on a laser printer in our space in Rotterdam. Also the timelines are always short because we&#039;re already in the middle of so many other projects while working on it. In the making of this RSS workflow, we took these conditions as starting points for the design and development process.&lt;br /&gt;
&lt;br /&gt;
On the other hand, the Minor Tech newspaper was made using wiki-to-print and CSS grid during a two-day publication sprint between two people in Rotterdam and a large group that were writing and editing articles at a workshop in London. We were new to using CSS grid for paged media, and it took quite some tetris-ing to work within the constraints of the grid and a pre-determined page count. We spent a few hours before the sprint puzzling how different articles could fit, sketching in Octomode and on paper.&lt;br /&gt;
&lt;br /&gt;
![Aerial view of Varia working at our laptops in Rotterdam](https://vvvvvvaria.org/logs/toward-a-minor-tech/image/I1RSpI0hT_63HJ1giGW0Mw.jpg) &lt;br /&gt;
![Tetris-ing in Octomode](https://vvvvvvaria.org/logs/toward-a-minor-tech/image/Screenshot_from_2023-01-18_16-52-54.png) &lt;br /&gt;
![Tetris-ing on paper before the sprint](https://vvvvvvaria.org/logs/toward-a-minor-tech/image/U4vxHcdaQp-taZc_98-28Q.jpg)&lt;br /&gt;
&lt;br /&gt;
From the beginning, we had to accept the constraints of working within a rigid grid where it is impossible to flow articles from one page to another. It worked out in the case of the Minor Tech newspaper, as the texts were written with a maximum amount of 500 words. We ended up with a lot of small empty spaces though. We asked the writers for &amp;quot;cellular contributions&amp;quot; – content that would fit within the spaces of the newspaper that were left empty after our tetris-ing. The proposal for cellular contributions resulted in super nice quotes, pictures, and cute advertisements. &lt;br /&gt;
&lt;br /&gt;
![A quote included in the &amp;quot;cellular contributions&amp;quot; of the Toward a Minor Tech newspaper](https://varia.zone/archive/2023-01-Toward-a-Minor-Tech/toward-a-minor-tech-04.jpg)&lt;br /&gt;
&lt;br /&gt;
In this way, the shortcomings of working towards particular formats and scenarios, such as the typically heavy content density of a newspaper or a two-day collective production sprint, became a springboard into more experimental solutions and giving flexibility to the content and layout. This came from our choice to use CSS grid and also the availability of our collaborators during this sprint. But each publication workflow varies, and calls for different approaches. The use of CSS grid had a nice side effect, but the remote way of working during the sprint did not really help to let the production of content and layout overlap and intertwine. We would do this differently next time and prioritize being together in the same space to make sure we are in conversation with each other.&lt;br /&gt;
&lt;br /&gt;
... read the continuation of this conversation in the next bulletin&lt;/div&gt;</summary>
		<author><name>Slvie</name></author>
	</entry>
	<entry>
		<id>https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Creative_Crowd&amp;diff=6039</id>
		<title>Creative Crowd</title>
		<link rel="alternate" type="text/html" href="https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Creative_Crowd&amp;diff=6039"/>
		<updated>2023-07-14T11:44:41Z</updated>

		<summary type="html">&lt;p&gt;Slvie: basic editing grammer and punctuation&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Wiki-to-print/Wiki2print/Wiki-to-pdf, and so on... ==&lt;br /&gt;
=== An (ongoing) exchange between Hackers &amp;amp; Designers and Varia about “publishing along the trails”. === &lt;br /&gt;
&lt;br /&gt;
In the following conversation, the two collectives H&amp;amp;D and Varia discuss and trace the distributed process of building and working with web-based open-source publishing tools and workflows that are referred to as Wiki-to-print, Wiki2print or Wiki-to-pdf. While prevailing monocultures of design software created conditions in which it is difficult to imagine publishing processes otherwise, the wiki-to-print experiments discussed here propose other possible socio-technical scenarios for designing and working together that are not merely utilitarian or solution-driven. Such tools nourish attitudes that challenge linearity, efficiency, and a progress-based understanding of a design process.&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) We are curious about the genealogy of Wiki-to-pdf/print as it is used for collective publishing. Can you recollect what brought you to this workflow? What precisely sparked your curiosity and kept you interested in working with the MediaWiki infrastructure to edit and design publications?&lt;br /&gt;
&lt;br /&gt;
(Varia) We were introduced to Wikis and the MediaWiki software in particular during our studies, at what is now called the Experimental Publishing Master at the Piet Zwart Institute. That wiki has been used since 2006 and is still used today by the students and staff to document projects, classes and How-to’s, as a shared calendar or place to prepare thesis drafts with tutors. The sociality of the wiki appears when it is part of the daily infrastructure and when it&#039;s used so intensively. The RecentChanges page, for example, has become a place where you can find out what other people have recently been working on. Hooking such social dynamics into a print workflow creates a lot of exciting possibilities when you think about it. &lt;br /&gt;
&lt;br /&gt;
Working with a &amp;quot;fresh&amp;quot; Wiki for making a book is quite different, but not less exciting. Using a Wiki in an editorial workflow is quite charming because it turns such workflow into a collective environment where everyone can follow the development of the content without imposing predefined article structures. A wiki page is &amp;quot;just&amp;quot; a page. The form and format are open. It&#039;s very different from, for example, a WordPress article, where the structure is predefined and cut up into smaller pieces (title, subtitle perhaps, author name, introduction, main text, etc). The attitude of the wiki software, to not impose a structure or format upon you, creates an interesting shift from technical protocols towards social protocols. What we mean by social protocols, is that decisions need to be made together, between people, not through a predefined technical configuration.&lt;br /&gt;
&lt;br /&gt;
This way of making publications is part of a bigger landscape of collective working environments, tools, habits and types of publications. This shift, from assembling a publication using a graphic user interface to compiling a publication through code, is super exciting to us. In our view, the biggest impact this software has is that it allows for a non-linear way of working: it makes the workflow much more continuous, and the design and editing are done in parallel. Of course, a deadline is unavoidable when working on printed matter. At some point, you need to stop editing. But this deadline is much softer compared to linear workflows where designers need to wait for the final version of the content before the design process can start. You can just make adjustments to the document style in CSS declarations, which are rendered each time you refresh the page. But they don&#039;t influence the content, which can keep changing.&lt;br /&gt;
&lt;br /&gt;
Working with Wiki software specifically is a small subsection of this landscape. There are many projects that worked with wikis for printed matter. Taking part in such a continuous timeline is super interesting to us! In 2017, Sandra Fauconnier, Cristina Cochior and Juan Gomez worked on [the potential of e-books based on Wikimedia content] (https://web.archive.org/web/20171016013843/http://www.publishinglab.nl/wiki-ebook/2017/01/27/wrapping-up-the-wiki-research/) during an INC research project at the PublishingLaband. Also, the Wikimedia Foundation has worked with [a range of different tools] (https://www.mediawiki.org/wiki/PDF_export) to add print support to the MediaWiki software and Wikipedia in particular. We had to dig a bit to find that link to PublishingLab, which thanks to the WayBack Machine, still exists online.&lt;br /&gt;
&lt;br /&gt;
This reminds us of the importance of documentation for maintaining links between the trail of wiki printing projects that has been growing in multiple directions in the last years. Code has been reused between different groups, ideas and approaches have been versioned over time, and a range of different kinds of printed publications have been based on Wiki workflows: newspapers, printed books, digital PDF files and web pages. This Wiki-to-print direction introduces Flask to dynamically connect the writing of the content and the rendering of the PDF. It is a side branch of the longer wiki printing timeline and operates in a more specific art/design context around the Netherlands and Belgium so far, but hopefully, it will continue travelling, morphing and transforming. Some projects on this trail include the following ones, but there are probably more.&lt;br /&gt;
&lt;br /&gt;
- André Castro and Alexia de Visscher&#039;s work on Mondotheque with Constant:&lt;br /&gt;
https://www.mondotheque.be/&lt;br /&gt;
https://books.constantvzw.org/home/mondotheque&lt;br /&gt;
- OSP&#039;s work on DiVersions with Constant:&lt;br /&gt;
https://diversions.constantvzw.org/&lt;br /&gt;
https://books.constantvzw.org/home/diversions-v2&lt;br /&gt;
- Manetta Berends&#039; work on Volumetric Regimes with Possible Bodies, published by Open Humanities Press in the Data Browser series: &lt;br /&gt;
https://volumetricregimes.xyz/&lt;br /&gt;
http://www.data-browser.net/db08.html&lt;br /&gt;
- Martino Morandi&#039;s work on Wiki-to-pdf with TITiPI:&lt;br /&gt;
https://titipi.org/wiki/index.php/Wiki-to-pdf&lt;br /&gt;
https://titipi.org/wiki-to-pdf/pagedjs/Infrastructural_Interactions&lt;br /&gt;
- Hackers &amp;amp; Designer&#039;s work on Making Matters:&lt;br /&gt;
https://hackersanddesigners.nl/s/Publishing/p/Making_Matters._A_Vocabulary_of_Collective_Arts&lt;br /&gt;
https://wiki2print.hackersanddesigners.nl/wiki/Publishing:Making_Matters_Lexicon&lt;br /&gt;
- Varia&#039;s work on Toward a Minor Tech with APRJA:&lt;br /&gt;
https://darc.au.dk/publications/peer-reviewed-newspaper&lt;br /&gt;
https://varia.zone/en/toward-a-minor-tech.html&lt;br /&gt;
https://cc.vvvvvvaria.org/wiki/Wiki-to-print&lt;br /&gt;
&lt;br /&gt;
(Varia) We are curious how you experienced being part of this trail. And how did it feel to see your code being reused again?&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) It took some time before understanding the different pathways of this trail, how code has been forked, continued in different contexts, and developed in different directions. This process is ongoing, constantly evolving, so it&#039;s perhaps impossible to fully comprehend. There is a slowness to this process as well, and a (dispersed) collective effort, which is quite interesting. There are no feature requests or an agreement amongst these different groups and repositories for instance about predetermined outcomes. Through this slowness and also fragmentation, these tools can be questioned conceptually, technically, ethically and not necessarily conclusively ... readjusting general perceptions of what is inevitable and what is useful in conceptualizing and actualizing tools.&lt;br /&gt;
It seems it is a non-linear and somewhat unpredictable trail that has evolved over the years, that has more and less active moments. &lt;br /&gt;
H&amp;amp;D has also worked with wikis for a long time already, i.e. as a cms to our website (https://hackersanddesigners.nl/s/Publishing/p/The_making_of_hackersanddesigners.nl), which is a central place for writing and editing workshop manuals, announcements, workshop and project documentation. André Castro joined a H&amp;amp;D meetup a long time ago (maybe in 2015) and introduced us to some Wiki stuff. Similarly to what you described in the context of XPUB, Wikis became an integral part of H&amp;amp;D&#039;s collective infrastructure and ways of organizing ourselves. The Wikis are intertwined with the ways the group works together, and is also reflected in the shared excitement about working with wiki as a publishing infrastructure, that allows us to collapse processes of writing, editing, designing, and archiving. &lt;br /&gt;
&lt;br /&gt;
We made a publication in 2015 using Wiki and LaTeX https://hackersanddesigners.nl/s/Publishing/p/HDSA2015-documentation, and in 2016 we made one using Wiki and Scribus https://hackersanddesigners.nl/s/Publishing/p/HDSA2016-documentation &amp;lt;!--[super nice!]--&amp;gt; &lt;br /&gt;
&lt;br /&gt;
(Varia) What triggered the shift from LaTeX and Scribus to Wiki2print?&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) It was exciting to see a layout produced more or less instantly. And it looked pretty good! Yet, the learning curve of LaTeX was quite steep. Coming from graphic design and being used to somewhat &#039;intuitive&#039; ways of working with layout software, that is, being able to &#039;see&#039; different versions of a layout very quickly, the process and outcome of using LaTex seemed rather stiff in comparison. It also seemed that LaTeX is very good at certain things – i.e. making a layout look very &#039;proper&#039; but not so good at making exciting unexpected interventions. The wiki-scribus combination was much more flexible. We basically just used the wiki to edit and structure the publication collaboratively and eventually exported and used Pandoc to convert the wiki syntax to something we could import and use in Scribus. While we could simultaneously edit in the wiki and easily update the Scribus file with the new content without losing the styling we had done, there was still this break between writing/assembling of the content on the one hand and styling it on the other. &lt;br /&gt;
&lt;br /&gt;
(Varia) What triggered the shift from LaTeX and Scribus to wiki2print?&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) It took us a while to move towards wiki2print. There were various other convulsed publishing experiments in between, like heart-beat to print, and the PJ Machine from Sara Garcin. &lt;br /&gt;
&lt;br /&gt;
What is interesting about wiki2print is indeed the workflow that is so different to what one is used to. As you mentioned before, the separations of different tasks, that are often embodied by different people inhabit (designer, writer, coder, copy editor...) are not so separate anymore. As a designer for instance you make different kinds of choices if you they are also involved in all other layers of a publishing process. It may seem that less is possible in this workflow, for example in comparison to the inDesign experience... you have less control or agency over the outcome. But you could also question the so-called agency given by certain tools, – the illusion of mastery they emanate. &lt;br /&gt;
&lt;br /&gt;
Wendy Hui Kyong Chun wrote about this in her text on Daemonic Interfaces (Programmed Visions: Software and Memory). The so-called intuitive user experiences, dragging and dropping moves the tool to the background. One thinks about it less if one feels in control. You don&#039;t question it anymore, it enters your subconscious... in this way, tools like indesign also become &#039;inevitable. In this way, intuitive software also become unchallenged and inevitable. Working with wiki2print is quite edgy in comparison. The limits are very present... maybe something to hold on to, not to overcome?  &lt;br /&gt;
&lt;br /&gt;
Anyhow, in 2022 we worked on the [Making Matters](add link) publication for which we looked at the repository of Manetta for [Volumetric Regimes for Possible Bodies](add link) and Martino for [TITiPI](add link). It was super helpful to see some exciting examples and build upon what is already there. By doing so, also a feeling of response-ability evolved, to make the trail legible somehow. The writing of the colophon became an important part of making that trail more visible to ourselves and others. We added an elaborate [&#039;Note about the design of the publication&#039;](add link) in which we acknowledged the work that has already been done, and mention other relevant projects and practices that inspire us. We felt so excited to read the colophon of Minor Tech and seeing the trail grow and taking part in it.&lt;br /&gt;
&lt;br /&gt;
As you mentioned before, part of continuing that trail is also making sure projects are well documented so that someone else can understand and reuse it. We also like the idea of contributing to the larger collective effort of improving these forms of publishing. For instance we heard about a small issue, that we felt we could perhaps pay attention to in our next publication [First, then... repeat]. Wiki has a very useful feature to upload new versions of files. Yet, in the Paged.js preview the new version was not updating. In Making Matters we found a convoluted workaround by renaming every new file version and changing the image tag in the article. We now added an &amp;quot;overwrite images&amp;quot; check box https://wiki2print.hackersanddesigners.nl/ which replaces the image with the last uploaded version. &lt;br /&gt;
&lt;br /&gt;
(Varia) Super nice to see that feature! Maybe related to the new image versions issue... We also ran into the issue that MediaWiki works with a job queue, which means that edits are held back and spread over time to make sure that the server is not overloaded. We are working around this by running the `runJobs.php` maintenance script that is shipped with the MediaWiki software, which works, but it is still a bit of a stretch.&lt;br /&gt;
&lt;br /&gt;
Speaking of features, it is nice to see custom Paged.js features appearing in other projects. Amélie Dumont is currently working on a website and book for which they work with a Javascript function to &amp;quot;keep&amp;quot; your scroll after a refresh. OMG Yes! Which is such a super useful feature to have when working on a book with many pages!&lt;br /&gt;
&lt;br /&gt;
It is nice to be reminded of the https://wiki2print.hackersanddesigners.nl/ link btw and to see the index page that you and also Martino started to work with. We decided to step away from it and integrated the index and update button(s) inside the wiki, which are two update buttons in our case: one for the text and one for the more heavier updates of media. In that way, we don&#039;t need to switch between the wiki interface and the Flask one, which felt like an interesting step towards staying within one shared environment both for writing and layout making. That is also why we totally forgot about this page actually. The page is technically still there in the version of wiki-to-print that is installed on the CC server, but it has no specific function anymore, apart from reminding us that we clicked an update button on the wiki, because it opens all the time after such click, which is probably something we could work around, but well...&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) It seems we have developed ways working on publications that are quite flexible and sometimes come with contingent and surprising outcomes. What is enjoyable about this way of working is that content production and design of publications can emerge on the go and in response to different collective conditions (i.e. different timelines, dispersed geographies, janky infrastructure). In the context of the Making Matters publication this somewhat unforeseeable collective process that we usually cherished, became quite challenging and somewhat incompatible with the material realities and ways of working of a publisher. You mentioned the softness of boundaries between designing, writing and editing. These soft boundaries can also become a bit scary when working on a publication with many pages, a large edition, involving high production costs. When changes in the beginning of the document can still affect something in the middle – potentially without us noticing. &lt;br /&gt;
There are many more tensions that can be experienced when it comes to designing for print in the browser. For instance, preparing and uploading images in high resolution seems counter intuitive in the context of web and network technologies. What are other tensions that come to mind and how do you negotiate those? Are there printing techniques that can be regarded as more compatible with wiki-to-print workflows than others? &lt;br /&gt;
&lt;br /&gt;
(varia) Editing wiki pages in order to change how a page will look on paper feels very counter-intuitive, as well. And sometimes you forget about things that are elementary to the web, like animated GIFs. In the browser of course, you can use animated GIFs. However, before exporting PDFs we had to remove the GIFs from wiki pages, to have control over which frame would appear in print. Of course you can undo these edits after exporting and still have the GIFs on the wiki, but it still feels counter-intuitive. [It can be fun to add animations to add some purposeful contingency into a layout too. see https://chatty-pub.hackersanddesigners.nl/Scriptothek#ch-infrables :-)]&lt;br /&gt;
&lt;br /&gt;
Another important bottleneck in the wiki-to-print workflow is image placement. When we approach a page as a &amp;quot;canvas&amp;quot;: with fixed margins, columns and font size, then the positioning of images is a very painful part of the process. The placement of an image depends on its position in the flow of the text. But of course, when you place an image on a wiki page, you have no idea where it ends up on a printed page! CSS Regions was initially introduced to work around this as it allows you to position the images and let text flow around them on a page. But unfortunately CSS Regions are not supported anymore by current browsers. There are different attitudes when designing for print, or for web, and implications that come from diverging established workflows. To give every image the same fixed width seems quite brutal in print, even though it may be desirable on the web, or vice versa. But the effects of resizing images one-by-one can easily cascade and you have to think about what else is affected on following pages.&lt;br /&gt;
&lt;br /&gt;
There is also the question of design cultures and ways of thinking that come from specific software. Shifting away from tools that are based on 500+ years of book design traditions toward web environments that are based on network technologies has many implications. One thing we noticed is that there has to be an adjustment in how much time and attention is given to producing a PDF for print. The instantaneousness of the web affects understandings of how ready the PDF is for printing, or how PDF documents are build at all. The PDF may still need to be converted into CYMK colorspace, distilled for a particular PDF format or have imposition applied before it is sent to a printer. Even though you can see it rendered in a browser window immediately the print preview is a sort of illusion. You are not really looking at the final version of the PDF at all, a lot of steps need to be taken afterwards to match industrial printing standards. &lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) What processes do your pdfs undergo &#039;afterwards&#039; to match printing standards?&lt;br /&gt;
&lt;br /&gt;
(varia) The Volumetric Regimes book is produced on-demand and needed to be submitted in a PDF/X-3:2002 format, which is not the format that browsers provide by default. It was quite a search to find a way to turn a PDF into that format, and in the end LaTeX was the way out here. Another big surprise that appeared during the making of the Volumetric Regimes book was the disappearance of the emoji face on [the cover](https://volumetricregimes.xyz/index.php?title=File:VRcover.png). We wanted to overprint this black emoji over the blue background gradient, which we managed to do with Ghostscript and [OSP&#039;s PDF-utils repository](https://gitlab.constantvzw.org/osp/tools.pdfutils). The PDF looked fine, the preflight software displayed the cover fine, so we were relieved! What we did not expect though, is to receive a box of books without the author names. They disappeared! The overprinting feature was applied to all elements on the cover, including the white text. Thanks to more help of the OSPs, we figured out that we can use Scribus to open the cover PDF and apply overprint only to a particular layer of the PDF. It was such a struggle!&lt;br /&gt;
&lt;br /&gt;
The Minor Tech newspaper didn&#039;t require such conversion, because we could talk with the people at Tripiti directly, who printed the newspaper for us. In that case we only converted the PDF into a grayscale colorspace, to make sure that the whole PDF was rendered in one color, which we needed because the newspaper was printed in offset with a spot colour. One thing that is not necessarily an &#039;afterwards&#039; process, but an important one, is browser choice. We worked using Mozilla Firefox for the Minor Tech newspaper up until realizing (just after midnight) that images were all in very low resolution when we pressed ctrl+P, so we had to switch to Chrome to make the final PDF. Even then, Chrome rendered the PDF slightly differently and we had to make some adjustments. These are things you hardly think about until right at the end of a design process. Luckily we caught this in time!&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) We loved reading your article about disappearing / eaten sentences: https://cc.vvvvvvaria.org/wiki/Octolog) and the hacks people invent to work around these issues, &amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt; :-))) &lt;br /&gt;
Karl brought back the Minor Tech newspaper from Transmediale. We were looking at it and were particularly impressed by the column layout! We have experienced a lot of issues with disappearing text in columns in the (printed) [First, Then... Repeat](link) publication. We felt a bit haunted by it and had agreed to NEVER use columns again! As you have experienced too text kept disappearing in the pdf, while in the browser it would still be visible! &lt;br /&gt;
&lt;br /&gt;
(Varia) Yes the disappearing sentences, oof, they were so painful. What really helped was that we were being able to reach out to Paged.js through their Mattermost chat. Julien Taquet works on Paged.js and is super present on the chat. It was through him that we could start to understand what the cause of this issue is, which was helpful and partially released some stress. But it did not solve the issue straight away, as it is a very sensitive one with close ties to the lower processing levels of Paged.js. So in the end we forced a page break on a very specific position in the text, which is a very scary thing to do, because it means that nothing else in the article can be changed anymore, not even a letter, to make sure that you don&#039;t end up with big gaps in the text. &lt;br /&gt;
&lt;br /&gt;
(varia) To come back to other tensions, those related to collective processes, we would be curious to hear more about the challenges that you encountered during the Making Matters production? What kind of changes were made in the last moment? How did this have an impact on the layout?&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) A challenging element was to converge – on the one hand the expectations to make something that reflects collective experimentation, which the book spoke about in its content and on the other hand negotiate the pretty much non-negotiable linear workflow of academic publishing, very tight deadlines, and many contributors and editors that don&#039;t know each other, are dispersed and hard to reach. A more fluent reciprocal process in this context didn&#039;t seem feasible. The notion of &amp;quot;experimentation&amp;quot; as well as &amp;quot;collective&amp;quot; were taken for granted as something inherently productive, as something that leads with certainty towards results – that can be predicated and measured by the same standards and criteria as any other book. While we were interested in and open about challenging the arbitrary boundaries of what is considered professional book design and what is not there were moments our &amp;quot;expertise&amp;quot; was questioned as designers. &lt;br /&gt;
By choosing this path we had ourselves already decided that micro-typography may not be our biggest priority. Instead we could pay attention to other exciting things. For instance the publication accommodates non-linear reading, which is something that the flat structure of a wiki inspired us to do. Cross-references are indicated with  different kinds of arrows, referring to one of the seven chapter themes. The arrows occur on the chapter introduction pages, next to the respective terms, as well as in the side bar navigation of the respective chapter categories. This allows the reader to quickly sift through the book and find terms in different contexts. In addition, elements in the side bar navigation subtly poke out when indicating the occurrence of a term in the text. We also worked with different colors per chapter and a subtle gradient that changes throughout the whole book to indicate that terms do not &#039;belong&#039; solely in one place but that their place is ambiguous and theory meanings spill over. The latter caused quite some pain in the pre-press process. The generated PDF had so many strange hidden elements and layers in it, that apparently showed up in the pre-press and caused a lot of troubles producing the gradient. We were not in contact with the printer directly, which made this whole pre-press process even harder. &lt;br /&gt;
&lt;br /&gt;
Making Matters was our first wiki-to-print attempt. Entering a rather large project with a publishing infrastructure that was quite new to us was exciting at first but also quite risky and stressful as there were so many moving variables. &lt;br /&gt;
&lt;br /&gt;
We had to present a pretty fixed design proposal at the beginning of the process, which we then worked towards. In a way we made a promise without knowing what is possible. On the one hand it was helpful to have a goal – something to hold on to. But it was also stressful because of unexpected quirks and impossibilities. Honestly, we did it because there was a budget for once, which gave us the possibility to finally dive into this workflow. Eventually we worked at least double of what we were paid. &lt;br /&gt;
&lt;br /&gt;
After that publication we&#039;ve been moving more and more towards a CSS editing process in the wiki CSS panel. That way, editing and styling become part of the same workflow, which also facilitates a more flexible approach to the design of the publication. &lt;br /&gt;
&lt;br /&gt;
(Varia) How did you do it before having the CSS in the wiki CSS panel? It seems to have had a big shift to work within the wiki all together.&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) The Making Matters book needed to be laid out on a baseline grid, which proved to be challenging in CSS. We used a more traditional web development approach for the styling using Sass and a library called Plumber that made it possible to have a baseline grid in CSS. Web fonts don&#039;t always have a consistent baseline so you need to account for that for each font using positive and negative margins. Also images needed to be scaled so that they conform to the grid vertically. Headaches! This meant that editing content and applying styles were not integrated into a unified workflow regrettably. On the other hand, since the project was so CSS heavy it made sense to work on it in a more &#039;user-friendly&#039; environment. There were so many small interventions! As mentioned before, the book is structured like a dictionary and each time there is a keyword in the text the illustration in the margin reacts to that, creating a little animation when you flip through the book. We used P5js with a SVG renderer for that so that the illustrations were usable in print. In the end we made a little front-end in the PDF view where we can play with some of the settings, change the version of the script, toggle a view of the baseline grid, separate layers for printing. It was a fun challenge but since then we have moved more and more to a single workflow, and also simpler layouts. Only the fonts are hardcoded and all other styling done in the wiki. It makes for a more collaborative workflow. &lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) We are curious, how to organize collective workflows around a wiki-to-print project? i.e. How many people should be involved in the workflow? How are tasks divided? Are you working in the same space or distributed/remotely? What are appropriate timelines and budgets?&lt;br /&gt;
&lt;br /&gt;
(varia) Regarding the soft deadlines, we noticed that working closely between editors and designers is really needed to make it happen. It is also important to have a shared understanding of the limitations and possibilities of wiki software, to find ways to think along with the workflow instead of going against the grain. This needs time for conversation and reflection and it is always a bit of a struggle. It&#039;s something that we are still figuring out.&lt;br /&gt;
&lt;br /&gt;
We have different experiences regarding the columns and collective conditions shaped by the workflow that also depend on the publication&#039;s content, conditions, collectivity and design choices. With Varia&#039;s occasional printed newsletter SomeTimes we were used to using columns in Octomode (a way of making PDFs from Etherpads), where all you have to worry about usually is how content flows from one column to another. [To give an idea, this is the PDF of SomeTimes, Issue 1, made in Octomode](https://varia.zone/documents/SomeTimes_number-1.pdf). The content of SomeTimes is made collectively from RSS feeds, particular hashtags on Mastodon, and posts gathered by a logbot. We have made a couple issues of it by now, and the simple design works, so we don&#039;t need to change it much. The budget is low, we produce it on A3 on a laser printer in our space in Rotterdam. Also the timelines are always short because we&#039;re already in the middle of so many other projects while working on it. In the making of this RSS workflow, we took these conditions as starting points for the design and development process.&lt;br /&gt;
&lt;br /&gt;
On the other hand, the Minor Tech newspaper was made using wiki-to-print and CSS grid during a two-day publication sprint between two people in Rotterdam and a large group that were writing and editing articles at a workshop in London. We were new to using CSS grid for paged media, and it took quite some tetris-ing to work within the constraints of the grid and a pre-determined page count. We spent a few hours before the sprint puzzling how different articles could fit, sketching in Octomode and on paper.&lt;br /&gt;
&lt;br /&gt;
![Aerial view of Varia working at our laptops in Rotterdam](https://vvvvvvaria.org/logs/toward-a-minor-tech/image/I1RSpI0hT_63HJ1giGW0Mw.jpg) &lt;br /&gt;
![Tetris-ing in Octomode](https://vvvvvvaria.org/logs/toward-a-minor-tech/image/Screenshot_from_2023-01-18_16-52-54.png) &lt;br /&gt;
![Tetris-ing on paper before the sprint](https://vvvvvvaria.org/logs/toward-a-minor-tech/image/U4vxHcdaQp-taZc_98-28Q.jpg)&lt;br /&gt;
&lt;br /&gt;
From the beginning, we had to accept the constraints of working within a rigid grid where it is impossible to flow articles from one page to another. It worked out in the case of the Minor Tech newspaper, as the texts were written with a maximum amount of 500 words. We ended up with a lot of small empty spaces though. We asked the writers for &amp;quot;cellular contributions&amp;quot; – content that would fit within the spaces of the newspaper that were left empty after our tetris-ing. The proposal for cellular contributions resulted in super nice quotes, pictures, and cute advertisements. &lt;br /&gt;
&lt;br /&gt;
![A quote included in the &amp;quot;cellular contributions&amp;quot; of the Toward a Minor Tech newspaper](https://varia.zone/archive/2023-01-Toward-a-Minor-Tech/toward-a-minor-tech-04.jpg)&lt;br /&gt;
&lt;br /&gt;
In this way, the shortcomings of working towards particular formats and scenarios, such as the typically heavy content density of a newspaper or a two-day collective production sprint, became a springboard into more experimental solutions and giving flexibility to the content and layout. This came from our choice to use CSS grid and also the availability of our collaborators during this sprint. But each publication workflow varies, and calls for different approaches. The use of CSS grid had a nice side effect, but the remote way of working during the sprint did not really help to let the production of content and layout overlap and intertwine. We would do this differently next time and prioritize being together in the same space to make sure we are in conversation with each other.&lt;br /&gt;
&lt;br /&gt;
... read the continuation of this conversation in the next bulletin&lt;/div&gt;</summary>
		<author><name>Slvie</name></author>
	</entry>
	<entry>
		<id>https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Creative_Crowd&amp;diff=6038</id>
		<title>Creative Crowd</title>
		<link rel="alternate" type="text/html" href="https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Creative_Crowd&amp;diff=6038"/>
		<updated>2023-07-14T07:27:24Z</updated>

		<summary type="html">&lt;p&gt;Slvie: basic editing grammer and punctuation&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Wiki-to-print/Wiki2print/Wiki-to-pdf, and so on... ==&lt;br /&gt;
=== An (ongoing) exchange between Hackers &amp;amp; Designers and Varia about “publishing along the trails”. === &lt;br /&gt;
&lt;br /&gt;
In the following conversation, the two collectives H&amp;amp;D and Varia discuss and trace the distributed process of building and working with web-based open-source publishing tools and workflows that are referred to as Wiki-to-print, Wiki2print or Wiki-to-pdf. While prevailing monocultures of design software created conditions in which it is difficult to imagine publishing processes otherwise, the wiki-to-print experiments discussed here propose other possible socio-technical scenarios for designing and working together that are not merely utilitarian or solution-driven. Such tools nourish attitudes that challenge linearity, efficiency, and a progress-based understanding of a design process.&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) We are curious about the genealogy of Wiki-to-pdf/print as it is used for collective publishing. Can you recollect what brought you to this workflow? What precisely sparked your curiosity and kept you interested in working with the MediaWiki infrastructure to edit and design publications?&lt;br /&gt;
&lt;br /&gt;
(Varia) We were introduced to Wikis and the MediaWiki software in particular during our studies, at what is now called the Experimental Publishing Master at the Piet Zwart Institute. That wiki has been used since 2006 and is still used today by the students and staff to document projects, classes and How-to’s, as a shared calendar or place to prepare thesis drafts with tutors. The sociality of the wiki appears when it is part of the daily infrastructure and when it&#039;s used so intensively. The RecentChanges page, for example, has become a place where you can find out what other people have recently been working on. Hooking such social dynamics into a print workflow creates a lot of exciting possibilities when you think about it. &lt;br /&gt;
&lt;br /&gt;
Working with a &amp;quot;fresh&amp;quot; Wiki for making a book is quite different, but not less exciting. Using a Wiki in an editorial workflow is quite charming because it turns such workflow into a collective environment where everyone can follow the development of the content without imposing predefined article structures. A wiki page is &amp;quot;just&amp;quot; a page. The form and format are open. It&#039;s very different from, for example, a WordPress article, where the structure is predefined and cut up into smaller pieces (title, subtitle perhaps, author name, introduction, main text, etc). The attitude of the wiki software, to not impose a structure or format upon you, creates an interesting shift from technical protocols towards social protocols. What we mean by social protocols, is that decisions need to be made together, between people, not through a predefined technical configuration.&lt;br /&gt;
&lt;br /&gt;
This way of making publications is part of a bigger landscape of collective working environments, tools, habits and types of publications. This shift, from assembling a publication using a graphic user interface to compiling a publication through code, is super exciting to us. In our view, the biggest impact this software has is that it allows for a non-linear way of working: it makes the workflow much more continuous, and the design and editing are done in parallel. Of course, a deadline is unavoidable when working on printed matter. At some point, you need to stop editing. But this deadline is much softer compared to linear workflows where designers need to wait for the final version of the content before the design process can start. You can just make adjustments to the document style in CSS declarations, which are rendered each time you refresh the page. But they don&#039;t influence the content, which can keep changing.&lt;br /&gt;
&lt;br /&gt;
Working with Wiki software specifically is a small subsection of this landscape. There are many projects that worked with wikis for printed matter. Taking part in such a continuous timeline is super interesting to us! In 2017, Sandra Fauconnier, Cristina Cochior and Juan Gomez worked on [the potential of e-books based on Wikimedia content] (https://web.archive.org/web/20171016013843/http://www.publishinglab.nl/wiki-ebook/2017/01/27/wrapping-up-the-wiki-research/) during an INC research project at the PublishingLaband. Also, the Wikimedia Foundation has worked with [a range of different tools] (https://www.mediawiki.org/wiki/PDF_export) to add print support to the MediaWiki software and Wikipedia in particular. We had to dig a bit to find that link to PublishingLab, which thanks to the WayBack Machine, still exists online.&lt;br /&gt;
&lt;br /&gt;
This reminds us of the importance of documentation for maintaining links between the trail of wiki printing projects that has been growing in multiple directions in the last years. Code has been reused between different groups, ideas and approaches have been versioned over time, and a range of different kinds of printed publications have been based on Wiki workflows: newspapers, printed books, digital PDF files and web pages. This Wiki-to-print direction introduces Flask to dynamically connect the writing of the content and the rendering of the PDF. It is a side branch of the longer wiki printing timeline and operates in a more specific art/design context around the Netherlands and Belgium so far, but hopefully, it will continue travelling, morphing and transforming. Some projects on this trail include the following ones, but there are probably more.&lt;br /&gt;
&lt;br /&gt;
- André Castro and Alexia de Visscher&#039;s work on Mondotheque with Constant:&lt;br /&gt;
https://www.mondotheque.be/&lt;br /&gt;
https://books.constantvzw.org/home/mondotheque&lt;br /&gt;
- OSP&#039;s work on DiVersions with Constant:&lt;br /&gt;
https://diversions.constantvzw.org/&lt;br /&gt;
https://books.constantvzw.org/home/diversions-v2&lt;br /&gt;
- Manetta Berends&#039; work on Volumetric Regimes with Possible Bodies, published by Open Humanities Press in the Data Browser series: &lt;br /&gt;
https://volumetricregimes.xyz/&lt;br /&gt;
http://www.data-browser.net/db08.html&lt;br /&gt;
- Martino Morandi&#039;s work on Wiki-to-pdf with TITiPI:&lt;br /&gt;
https://titipi.org/wiki/index.php/Wiki-to-pdf&lt;br /&gt;
https://titipi.org/wiki-to-pdf/pagedjs/Infrastructural_Interactions&lt;br /&gt;
- Hackers &amp;amp; Designer&#039;s work on Making Matters:&lt;br /&gt;
https://hackersanddesigners.nl/s/Publishing/p/Making_Matters._A_Vocabulary_of_Collective_Arts&lt;br /&gt;
https://wiki2print.hackersanddesigners.nl/wiki/Publishing:Making_Matters_Lexicon&lt;br /&gt;
- Varia&#039;s work on Toward a Minor Tech with APRJA:&lt;br /&gt;
https://darc.au.dk/publications/peer-reviewed-newspaper&lt;br /&gt;
https://varia.zone/en/toward-a-minor-tech.html&lt;br /&gt;
https://cc.vvvvvvaria.org/wiki/Wiki-to-print&lt;br /&gt;
&lt;br /&gt;
(Varia) We are curious how you experienced being part of this trail. And how did it feel to see your code being reused again?&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) It took some time before understanding the different pathways of this trail, how code has been forked, continued in different contexts, and developed in different directions. This process is ongoing, constantly evolving, so it&#039;s perhaps impossible to fully comprehend. There is a slowness to this process as well, and a (dispersed) collective effort, which is quite interesting. There are no feature requests or an agreement amongst these different groups and repositories for instance about predetermined outcomes. Through this slowness and also fragmentation, these tools can be questioned conceptually, technically, ethically and not necessarily conclusively ... readjusting general perceptions of what is inevitable and what is useful in conceptualizing and actualizing tools.&lt;br /&gt;
It seems it is a non-linear and somewhat unpredictable trail that has evolved over the years, that has more and less active moments. &lt;br /&gt;
H&amp;amp;D has also worked with wikis for a long time already, i.e. as a cms to our website (https://hackersanddesigners.nl/s/Publishing/p/The_making_of_hackersanddesigners.nl), which is a central place for writing and editing workshop manuals, announcements, workshop and project documentation. André Castro joined a H&amp;amp;D meetup a long time ago (maybe in 2015) and introduced us to some Wiki stuff. Similarly to what you described in the context of XPUB, Wikis became an integral part of H&amp;amp;D&#039;s collective infrastructure and ways of organizing ourselves. The Wikis are intertwined with the ways the group works together, and is also reflected in the shared excitement about working with wiki as a publishing infrastructure, that allows us to collapse processes of writing, editing, designing, and archiving. &lt;br /&gt;
&lt;br /&gt;
We made a publication in 2015 using Wiki and LaTeX https://hackersanddesigners.nl/s/Publishing/p/HDSA2015-documentation, and in 2016 we made one using Wiki and Scribus https://hackersanddesigners.nl/s/Publishing/p/HDSA2016-documentation &amp;lt;!--[super nice!]--&amp;gt; &lt;br /&gt;
&lt;br /&gt;
(Varia) What triggered the shift from LaTeX and Scribus to Wiki2print?&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) It was exciting to see a layout produced more or less instantly. And it looked pretty good! Yet, the learning curve of LaTeX was quite steep. Coming from graphic design and being used to somewhat &#039;intuitive&#039; ways of working with layout software, that is, being able to &#039;see&#039; different versions of a layout very quickly, the process and outcome of using LaTex seemed rather stiff in comparison. It also seemed that LaTeX is very good at certain things – i.e. making a layout look very &#039;proper&#039; but not so good at making exciting unexpected interventions. The wiki-scribus combination was much more flexible. We basically just used the wiki to edit and structure the publication collaboratively and eventually exported and used Pandoc to convert the wiki syntax to something we could import and use in Scribus. While we could simultaneously edit in the wiki and easily update the Scribus file with the new content without losing the styling we had done, there was still this break between writing/assembling of the content on the one hand and styling it on the other. &lt;br /&gt;
&lt;br /&gt;
What triggered the shift from LaTeX and Scribus to wiki2print?&lt;br /&gt;
&lt;br /&gt;
It took us a while to move towards wiki2print. There were various other convulsed publishing experiments in between, like heart-beat to print, and the PJ Machine from Sara Garcin. &lt;br /&gt;
&lt;br /&gt;
What is interesting about wiki2print is indeed the workflow that is so different to what one is used to. As you mentioned before, the separations of different tasks, that are often embodied by different people inhabit (designer, writer, coder, copy editor...) are not so separate anymore. As a designer for instance you make different kinds of choices if you they are also involved in all other layers of a publishing process. It may seem that less is possible in this workflow, for example in comparison to the inDesign experience... you have less control or agency over the outcome. But you could also question the so-called agency given by certain tools, – the illusion of mastery they emanate. &lt;br /&gt;
&lt;br /&gt;
Wendy Hui Kyong Chun wrote about this in her text on Daemonic Interfaces (Programmed Visions: Software and Memory). The so-called intuitive user experiences, dragging and dropping moves the tool to the background. One thinks about it less if one feels in control. You don&#039;t question it anymore, it enters your subconscious... in this way, tools like indesign also become &#039;inevitable. In this way, intuitive software also become unchallenged and inevitable. Working with wiki2print is quite edgy in comparison. The limits are very present... maybe something to hold on to, not to overcome?  &lt;br /&gt;
&lt;br /&gt;
Anyhow, in 2022 we worked on the [Making Matters](add link) publication for which we looked at the repository of Manetta for [Volumetric Regimes for Possible Bodies](add link) and Martino for [TITiPI](add link). It was super helpful to see some exciting examples and build upon what is already there. By doing so, also a feeling of response-ability evolved, to make the trail legible somehow. The writing of the colophon became an important part of making that trail more visible to ourselves and others. We added an elaborate [&#039;Note about the design of the publication&#039;](add link) in which we acknowledged the work that has already been done, and mention other relevant projects and practices that inspire us. We felt so excited to read the colophon of Minor Tech and seeing the trail grow and taking part in it.&lt;br /&gt;
&lt;br /&gt;
As you mentioned before, part of continuing that trail is also making sure projects are well documented so that someone else can understand and reuse it. We also like the idea of contributing to the larger collective effort of improving these forms of publishing. For instance we heard about a small issue, that we felt we could perhaps pay attention to in our next publication [First, then... repeat]. Wiki has a very useful feature to upload new versions of files. Yet, in the Paged.js preview the new version was not updating. In Making Matters we found a convoluted workaround by renaming every new file version and changing the image tag in the article. We now added an &amp;quot;overwrite images&amp;quot; check box https://wiki2print.hackersanddesigners.nl/ which replaces the image with the last uploaded version. &lt;br /&gt;
&lt;br /&gt;
(Varia) Super nice to see that feature! Maybe related to the new image versions issue... We also ran into the issue that MediaWiki works with a job queue, which means that edits are held back and spread over time to make sure that the server is not overloaded. We are working around this by running the `runJobs.php` maintenance script that is shipped with the MediaWiki software, which works, but it is still a bit of a stretch.&lt;br /&gt;
&lt;br /&gt;
Speaking of features, it is nice to see custom Paged.js features appearing in other projects. Amélie Dumont is currently working on a website and book for which they work with a Javascript function to &amp;quot;keep&amp;quot; your scroll after a refresh. OMG Yes! Which is such a super useful feature to have when working on a book with many pages!&lt;br /&gt;
&lt;br /&gt;
It is nice to be reminded of the https://wiki2print.hackersanddesigners.nl/ link btw and to see the index page that you and also Martino started to work with. We decided to step away from it and integrated the index and update button(s) inside the wiki, which are two update buttons in our case: one for the text and one for the more heavier updates of media. In that way, we don&#039;t need to switch between the wiki interface and the Flask one, which felt like an interesting step towards staying within one shared environment both for writing and layout making. That is also why we totally forgot about this page actually. The page is technically still there in the version of wiki-to-print that is installed on the CC server, but it has no specific function anymore, apart from reminding us that we clicked an update button on the wiki, because it opens all the time after such click, which is probably something we could work around, but well...&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) It seems we have developed ways working on publications that are quite flexible and sometimes come with contingent and surprising outcomes. What is enjoyable about this way of working is that content production and design of publications can emerge on the go and in response to different collective conditions (i.e. different timelines, dispersed geographies, janky infrastructure). In the context of the Making Matters publication this somewhat unforeseeable collective process that we usually cherished, became quite challenging and somewhat incompatible with the material realities and ways of working of a publisher. You mentioned the softness of boundaries between designing, writing and editing. These soft boundaries can also become a bit scary when working on a publication with many pages, a large edition, involving high production costs. When changes in the beginning of the document can still affect something in the middle – potentially without us noticing. &lt;br /&gt;
There are many more tensions that can be experienced when it comes to designing for print in the browser. For instance, preparing and uploading images in high resolution seems counter intuitive in the context of web and network technologies. What are other tensions that come to mind and how do you negotiate those? Are there printing techniques that can be regarded as more compatible with wiki-to-print workflows than others? &lt;br /&gt;
&lt;br /&gt;
(varia) Editing wiki pages in order to change how a page will look on paper feels very counter-intuitive, as well. And sometimes you forget about things that are elementary to the web, like animated GIFs. In the browser of course, you can use animated GIFs. However, before exporting PDFs we had to remove the GIFs from wiki pages, to have control over which frame would appear in print. Of course you can undo these edits after exporting and still have the GIFs on the wiki, but it still feels counter-intuitive. [It can be fun to add animations to add some purposeful contingency into a layout too. see https://chatty-pub.hackersanddesigners.nl/Scriptothek#ch-infrables :-)]&lt;br /&gt;
&lt;br /&gt;
Another important bottleneck in the wiki-to-print workflow is image placement. When we approach a page as a &amp;quot;canvas&amp;quot;: with fixed margins, columns and font size, then the positioning of images is a very painful part of the process. The placement of an image depends on its position in the flow of the text. But of course, when you place an image on a wiki page, you have no idea where it ends up on a printed page! CSS Regions was initially introduced to work around this as it allows you to position the images and let text flow around them on a page. But unfortunately CSS Regions are not supported anymore by current browsers. There are different attitudes when designing for print, or for web, and implications that come from diverging established workflows. To give every image the same fixed width seems quite brutal in print, even though it may be desirable on the web, or vice versa. But the effects of resizing images one-by-one can easily cascade and you have to think about what else is affected on following pages.&lt;br /&gt;
&lt;br /&gt;
There is also the question of design cultures and ways of thinking that come from specific software. Shifting away from tools that are based on 500+ years of book design traditions toward web environments that are based on network technologies has many implications. One thing we noticed is that there has to be an adjustment in how much time and attention is given to producing a PDF for print. The instantaneousness of the web affects understandings of how ready the PDF is for printing, or how PDF documents are build at all. The PDF may still need to be converted into CYMK colorspace, distilled for a particular PDF format or have imposition applied before it is sent to a printer. Even though you can see it rendered in a browser window immediately the print preview is a sort of illusion. You are not really looking at the final version of the PDF at all, a lot of steps need to be taken afterwards to match industrial printing standards. &lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) What processes do your pdfs undergo &#039;afterwards&#039; to match printing standards?&lt;br /&gt;
&lt;br /&gt;
(varia) The Volumetric Regimes book is produced on-demand and needed to be submitted in a PDF/X-3:2002 format, which is not the format that browsers provide by default. It was quite a search to find a way to turn a PDF into that format, and in the end LaTeX was the way out here. Another big surprise that appeared during the making of the Volumetric Regimes book was the disappearance of the emoji face on [the cover](https://volumetricregimes.xyz/index.php?title=File:VRcover.png). We wanted to overprint this black emoji over the blue background gradient, which we managed to do with Ghostscript and [OSP&#039;s PDF-utils repository](https://gitlab.constantvzw.org/osp/tools.pdfutils). The PDF looked fine, the preflight software displayed the cover fine, so we were relieved! What we did not expect though, is to receive a box of books without the author names. They disappeared! The overprinting feature was applied to all elements on the cover, including the white text. Thanks to more help of the OSPs, we figured out that we can use Scribus to open the cover PDF and apply overprint only to a particular layer of the PDF. It was such a struggle!&lt;br /&gt;
&lt;br /&gt;
The Minor Tech newspaper didn&#039;t require such conversion, because we could talk with the people at Tripiti directly, who printed the newspaper for us. In that case we only converted the PDF into a grayscale colorspace, to make sure that the whole PDF was rendered in one color, which we needed because the newspaper was printed in offset with a spot colour. One thing that is not necessarily an &#039;afterwards&#039; process, but an important one, is browser choice. We worked using Mozilla Firefox for the Minor Tech newspaper up until realizing (just after midnight) that images were all in very low resolution when we pressed ctrl+P, so we had to switch to Chrome to make the final PDF. Even then, Chrome rendered the PDF slightly differently and we had to make some adjustments. These are things you hardly think about until right at the end of a design process. Luckily we caught this in time!&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) We loved reading your article about disappearing / eaten sentences: https://cc.vvvvvvaria.org/wiki/Octolog) and the hacks people invent to work around these issues, &amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt;&amp;lt;br/&amp;gt; :-))) &lt;br /&gt;
Karl brought back the Minor Tech newspaper from Transmediale. We were looking at it and were particularly impressed by the column layout! We have experienced a lot of issues with disappearing text in columns in the (printed) [First, Then... Repeat](link) publication. We felt a bit haunted by it and had agreed to NEVER use columns again! As you have experienced too text kept disappearing in the pdf, while in the browser it would still be visible! &lt;br /&gt;
&lt;br /&gt;
(Varia) Yes the disappearing sentences, oof, they were so painful. What really helped was that we were being able to reach out to Paged.js through their Mattermost chat. Julien Taquet works on Paged.js and is super present on the chat. It was through him that we could start to understand what the cause of this issue is, which was helpful and partially released some stress. But it did not solve the issue straight away, as it is a very sensitive one with close ties to the lower processing levels of Paged.js. So in the end we forced a page break on a very specific position in the text, which is a very scary thing to do, because it means that nothing else in the article can be changed anymore, not even a letter, to make sure that you don&#039;t end up with big gaps in the text. &lt;br /&gt;
&lt;br /&gt;
(varia) To come back to other tensions, those related to collective processes, we would be curious to hear more about the challenges that you encountered during the Making Matters production? What kind of changes were made in the last moment? How did this have an impact on the layout?&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) A challenging element was to converge – on the one hand the expectations to make something that reflects collective experimentation, which the book spoke about in its content and on the other hand negotiate the pretty much non-negotiable linear workflow of academic publishing, very tight deadlines, and many contributors and editors that don&#039;t know each other, are dispersed and hard to reach. A more fluent reciprocal process in this context didn&#039;t seem feasible. The notion of &amp;quot;experimentation&amp;quot; as well as &amp;quot;collective&amp;quot; were taken for granted as something inherently productive, as something that leads with certainty towards results – that can be predicated and measured by the same standards and criteria as any other book. While we were interested in and open about challenging the arbitrary boundaries of what is considered professional book design and what is not there were moments our &amp;quot;expertise&amp;quot; was questioned as designers. &lt;br /&gt;
By choosing this path we had ourselves already decided that micro-typography may not be our biggest priority. Instead we could pay attention to other exciting things. For instance the publication accommodates non-linear reading, which is something that the flat structure of a wiki inspired us to do. Cross-references are indicated with  different kinds of arrows, referring to one of the seven chapter themes. The arrows occur on the chapter introduction pages, next to the respective terms, as well as in the side bar navigation of the respective chapter categories. This allows the reader to quickly sift through the book and find terms in different contexts. In addition, elements in the side bar navigation subtly poke out when indicating the occurrence of a term in the text. We also worked with different colors per chapter and a subtle gradient that changes throughout the whole book to indicate that terms do not &#039;belong&#039; solely in one place but that their place is ambiguous and theory meanings spill over. The latter caused quite some pain in the pre-press process. The generated PDF had so many strange hidden elements and layers in it, that apparently showed up in the pre-press and caused a lot of troubles producing the gradient. We were not in contact with the printer directly, which made this whole pre-press process even harder. &lt;br /&gt;
&lt;br /&gt;
Making Matters was our first wiki-to-print attempt. Entering a rather large project with a publishing infrastructure that was quite new to us was exciting at first but also quite risky and stressful as there were so many moving variables. &lt;br /&gt;
&lt;br /&gt;
We had to present a pretty fixed design proposal at the beginning of the process, which we then worked towards. In a way we made a promise without knowing what is possible. On the one hand it was helpful to have a goal – something to hold on to. But it was also stressful because of unexpected quirks and impossibilities. Honestly, we did it because there was a budget for once, which gave us the possibility to finally dive into this workflow. Eventually we worked at least double of what we were paid. &lt;br /&gt;
&lt;br /&gt;
After that publication we&#039;ve been moving more and more towards a CSS editing process in the wiki CSS panel. That way, editing and styling become part of the same workflow, which also facilitates a more flexible approach to the design of the publication. &lt;br /&gt;
&lt;br /&gt;
(Varia) How did you do it before having the CSS in the wiki CSS panel? It seems to have had a big shift to work within the wiki all together.&lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) The Making Matters book needed to be laid out on a baseline grid, which proved to be challenging in CSS. We used a more traditional web development approach for the styling using Sass and a library called Plumber that made it possible to have a baseline grid in CSS. Web fonts don&#039;t always have a consistent baseline so you need to account for that for each font using positive and negative margins. Also images needed to be scaled so that they conform to the grid vertically. Headaches! This meant that editing content and applying styles were not integrated into a unified workflow regrettably. On the other hand, since the project was so CSS heavy it made sense to work on it in a more &#039;user-friendly&#039; environment. There were so many small interventions! As mentioned before, the book is structured like a dictionary and each time there is a keyword in the text the illustration in the margin reacts to that, creating a little animation when you flip through the book. We used P5js with a SVG renderer for that so that the illustrations were usable in print. In the end we made a little front-end in the PDF view where we can play with some of the settings, change the version of the script, toggle a view of the baseline grid, separate layers for printing. It was a fun challenge but since then we have moved more and more to a single workflow, and also simpler layouts. Only the fonts are hardcoded and all other styling done in the wiki. It makes for a more collaborative workflow. &lt;br /&gt;
&lt;br /&gt;
(H&amp;amp;D) We are curious, how to organize collective workflows around a wiki-to-print project? i.e. How many people should be involved in the workflow? How are tasks divided? Are you working in the same space or distributed/remotely? What are appropriate timelines and budgets?&lt;br /&gt;
&lt;br /&gt;
(varia) Regarding the soft deadlines, we noticed that working closely between editors and designers is really needed to make it happen. It is also important to have a shared understanding of the limitations and possibilities of wiki software, to find ways to think along with the workflow instead of going against the grain. This needs time for conversation and reflection and it is always a bit of a struggle. It&#039;s something that we are still figuring out.&lt;br /&gt;
&lt;br /&gt;
We have different experiences regarding the columns and collective conditions shaped by the workflow that also depend on the publication&#039;s content, conditions, collectivity and design choices. With Varia&#039;s occasional printed newsletter SomeTimes we were used to using columns in Octomode (a way of making PDFs from Etherpads), where all you have to worry about usually is how content flows from one column to another. [To give an idea, this is the PDF of SomeTimes, Issue 1, made in Octomode](https://varia.zone/documents/SomeTimes_number-1.pdf). The content of SomeTimes is made collectively from RSS feeds, particular hashtags on Mastodon, and posts gathered by a logbot. We have made a couple issues of it by now, and the simple design works, so we don&#039;t need to change it much. The budget is low, we produce it on A3 on a laser printer in our space in Rotterdam. Also the timelines are always short because we&#039;re already in the middle of so many other projects while working on it. In the making of this RSS workflow, we took these conditions as starting points for the design and development process.&lt;br /&gt;
&lt;br /&gt;
On the other hand, the Minor Tech newspaper was made using wiki-to-print and CSS grid during a two-day publication sprint between two people in Rotterdam and a large group that were writing and editing articles at a workshop in London. We were new to using CSS grid for paged media, and it took quite some tetris-ing to work within the constraints of the grid and a pre-determined page count. We spent a few hours before the sprint puzzling how different articles could fit, sketching in Octomode and on paper.&lt;br /&gt;
&lt;br /&gt;
![Aerial view of Varia working at our laptops in Rotterdam](https://vvvvvvaria.org/logs/toward-a-minor-tech/image/I1RSpI0hT_63HJ1giGW0Mw.jpg) &lt;br /&gt;
![Tetris-ing in Octomode](https://vvvvvvaria.org/logs/toward-a-minor-tech/image/Screenshot_from_2023-01-18_16-52-54.png) &lt;br /&gt;
![Tetris-ing on paper before the sprint](https://vvvvvvaria.org/logs/toward-a-minor-tech/image/U4vxHcdaQp-taZc_98-28Q.jpg)&lt;br /&gt;
&lt;br /&gt;
From the beginning, we had to accept the constraints of working within a rigid grid where it is impossible to flow articles from one page to another. It worked out in the case of the Minor Tech newspaper, as the texts were written with a maximum amount of 500 words. We ended up with a lot of small empty spaces though. We asked the writers for &amp;quot;cellular contributions&amp;quot; – content that would fit within the spaces of the newspaper that were left empty after our tetris-ing. The proposal for cellular contributions resulted in super nice quotes, pictures, and cute advertisements. &lt;br /&gt;
&lt;br /&gt;
![A quote included in the &amp;quot;cellular contributions&amp;quot; of the Toward a Minor Tech newspaper](https://varia.zone/archive/2023-01-Toward-a-Minor-Tech/toward-a-minor-tech-04.jpg)&lt;br /&gt;
&lt;br /&gt;
In this way, the shortcomings of working towards particular formats and scenarios, such as the typically heavy content density of a newspaper or a two-day collective production sprint, became a springboard into more experimental solutions and giving flexibility to the content and layout. This came from our choice to use CSS grid and also the availability of our collaborators during this sprint. But each publication workflow varies, and calls for different approaches. The use of CSS grid had a nice side effect, but the remote way of working during the sprint did not really help to let the production of content and layout overlap and intertwine. We would do this differently next time and prioritize being together in the same space to make sure we are in conversation with each other.&lt;br /&gt;
&lt;br /&gt;
... read the continuation of this conversation in the next bulletin&lt;/div&gt;</summary>
		<author><name>Slvie</name></author>
	</entry>
	<entry>
		<id>https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Earth_battery&amp;diff=6037</id>
		<title>Earth battery</title>
		<link rel="alternate" type="text/html" href="https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Earth_battery&amp;diff=6037"/>
		<updated>2023-07-14T07:05:18Z</updated>

		<summary type="html">&lt;p&gt;Slvie: basic editing grammer and punctuation&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ... looking back: &amp;lt;br&amp;gt; ✧˖°. Mud batteries ⋆ ˚｡⋆୨୧˚ ==&lt;br /&gt;
=== How-to make batteries from soil === &lt;br /&gt;
&amp;lt;span class=&amp;quot;author&amp;quot;&amp;gt;「 H&amp;amp;D in collaboration with Hackitects (Michel Barchini, Mary Farwy)」&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The 8th edition of the H&amp;amp;D Summer Academy &amp;quot;Connecting Otherwise&amp;quot; was organized in a distributed manner. H&amp;amp;D invited four initiatives (DDDUG, Hackitects, MELT, NEWS) to develop a workshop program together for four different interconnected locations: Amsterdam, Aotearoa (formerly known as New Zealand), Berlin (+ online) and Seoul. In Amsterdam, we were accompanied by the Hackitect collective (Michel Barchini, Mary Farwy). In the workshop, we invited participants to imagine and try out ways to radically reduce the energy use associated with communication technologies such as the Internet and consider a low-tech approach to &#039;connecting otherwise&#039;. The workshop incorporated different experimental approaches simultaneously. One focused on exploring strategies from DIY biotechnology, where bacteria found in local iron-rich soil are harnessed to generate and store energy. &lt;br /&gt;
&lt;br /&gt;
==== Collecting mud for the battery ====&lt;br /&gt;
Look for reddish brown soil (rich in iron) near river beds and swamps, areas where water has a reddish color. Preferably collect deep samples not from the surface.&lt;br /&gt;
&lt;br /&gt;
About 1 liter makes 2 batteries. Ideally, you get it a few days before the workshop, but the soil should stay good for up to two weeks. It is always good to collect more mud than what you calculate, in case some spills during preparations.&lt;br /&gt;
&lt;br /&gt;
Make sure you take mud as well as some water (see image below).&lt;br /&gt;
&lt;br /&gt;
==== Tools &amp;amp; Materials ==== &lt;br /&gt;
*Pot and stove to cook the agar mixture&lt;br /&gt;
*Multimeter&lt;br /&gt;
*Clippers and wire stripper&lt;br /&gt;
*Breadboard &lt;br /&gt;
*Kitchen scale&lt;br /&gt;
*Liquids measuring cup&lt;br /&gt;
*Tape (or anything to mark different wires)&lt;br /&gt;
&lt;br /&gt;
==== Materials ==== &lt;br /&gt;
*Mud &lt;br /&gt;
*Containers with wide openings on top (ex: glass jar or plastic container - around 1L)&lt;br /&gt;
*Electric wires (Copper wires 30 cm - 2 wires are needed per battery)&lt;br /&gt;
*Stainless steel grids to be cut in rectangles. Size: around 8 x 8 cm, but can change according to the size and shape of your container. Aluminium nets are good to use, but they are less conductive. You can also use kitchen strainer mesh. You can also experiment with the size of the net, for example: making it like a strip 8 x 20, to have more surface area. In this case, you can roll it without making the surfaces touch.&lt;br /&gt;
*Epoxy glue&lt;br /&gt;
*Small brush to spread the glue&lt;br /&gt;
*Active coal&lt;br /&gt;
*Agar (10g is needed per 1L battery)&lt;br /&gt;
*Salt substances (any broth powder - 1 pack, 2g per battery). Broth powder is the one you use for cooking. We used the veggie broth cubes that you buy from the supermarket.&lt;br /&gt;
*LED &lt;br /&gt;
*Drinking Water&lt;br /&gt;
&lt;br /&gt;
==== Making the Cathodes ==== &lt;br /&gt;
To make the cathodes you need the active coal, epoxy glue, metal nets and electric wires.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p class=&amp;quot;page-break&amp;quot;&amp;gt;&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:cathode1.jpg|thumb]]&lt;br /&gt;
ID: Hands performing the steps described in what follows&lt;br /&gt;
&lt;br /&gt;
#Empty the pills of the active coal to get the powder out, and place it on a sheet. (about 10 pills powder per 1 cathode disc)&lt;br /&gt;
#Cut two meshes in a rectangular shape, 8 x 8 cm. Place them in opposite directions and fold the edges so they are attached. We make two layers, so it can hold the glue and coal well.&lt;br /&gt;
#Brush the glue on the mesh and make sure that you add enough glue and that it is brushed evenly on the surface of the mesh.&lt;br /&gt;
&lt;br /&gt;
[[File:cathode2.jpg|thumb]]&lt;br /&gt;
ID: Hands performing the steps described in what follows&lt;br /&gt;
&lt;br /&gt;
#Cover the brushed mesh with the active coal powder and press it very well. After pressing, add coal and press again. It is very important that the coal is covering the whole surface.&lt;br /&gt;
#After making sure that the mesh is covered and pressed with coal, connect the mesh from one of the sides to an electric wire. In the end, you might need to bend the mesh to fit your container. Bend it, but be sure not to make the edges touch each other. More coal surface is better! Now leave it to fully dry.&lt;br /&gt;
&lt;br /&gt;
==== Preparing first part of the Soil Battery ====&lt;br /&gt;
For this step, you need the container (glass jar), mud, the dried cathodes.&lt;br /&gt;
&lt;br /&gt;
[[File:cathode3.jpg|thumb]]&lt;br /&gt;
ID: 1. The finished cathode, 2. Two glass jars half filled with mud, with a wire from the cathode coming out of the opening&lt;br /&gt;
&amp;lt;span class=&amp;quot;page-break&amp;quot;&amp;gt;&amp;amp;nbsp;&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
#Put the cathode in the container (make sure that the glue is dry, and the coal is stuck to it).&lt;br /&gt;
#Fill the jar with mud so it covers the cathode, keeping the wire out of the container.&lt;br /&gt;
#Mark the wire with tape to identify that it&#039;s negative. (black = negative)&lt;br /&gt;
#Hit the container to get all the trapped air bubbles out. It is VERY IMPORTANT to release the air bubbles from the mud.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;p class=&amp;quot;page-break&amp;quot;&amp;gt;&amp;amp;nbsp;&amp;lt;/p&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Making the proton exchange membrane ====&lt;br /&gt;
&lt;br /&gt;
[[File:mudbattery_parallel.jpg|thumb]]&lt;br /&gt;
ID: Process of preparing and pouring the agar described in the steps below&lt;br /&gt;
&lt;br /&gt;
[[File:battery_demonstration.jpg|thumb]]&lt;br /&gt;
ID: Mud battery in a glass jar: half filled with mud, then a layer of solidified agar, and filled to the top with clean tap water. Two cables are coming from the jar and are connected to an LED for illustration purposes.&lt;br /&gt;
&lt;br /&gt;
==== Connecting the batteries in parallel ====&lt;br /&gt;
The water part in the battery is (+) and the mud part is (-). When connecting two batteries in parallel, the (-) from the first battery should be connected to the (-) in the second one, and the (+) from the first to the (+) in the second. Then the (-) and (+) should be connected together to close the circuit. See the drawing:&lt;br /&gt;
&lt;br /&gt;
[[File:agar_membrane.jpg|thumb]]&lt;br /&gt;
ID: Diagram of two mud batteries connected in parallel: The cathode (or minus, black) comes from the mud of battery one and is connected to the cathode of battery 2. The anode (or plus, red) is the wire sitting in the top half of the water, and is connected to the anode of battery two.&lt;br /&gt;
&lt;br /&gt;
The mud-batteries how-to was assembled in preparation for the H&amp;amp;D Summer Academy 2022 &amp;quot;Connecting Otherwise,&amp;quot; and used as a guide during the workshop &amp;quot;SoilPunk&amp;quot; by Hackitects in collaboration with H&amp;amp;D.  &lt;br /&gt;
Visit https://github.com/hackersanddesigners/Soilpunk_joulethief for more complete documentation.&lt;br /&gt;
Listen to the audio documentation of Radio Echo Collective: https://www.mixcloud.com/RadioEchoCollective/hd-connecting-otherwise-soilpunk-with-hackitects-x-hd/&lt;/div&gt;</summary>
		<author><name>Slvie</name></author>
	</entry>
	<entry>
		<id>https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Bulletin_1_Introduction&amp;diff=6033</id>
		<title>Bulletin 1 Introduction</title>
		<link rel="alternate" type="text/html" href="https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Bulletin_1_Introduction&amp;diff=6033"/>
		<updated>2023-07-13T14:00:46Z</updated>

		<summary type="html">&lt;p&gt;Slvie: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Setting the scene ==&lt;br /&gt;
&amp;lt;span class=&amp;quot;author&amp;quot;&amp;gt;「 Anja Groten, Sylvie van Wijk 」&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This first edition of the H&amp;amp;D bulletin evolved in the period leading up to the H&amp;amp;D Summer Camp “Hopepunk: Reknitting Collective Infrastructures”, taking place from 17th to 27th of July 2023 at the campsite Het Wilde Weg in Sint-Oederode, The Netherlands. H&amp;amp;D is being given the opportunity to take over the entire campsite. We will temporarily move in and are excited to take good care of it while its owners are taking a break.&lt;br /&gt;
&lt;br /&gt;
Along with thirty co-habitants we embark on an adventure of learning, making and living together, working towards a holistic and intersectional way of practicing sustainability and regeneration (technically, socially, ecologically, economically, culturally). &lt;br /&gt;
 &lt;br /&gt;
The line “Hopepunk: Reknitting Collective Infrastructures” responds to the widespread onset feelings of anxiety, uncertainty and dread caused by geopolitical tensions, climate crisis and asymmetric distribution of wealth, power, and everyday resources, as accelerated by turbo-capitalist innovation and planetary-scale computing. The campsite will become our test site for reimagining and reknitting arbitrary boundaries between work, play, leisure, maintenance and care, that is, for managing “the meanwhile within damaged life’s perdurance.”&amp;lt;ref&amp;gt;Lauren Berlant, “The commons: Infrastructures for troubling times,” Environment and Planning D: Society and Space 34, no. 3 (2016): 393–419.&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== “It takes a village…” === &lt;br /&gt;
&lt;br /&gt;
Hope, to us, is political and rooted in generosity and reciprocity. It means collectively imagining and putting into practice economies of care – humble forms of exchange, that take others into account, that understand take regeneration as non-negotiable, that resist greed, the artificial scarcity, that refuse gate-keeping of resources, extraction and privatization. &lt;br /&gt;
&lt;br /&gt;
Setting up a temporary H&amp;amp;D village is our attempt to imagine what is not-yet there, or to put it in the words of physicist and feminist scholar Karen Barad, it is a ‘Gedankenexperiment’. Such thought experiments are imaginative, reflective, concrete, practical, and consequential. According to &lt;br /&gt;
Barad, &#039;Gedankenexperiments’ are pedagogical devices. They are non-material eventualities, however, they do matter in material ways.&amp;lt;ref&amp;gt;Barad, in Diss&amp;lt;/ref&amp;gt; &lt;br /&gt;
&lt;br /&gt;
We will be experimenting with solar technologies, solar-cooking and food preservation, community forming through life action role play, in situ coding, gymnastics, repurposing electronic and food waste, tracing the water histories of the past and the current local water, building electric circuits of organic materials and more. &lt;br /&gt;
&lt;br /&gt;
=== Refusal === &lt;br /&gt;
&lt;br /&gt;
At this site we enter into an immersive experiment of living and working together, self-organizing experience-based learning and tool-sharing as a political practice and mode of refusal. On the one hand, this refusal is about resisting linearity, efficiency and a progress-based understanding of earthly co-existence. On the other hand, it is also about resisting despair and refusing to accept the status quo we refer to the “punk” in Hopepunk (or akin genres such as Solar-, Cyber-, Cypher, and Steampunk) – the countercultural, oppositional aspect of exercising hope. That is, hope does not operate at the expense of active resistance. Being hopeful is about taking the liberty to orient towards something that sets in the future, that is not there yet, like the warm illumination of a horizon charged with possibility, it pulls us into the future.&lt;br /&gt;
&lt;br /&gt;
=== Solarpolitics === &lt;br /&gt;
&lt;br /&gt;
In her book &#039;&#039;Solar Politics&#039;&#039; Oxana Timofeeva describes the sun as a comrade in kind who gives without asking in return.  She explores the question: what would a socio-political economy, informed and fuelled by the sun, look like? &lt;br /&gt;
&lt;br /&gt;
The sun, as the biggest source of energy within our solar system, provides us with an excess of free energy that cannot be exhausted or contained. It is a common. It cannot be privatized. Could an economy solely fuelled by the sun be one defined by gift, solidarity and altruism? Could a shift from a capitalist to such a solar (powered) economy be a Copernican transformation? Similar to how the discovery of the sun as the core of our universe, changed the perception of us earthly inhabitants and ultimately our relationship with our environment to be less human-centric, could a sun-based economy equally recalibrate our ways of living together with the earth?&lt;br /&gt;
&lt;br /&gt;
The sun in Solarpunk is often depicted as “a super-abundant resource that can (in theory) provide for all and &#039;&#039;solar&#039;&#039; is in this sense equated with optimism, but also with a political ambition to envision and build a harmonious future powered by clean energy”.&amp;lt;ref&amp;gt;Johnson, &amp;quot;Solarpunk &amp;amp; the Pedagogical Value of Utopia&amp;quot; (2020), in: G. Kareola “Solarpunk &amp;amp; Web3” https://zine.zora.co/solarpunk-web3-kareola &amp;lt;/ref&amp;gt; The genre of Solarpunk has been acting as an orientation guide for H&amp;amp;D’s activities in the two years. The science fiction literary genre and art movement envisioned techno-futures in which humanity succeeded in solving major contemporary problems with the help of technology. Yet, as Georgia Kareola describes in &#039;&#039;Solarpunk &amp;amp; Web3&#039;&#039;, the specifics of these imaginaries “vary depending on the politics of the dreamer” After all, the “sunlight does not fall on everyone equally.”&amp;lt;ref&amp;gt; G. Kareola “Solarpunk &amp;amp; Web3” https://zine.zora.co/solarpunk-web3-kareola&amp;lt;/ref&amp;gt; In a similar sense, technology is not accessible to everyone equally.&lt;br /&gt;
&lt;br /&gt;
=== Hopeful pragmatism === &lt;br /&gt;
&lt;br /&gt;
The intergenerational Solarpunk workshops&amp;lt;ref&amp;gt;https://hackersanddesigners.nl/s/Events/p/Solarpunk_Kids_%28Bring_Your_Own_Grown-up%29_%E2%80%93_Scavenger_hunt_in_and_around_Page_Not_Found&amp;lt;/ref&amp;gt; we developed in 2022 showed us that the optimistic outlook embodied by the genre provides interesting tangents and tensions when combined with hands-on practical approaches. Can oppressive regimes, such as capitalism, authoritarianism, sexism, racism, and ableism be undone by solar power? It seems unlikely. Perhaps the core of punk futures lies in the DIY and DIT mentality – our capacity for generating pragmatic hopefulness.&lt;br /&gt;
&lt;br /&gt;
We’d hope such pragmatic hopefulness leads us to overcome the dystopias as well as the nostalgia of Cyber / Steam / Cypherpunk without creating a totalizing image of a harmonious utopian society (as is sometimes the case in the Solarpunk genre). What should not be forgotten is the injustices embedded in (solar) technology and the ways that climate change affects people “differently, unevenly, and disproportionately,”&lt;br /&gt;
&lt;br /&gt;
In a time of simultaneous and exponential increase of digital dependency and environmental exhaustion, we, as a collective of hackers, designers, artists, and educators intertwined with and interested in technology, find it important to answer the following question(s): &lt;br /&gt;
&lt;br /&gt;
&amp;lt;blockquote&amp;gt;&lt;br /&gt;
How can we build, repair, maintain and manage our technologies to allow for the continuous operation of global communication and information sharing while prevailing forms of digital dependencies are injurious to human and non-human life? How do we organise ourselves to this end? &lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
&lt;br /&gt;
These questions, and their possible answers, are at the heart of the political and aesthetic movements such as Solarpunk, Hopepunk and also more recently Permacomputing, to which Timofeeva’s text seems intimately related. All describe speculative scenarios about the full transition to renewable energies, which take on board a movement towards sustainability in inter-human interactions as well: &lt;br /&gt;
&lt;br /&gt;
&amp;lt;blockquote&amp;gt;“Solarpunk runs starkly in opposition to the political and economic forces of late-stage capitalism by demanding a non-hierarchical, diverse, decentralised yet integrated world. A world with worker co-operatives, tool shares, maker spaces, and common-pool resources.” (Andrewism, 2022) &lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The contributions in this edition attempt to imagine, articulate, visualize and draw into the future a hope-based society through the use of community-based tool-building and use, active engagement of the imagination for possible futures and the production of small-scale prototypes to this end. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;span class=&amp;quot;page-break&amp;quot;&amp;gt;&amp;amp;nbsp;&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;References: &lt;br /&gt;
&#039;&#039;&#039;&lt;br /&gt;
* Andrewism - Why this gives me hope for the future  https://www.youtube.com/watch?v=u3aauiR9M88  (2022)&lt;br /&gt;
* Oxfama Timoteefa, Solar Politics (2022) &lt;br /&gt;
* Williams, R., (2019) “‘This Shining Confluence of Magic and Technology’: Solarpunk, Energy Imaginaries, and the Infrastructures of Solarity”, Open Library of Humanities 5(1), 60. https://olh.openlibhums.org/article/id/4597/ &lt;br /&gt;
* “What might degrowth computing look like?” https://criticaledtech.com/2022/04/08/what-might-degrowth-computing-look-like/&lt;br /&gt;
* Isabelle Stengers “In Catastrophic Times” (…)&lt;br /&gt;
* Georgia Kareola “Solarpunk &amp;amp; Web3” https://zine.zora.co/solarpunk-web3-kareola&lt;br /&gt;
* “The Wickerman” &lt;br /&gt;
* “Land of Freedom” Ken Loach &lt;br /&gt;
* 2 articles of Juliette … &lt;br /&gt;
* Ursula K. Le Guin “The Dispossessed” (1974)&lt;br /&gt;
* Ursula K. Le Guin “Left hand of darkness” (1969)&lt;br /&gt;
* “Solarpunk” &amp;amp; the Pedagogical Value of Utopia http://www.susted.com/wordpress/content/solarpunk-the-pedagogical-value-of-utopia_2020_05/ &lt;br /&gt;
* Lauren Berlant “Infrastructures for troubling times”&lt;br /&gt;
* Karen Barad “Meeting the Universe Halfway”&lt;br /&gt;
* Instead of planned obsolescence, permacomputing practices planned longevity, reuse and repair of existing technology and approaches waste as a resource. https://wiki.xxiivv.com/site/permacomputing.html&lt;/div&gt;</summary>
		<author><name>Slvie</name></author>
	</entry>
	<entry>
		<id>https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Age_of_dust&amp;diff=6028</id>
		<title>Age of dust</title>
		<link rel="alternate" type="text/html" href="https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Age_of_dust&amp;diff=6028"/>
		<updated>2023-07-13T13:32:41Z</updated>

		<summary type="html">&lt;p&gt;Slvie: basic editing grammer and punctuation&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Looking forward... &amp;lt;br&amp;gt;ﾟ･:*｡ Age of Dust ~｡*:･ﾟ==&lt;br /&gt;
&amp;lt;span class=&amp;quot;author&amp;quot;&amp;gt;「 Juliette Lizotte 」 &amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Generations after the eruption of the Volcano, three communities meet around the discovery of a mysterious mineral: the Dust. As an essential source of energy, sacred healing powers, and geological warning, what messages and hopes does the Dust carry? When different belief systems meet, how to find a common ground? How will their encounter shape the world of tomorrow? The Age of Dust is a transformative journey, in which participants play out social and somatic dynamics to resist conventional narrative tropes and think beyond humans while experimenting with collaborative storytelling.&lt;br /&gt;
&lt;br /&gt;
=== The Setting ===&lt;br /&gt;
&lt;br /&gt;
Generations ago, an extraordinary eruption of the Volcano destroyed most of the world&#039;s life. The Creatures of the Crater survived. They are the offspring of volcanologists, native beings of the Volcano who were able to predict the event by combining their scientific and spiritual knowledge and therefore find refuge in time. They tried to warn others but were ignored. Every month during the new moon, when the sky was the darkest, the symbiotic community would come together for a ritual to commemorate all the lives taken by the lava and announce their predictions for the new cycle. During the ritual, they would enter into communication with the Magma Spirits that inhabit and constitute the Volcano, which could sometimes confirm their predictions. The Magma Spirits were one and multiple, witnesses of deeeeeeep time, they held a wonderful power of creation and destruction. &lt;br /&gt;
 &lt;br /&gt;
Further away from the Volcano, another community had survived: the Sourcers, survivalist techno witches that had hidden from the doomsday, underground in scattered burrows. It was said that Magma Spirits at night, during their sleep, had whispered in the ears of some Sourcers that the eruption was coming. All Sourcers were connected to each other through a techno-magical network that allowed them to share information, archive history, and organize their survival, although they were not physically together. &lt;br /&gt;
 &lt;br /&gt;
After the eruption, the landscape was dark and hostile, but it soon became the grounds for luscious bushes, strong trees that blossomed flowers, and fruits. The Creatures of the Crater reintroduced native species from seeds and cuttings they had preserved. Life started anew around the resting Volcano. But started growing hybrid, as if patch worked of different materials, the ground, trees, plants, stones, would sprout minerals, metals, sometimes gems...&lt;br /&gt;
 &lt;br /&gt;
Popping out of the peaceful black ground, some mysterious lava stones were found to be emitting a strange glow in the moonlight. Raising curiosity and wonder, the shining stones would sporadically puff up a red powder when the moon was at its fullest. The powder was called &amp;quot;the Dust&amp;quot; and it would magically disappear into the air with a sigh of relief, creating a soothing echo around the volcano. Among the Creatures of the Crater, some saw the blasts as messages, omens, or warnings from the underground, and were dedicated to understanding them. They developed rituals around them. &lt;br /&gt;
 &lt;br /&gt;
On their side of the world, Sourcers had also discovered the glowing stones and their Dust, but their presence was quite rare around the shelters. They found a way to capture the Dust before its disappearance and found it to be a rare and precious resource they could rely on for their survival. It was an alternative to the solar power that was becoming harder to source. They needed the Dust to survive and would need to find more of it.&lt;br /&gt;
 &lt;br /&gt;
Lately, the Dust phenomenon had changed behavior. Bursting more than before, breaking the cycle of the moon, the stones had been springing out, the Dust would not disappear into a shimmery sigh anymore, and little piles of Dust would remain on the ground, leaving everyone wondering. It was as if the geological process was broken. The balance had been disturbed.&lt;br /&gt;
 &lt;br /&gt;
A group of Sourcers got on its way to the volcano for the first time ever, breaking the perimeter of safety they had been living by for decades. &lt;br /&gt;
 &lt;br /&gt;
The Sourcers and the Creatures of the Crater were unaware of each other&#039;s existence, but the Magma Spirits could appear to both of them. &lt;br /&gt;
 &lt;br /&gt;
The three communities are about to meet and bond around the mysterious Dust and find ways to organize their lives with a resource essential to both for different reasons. Only the Maga Spirits know the true nature of the Dust, and they can only hope everyone will come together to restore balance... &lt;br /&gt;
&lt;br /&gt;
=== Rules / Disclaimers / Warnings ===&lt;br /&gt;
Gender: in the upcoming story, characters can be human or non-human, you can decide and share what pronouns you would like to go by. By default, we will use they/them for anyone, whether human or not, unless specified otherwise by a player. &lt;br /&gt;
Violence/tropes: this moment is thought of as an experience of wishful storytelling, the story can take many forms, and we make it together. Avoid bringing violence of any kind into our shared story, and try to resist falling into narrative tropes and archetypes. This is not the story of a hero&#039;s journey or a narrative about good vs. bad. Let&#039;s instead play with the understanding that everyone is intrinsically good and that everyone fights their tendencies to reproduce violent normative patriarchal systems. Let&#039;s practice dismantling!&lt;br /&gt;
It&#039;s important that everyone feels ownership over their character and the story.&lt;br /&gt;
The basis of the story will be set out, and you will be guided through it, but you are welcome and encouraged to make it yours, add to it, and invent new parts … You are invited to make this world, and expand it together!&lt;br /&gt;
We are x people, it&#039;s fine that things happen in parallel, you can have parallel discussions, and regroup when you need to take decisions as a group&lt;br /&gt;
Let your mind go wild, you are not expected to do anything, the play adapts to where you are taking the story.&lt;br /&gt;
Be mindful of the space you take and leave room for others to express themselves too, in the game we are trying to rehearse mindful and caring ways of behaving. Let&#039;s do this in everything we do during this time and hopefully afterward as well!&lt;br /&gt;
It is more important that we all have a great experience than that our story makes perfect sense.&lt;br /&gt;
Triggering spot &amp;gt; define altogether&lt;br /&gt;
&lt;br /&gt;
=== 3 types of characters (presented in printed character sheets): ===&lt;br /&gt;
Creatures of the Crater: &lt;br /&gt;
Community &amp;gt; symbiotic beings - living with and around the Volcano - humans/non-humans evolution of volcanologists and native lives&lt;br /&gt;
Time perception &amp;gt; follow the moon cycles &lt;br /&gt;
Power &amp;gt; measure things, and see omens in everything: they make predictions &lt;br /&gt;
Behavior &amp;gt; communicate with magma spirits at specific times&lt;br /&gt;
Fate &amp;gt; discover what Dust is&lt;br /&gt;
Action &amp;gt; can do 2 predictions of their choice (as a group) that must become true in the story&lt;br /&gt;
Sourcers/Fossorials: &lt;br /&gt;
Community - solar punk techno witches survivalists - humans/non-humans - living underground&lt;br /&gt;
Time perception&amp;gt; blurred&lt;br /&gt;
Power &amp;gt; connected with each other through a techno-magical network&lt;br /&gt;
Behavior &amp;gt; superstitious &amp;gt; DIY &amp;gt; commoning knowledge&lt;br /&gt;
Fate &amp;gt; survive and maintain their network&lt;br /&gt;
Action &amp;gt; can use 2 techno-magical solutions throughout the game that can solve anything (as a group)&lt;br /&gt;
Magma Spirits: &lt;br /&gt;
Community &amp;gt; spirits living in the Volcano - one and multiple - non-physical&lt;br /&gt;
Time perception &amp;gt; deep - geological&lt;br /&gt;
Power &amp;gt; channelling/ apparition&lt;br /&gt;
Behavior &amp;gt; can deliver cryptic messages to creatures of crater but can only interact at specific times&lt;br /&gt;
Fate &amp;gt; get physical beings to help them be liberated&lt;br /&gt;
Action &amp;gt; reveal their secret throughout the game (to be discussed with GM)&lt;br /&gt;
&lt;br /&gt;
The Age of Dust is a world-building workshop and live-action role-play imagined in the context of Lava Lines, a group exhibition and public program curated by Leila Arenou and Naïmé Perrette at Biblioteka in London, UK.&lt;br /&gt;
The project evolved in the context of Hackers &amp;amp; Designers 2023 program Hopepunk. &lt;br /&gt;
&lt;br /&gt;
The Age of Dust will be activated during the H&amp;amp;D Summer Camp 2023 at Het Wilde Weg, Sint-Oederode. The next iteration will take place at Constant Association of Art and Media in Brussels on the 15, 16, and 17th of September 2023. The role-playing part is reworked together with Susan Ploetz. The technical part is developed in close collaboration with Loes Bogers (H&amp;amp;D), Heerko van der Kooij (H&amp;amp;D) and Emma Pareschi.&lt;br /&gt;
https://constantvzw.org/site/Open-call-L-age-de-la-poussiere.html?lang=en &lt;br /&gt;
https://hackersanddesigners.nl/p/The_Age_of_Dust &lt;br /&gt;
&lt;br /&gt;
[if applicable, add more credits and references]&lt;/div&gt;</summary>
		<author><name>Slvie</name></author>
	</entry>
	<entry>
		<id>https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Bulletin_1_Introduction&amp;diff=6025</id>
		<title>Bulletin 1 Introduction</title>
		<link rel="alternate" type="text/html" href="https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Bulletin_1_Introduction&amp;diff=6025"/>
		<updated>2023-07-13T10:47:01Z</updated>

		<summary type="html">&lt;p&gt;Slvie: /* Setting the scene */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Setting the scene ==&lt;br /&gt;
&amp;lt;span class=&amp;quot;author&amp;quot;&amp;gt;「 Anja Groten, Sylvie van Wijk 」&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This first edition of the H&amp;amp;D bulletin evolved in the period leading up to the H&amp;amp;D Summer Camp “Hopepunk: Reknitting Collective Infrastructures”, taking place from 17th to 27th of July 2023 at the campsite Het Wilde Weg in Sint-Oederode, The Netherlands. H&amp;amp;D is being given the opportunity to take over the entire campsite. We will temporarily move in and are excited to take good care of it while its owners are taking a break.&lt;br /&gt;
&lt;br /&gt;
Along with thirty co-habitants we embark on an adventure of learning, making and living together, working towards a holistic and intersectional way of practicing sustainability and regeneration (technically, socially, ecologically, economically, culturally). &lt;br /&gt;
 &lt;br /&gt;
The line “Hopepunk: Reknitting Collective Infrastructures” responds to the widespread onset feelings of anxiety, uncertainty and dread caused by geopolitical tensions, climate crisis and asymmetric distribution of wealth, power, and everyday resources, as accelerated by turbo-capitalist innovation and planetary-scale computing. The campsite will become our test site for reimagining and reknitting arbitrary boundaries between work, play, leisure, maintenance and care, that is, for managing “the meanwhile within damaged life’s perdurance.”&amp;lt;ref&amp;gt;Lauren Berlant, “The commons: Infrastructures for troubling times,” Environment and Planning D: Society and Space 34, no. 3 (2016): 393–419.&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== “It takes a village…” === &lt;br /&gt;
&lt;br /&gt;
Hope, to us, is political and rooted in generosity and reciprocity. It means collectively imagining and putting into practice economies of care – humble forms of exchange, that take others into account, that understand take regeneration as non-negotiable, that resist greed, the artificial scarcity, that refuse gate-keeping of resources, extraction and privatization. &lt;br /&gt;
&lt;br /&gt;
Setting up a temporary H&amp;amp;D village is our attempt to imagine what is not-yet there, or to put it in the words of physicist and feminist scholar Karen Barad, it is a ‘Gedankenexperiment’. Such thought experiments are imaginative, reflective, concrete, practical, and consequential. According to &lt;br /&gt;
Barad, &#039;Gedankenexperiments’ are pedagogical devices. They are non-material eventualities, however, they do matter in material ways.&amp;lt;ref&amp;gt;Barad, in Diss&amp;lt;/ref&amp;gt; &lt;br /&gt;
&lt;br /&gt;
We will be experimenting with solar technologies, solar-cooking and food preservation, community forming through life action role play, in situ coding, gymnastics, repurposing electronic and food waste, tracing the water histories of the past and the current local water, building electric circuits of organic materials and more. &lt;br /&gt;
&lt;br /&gt;
=== Refusal === &lt;br /&gt;
&lt;br /&gt;
At this site we enter into an immersive experiment of living and working together, self-organizing experience-based learning and tool-sharing as a political practice and mode of refusal. On the one hand, this refusal is about resisting linearity, efficiency and a progress-based understanding of earthly co-existence. On the other hand, it is also about resisting despair and refusing to accept the status quo we refer to the “punk” in Hopepunk (or akin genres such as Solar-, Cyber-, Cypher, and Steampunk) – the countercultural, oppositional aspect of exercising hope. That is, hope does not operate at the expense of active resistance. Being hopeful is about taking the liberty to orient towards something that sets in the future, that is not there yet, like the warm illumination of a horizon charged with possibility, it pulls us into the future.&lt;br /&gt;
&lt;br /&gt;
=== Solarpolitics === &lt;br /&gt;
&lt;br /&gt;
In her book Solar Politics Oxana Timofeeva describes the sun as a comrade in kind who gives without asking in return.  She explores the question: what would a socio-political economy, informed and fuelled by the sun, look like? &lt;br /&gt;
&lt;br /&gt;
The sun, as the biggest source of energy within our solar system, provides us with an excess of free energy that cannot be exhausted or contained. It is a common. It cannot be privatized. Could an economy solely fuelled by the sun be one defined by gift, solidarity and altruism? Could a shift from a capitalist to such a solar (powered) economy be a Copernican transformation? Similar to how the discovery of the sun as the core of our universe, changed the perception of us earthly inhabitants and ultimately our relationship with our environment to be less human-centric, could a sun-based economy equally recalibrate our ways of living together with the earth?&lt;br /&gt;
&lt;br /&gt;
The sun in Solarpunk is often depicted as “a super-abundant resource that can (in theory) provide for all and “solar” is in this sense equated with optimism, but also with a political ambition to envision and build a harmonious future powered by clean energy”&amp;lt;ref&amp;gt;Johnson, &amp;quot;Solarpunk &amp;amp; the Pedagogical Value of Utopia&amp;quot; (2020), in: G. Kareola “Solarpunk &amp;amp; Web3” https://zine.zora.co/solarpunk-web3-kareola &amp;lt;/ref&amp;gt; The genre of Solarpunk has been acting as an orientation guide for H&amp;amp;D’s activities in the two years. The science fiction literary genre and art movement envisioned techno-futures in which humanity succeeded in solving major contemporary problems with the help of technology. Yet, as Georgia Kareola describes in “Solarpunk &amp;amp; Web3” the specifics of these imaginaries “vary depending on the politics of the dreamer” After all, the “sunlight does not fall on everyone equally.”&amp;lt;ref&amp;gt; G. Kareola “Solarpunk &amp;amp; Web3” https://zine.zora.co/solarpunk-web3-kareola&amp;lt;/ref&amp;gt; In a similar sense, technology is not accessible to everyone equally.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span class=&amp;quot;page-break&amp;quot;&amp;gt;&amp;amp;nbsp;&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Hopeful pragmatism === &lt;br /&gt;
&lt;br /&gt;
The intergenerational Solarpunk workshops&amp;lt;ref&amp;gt;https://hackersanddesigners.nl/s/Events/p/Solarpunk_Kids_%28Bring_Your_Own_Grown-up%29_%E2%80%93_Scavenger_hunt_in_and_around_Page_Not_Found&amp;lt;/ref&amp;gt; we developed in 2022 showed us that the optimistic outlook embodied by the genre provides interesting tangents and tensions when combined with hands-on practical approaches. Can oppressive regimes, such as capitalism, authoritarianism, sexism, racism, and ableism be undone by solar power? It seems unlikely. Perhaps the core of punk futures lies in the DIY and DIT mentality – our capacity for generating pragmatic hopefulness.&lt;br /&gt;
&lt;br /&gt;
We’d hope such pragmatic hopefulness leads us to overcome the dystopias as well as the nostalgia of Cyber / Steam / Cypherpunk without creating a totalizing image of a harmonious utopian society (as is sometimes the case in the Solarpunk genre). What should not be forgotten is the injustices embedded in (solar) technology and the ways that climate change affects people “differently, unevenly, and disproportionately,”&lt;br /&gt;
&lt;br /&gt;
In a time of simultaneous and exponential increase of digital dependency and environmental exhaustion, we, as a collective of hackers, designers, artists, and educators intertwined with and interested in technology, find it important to answer the following question(s): &lt;br /&gt;
&lt;br /&gt;
&amp;lt;blockquote&amp;gt;&lt;br /&gt;
How can we build, repair, maintain and manage our technologies to allow for the continuous operation of global communication and information sharing while prevailing forms of digital dependencies are injurious to human and non-human life? How do we organise ourselves to this end? &lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
&lt;br /&gt;
These questions, and their possible answers, are at the heart of the political and aesthetic movements such as Solarpunk, Hopepunk and also more recently Permacomputing, to which Timofeeva’s text seems intimately related. All describe speculative scenarios about the full transition to renewable energies, which take on board a movement towards sustainability in inter-human interactions as well: &lt;br /&gt;
&lt;br /&gt;
&amp;lt;blockquote&amp;gt;“Solarpunk runs starkly in opposition to the political and economic forces of late-stage capitalism by demanding a non-hierarchical, diverse, decentralised yet integrated world. A world with worker co-operatives, tool shares, maker spaces, and common-pool resources.” (Andrewism, 2022) &lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The contributions in this edition attempt to imagine, articulate, visualize and draw into the future a hope-based society through the use of community-based tool-building and use, active engagement of the imagination for possible futures and the production of small-scale prototypes to this end. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;span class=&amp;quot;page-break&amp;quot;&amp;gt;&amp;amp;nbsp;&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;References: &lt;br /&gt;
&#039;&#039;&#039;&lt;br /&gt;
* Andrewism - Why this gives me hope for the future  https://www.youtube.com/watch?v=u3aauiR9M88  (2022)&lt;br /&gt;
* Oxfama Timoteefa, Solar Politics (2022) &lt;br /&gt;
* Williams, R., (2019) “‘This Shining Confluence of Magic and Technology’: Solarpunk, Energy Imaginaries, and the Infrastructures of Solarity”, Open Library of Humanities 5(1), 60. https://olh.openlibhums.org/article/id/4597/ &lt;br /&gt;
* “What might degrowth computing look like?” https://criticaledtech.com/2022/04/08/what-might-degrowth-computing-look-like/&lt;br /&gt;
* Isabelle Stengers “In Catastrophic Times” (…)&lt;br /&gt;
* Georgia Kareola “Solarpunk &amp;amp; Web3” https://zine.zora.co/solarpunk-web3-kareola&lt;br /&gt;
* “The Wickerman” &lt;br /&gt;
* “Land of Freedom” Ken Loach &lt;br /&gt;
* 2 articles of Juliette … &lt;br /&gt;
* Ursula K. Le Guin “The Dispossessed” (1974)&lt;br /&gt;
* Ursula K. Le Guin “Left hand of darkness” (1969)&lt;br /&gt;
* “Solarpunk” &amp;amp; the Pedagogical Value of Utopia http://www.susted.com/wordpress/content/solarpunk-the-pedagogical-value-of-utopia_2020_05/ &lt;br /&gt;
* Lauren Berlant “Infrastructures for troubling times”&lt;br /&gt;
* Karen Barad “Meeting the Universe Halfway”&lt;br /&gt;
* Instead of planned obsolescence, permacomputing practices planned longevity, reuse and repair of existing technology and approaches waste as a resource. https://wiki.xxiivv.com/site/permacomputing.html&lt;/div&gt;</summary>
		<author><name>Slvie</name></author>
	</entry>
	<entry>
		<id>https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Bulletin_1_Introduction&amp;diff=6024</id>
		<title>Bulletin 1 Introduction</title>
		<link rel="alternate" type="text/html" href="https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Bulletin_1_Introduction&amp;diff=6024"/>
		<updated>2023-07-13T10:45:19Z</updated>

		<summary type="html">&lt;p&gt;Slvie: /* “It takes a village…” */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Setting the scene ==&lt;br /&gt;
&amp;lt;span class=&amp;quot;author&amp;quot;&amp;gt;「 Anja Groten, Sylvie van Wijk 」&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This first edition of the H&amp;amp;D bulletin evolved in the period leading up to the H&amp;amp;D Summer Camp “Hopepunk: Reknitting Collective Infrastructures”, taking place from 17th to 27th of July 2023 at the campsite Het Wilde Weg in Sint-Oederode, The Netherlands. H&amp;amp;D is being given the opportunity to take over the entire campsite. We are going to move in and are excited to take good care of it while its owners are taking a break.&lt;br /&gt;
&lt;br /&gt;
Along with thirty co-habitants we embark on an adventure of learning, making and living together, working towards a holistic and intersectional way of practicing sustainability and regeneration (technically, socially, ecologically, economically, culturally). &lt;br /&gt;
 &lt;br /&gt;
The line “Hopepunk: Reknitting Collective Infrastructures” responds to the widespread onset feelings of anxiety, uncertainty and dread caused by geopolitical tensions, climate crisis and asymmetric distribution of wealth, power, and everyday resources, as accelerated by turbo-capitalist innovation and planetary-scale computing. The campsite will become our test site for reimagining and reknitting arbitrary boundaries between work, play, leisure, maintenance and care, that is, for managing “the meanwhile within damaged life’s perdurance.”&amp;lt;ref&amp;gt;Lauren Berlant, “The commons: Infrastructures for troubling times,” Environment and Planning D: Society and Space 34, no. 3 (2016): 393–419.&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== “It takes a village…” === &lt;br /&gt;
&lt;br /&gt;
Hope, to us, is political and rooted in generosity and reciprocity. It means collectively imagining and putting into practice economies of care – humble forms of exchange, that take others into account, that understand take regeneration as non-negotiable, that resist greed, the artificial scarcity, that refuse gate-keeping of resources, extraction and privatization. &lt;br /&gt;
&lt;br /&gt;
Setting up a temporary H&amp;amp;D village is our attempt to imagine what is not-yet there, or to put it in the words of physicist and feminist scholar Karen Barad, it is a ‘Gedankenexperiment’. Such thought experiments are imaginative, reflective, concrete, practical, and consequential. According to &lt;br /&gt;
Barad, &#039;Gedankenexperiments’ are pedagogical devices. They are non-material eventualities, however, they do matter in material ways.&amp;lt;ref&amp;gt;Barad, in Diss&amp;lt;/ref&amp;gt; &lt;br /&gt;
&lt;br /&gt;
We will be experimenting with solar technologies, solar-cooking and food preservation, community forming through life action role play, in situ coding, gymnastics, repurposing electronic and food waste, tracing the water histories of the past and the current local water, building electric circuits of organic materials and more. &lt;br /&gt;
&lt;br /&gt;
=== Refusal === &lt;br /&gt;
&lt;br /&gt;
At this site we enter into an immersive experiment of living and working together, self-organizing experience-based learning and tool-sharing as a political practice and mode of refusal. On the one hand, this refusal is about resisting linearity, efficiency and a progress-based understanding of earthly co-existence. On the other hand, it is also about resisting despair and refusing to accept the status quo we refer to the “punk” in Hopepunk (or akin genres such as Solar-, Cyber-, Cypher, and Steampunk) – the countercultural, oppositional aspect of exercising hope. That is, hope does not operate at the expense of active resistance. Being hopeful is about taking the liberty to orient towards something that sets in the future, that is not there yet, like the warm illumination of a horizon charged with possibility, it pulls us into the future.&lt;br /&gt;
&lt;br /&gt;
=== Solarpolitics === &lt;br /&gt;
&lt;br /&gt;
In her book Solar Politics Oxana Timofeeva describes the sun as a comrade in kind who gives without asking in return.  She explores the question: what would a socio-political economy, informed and fuelled by the sun, look like? &lt;br /&gt;
&lt;br /&gt;
The sun, as the biggest source of energy within our solar system, provides us with an excess of free energy that cannot be exhausted or contained. It is a common. It cannot be privatized. Could an economy solely fuelled by the sun be one defined by gift, solidarity and altruism? Could a shift from a capitalist to such a solar (powered) economy be a Copernican transformation? Similar to how the discovery of the sun as the core of our universe, changed the perception of us earthly inhabitants and ultimately our relationship with our environment to be less human-centric, could a sun-based economy equally recalibrate our ways of living together with the earth?&lt;br /&gt;
&lt;br /&gt;
The sun in Solarpunk is often depicted as “a super-abundant resource that can (in theory) provide for all and “solar” is in this sense equated with optimism, but also with a political ambition to envision and build a harmonious future powered by clean energy”&amp;lt;ref&amp;gt;Johnson, &amp;quot;Solarpunk &amp;amp; the Pedagogical Value of Utopia&amp;quot; (2020), in: G. Kareola “Solarpunk &amp;amp; Web3” https://zine.zora.co/solarpunk-web3-kareola &amp;lt;/ref&amp;gt; The genre of Solarpunk has been acting as an orientation guide for H&amp;amp;D’s activities in the two years. The science fiction literary genre and art movement envisioned techno-futures in which humanity succeeded in solving major contemporary problems with the help of technology. Yet, as Georgia Kareola describes in “Solarpunk &amp;amp; Web3” the specifics of these imaginaries “vary depending on the politics of the dreamer” After all, the “sunlight does not fall on everyone equally.”&amp;lt;ref&amp;gt; G. Kareola “Solarpunk &amp;amp; Web3” https://zine.zora.co/solarpunk-web3-kareola&amp;lt;/ref&amp;gt; In a similar sense, technology is not accessible to everyone equally.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span class=&amp;quot;page-break&amp;quot;&amp;gt;&amp;amp;nbsp;&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Hopeful pragmatism === &lt;br /&gt;
&lt;br /&gt;
The intergenerational Solarpunk workshops&amp;lt;ref&amp;gt;https://hackersanddesigners.nl/s/Events/p/Solarpunk_Kids_%28Bring_Your_Own_Grown-up%29_%E2%80%93_Scavenger_hunt_in_and_around_Page_Not_Found&amp;lt;/ref&amp;gt; we developed in 2022 showed us that the optimistic outlook embodied by the genre provides interesting tangents and tensions when combined with hands-on practical approaches. Can oppressive regimes, such as capitalism, authoritarianism, sexism, racism, and ableism be undone by solar power? It seems unlikely. Perhaps the core of punk futures lies in the DIY and DIT mentality – our capacity for generating pragmatic hopefulness.&lt;br /&gt;
&lt;br /&gt;
We’d hope such pragmatic hopefulness leads us to overcome the dystopias as well as the nostalgia of Cyber / Steam / Cypherpunk without creating a totalizing image of a harmonious utopian society (as is sometimes the case in the Solarpunk genre). What should not be forgotten is the injustices embedded in (solar) technology and the ways that climate change affects people “differently, unevenly, and disproportionately,”&lt;br /&gt;
&lt;br /&gt;
In a time of simultaneous and exponential increase of digital dependency and environmental exhaustion, we, as a collective of hackers, designers, artists, and educators intertwined with and interested in technology, find it important to answer the following question(s): &lt;br /&gt;
&lt;br /&gt;
&amp;lt;blockquote&amp;gt;&lt;br /&gt;
How can we build, repair, maintain and manage our technologies to allow for the continuous operation of global communication and information sharing while prevailing forms of digital dependencies are injurious to human and non-human life? How do we organise ourselves to this end? &lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
&lt;br /&gt;
These questions, and their possible answers, are at the heart of the political and aesthetic movements such as Solarpunk, Hopepunk and also more recently Permacomputing, to which Timofeeva’s text seems intimately related. All describe speculative scenarios about the full transition to renewable energies, which take on board a movement towards sustainability in inter-human interactions as well: &lt;br /&gt;
&lt;br /&gt;
&amp;lt;blockquote&amp;gt;“Solarpunk runs starkly in opposition to the political and economic forces of late-stage capitalism by demanding a non-hierarchical, diverse, decentralised yet integrated world. A world with worker co-operatives, tool shares, maker spaces, and common-pool resources.” (Andrewism, 2022) &lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The contributions in this edition attempt to imagine, articulate, visualize and draw into the future a hope-based society through the use of community-based tool-building and use, active engagement of the imagination for possible futures and the production of small-scale prototypes to this end. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;span class=&amp;quot;page-break&amp;quot;&amp;gt;&amp;amp;nbsp;&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;References: &lt;br /&gt;
&#039;&#039;&#039;&lt;br /&gt;
* Andrewism - Why this gives me hope for the future  https://www.youtube.com/watch?v=u3aauiR9M88  (2022)&lt;br /&gt;
* Oxfama Timoteefa, Solar Politics (2022) &lt;br /&gt;
* Williams, R., (2019) “‘This Shining Confluence of Magic and Technology’: Solarpunk, Energy Imaginaries, and the Infrastructures of Solarity”, Open Library of Humanities 5(1), 60. https://olh.openlibhums.org/article/id/4597/ &lt;br /&gt;
* “What might degrowth computing look like?” https://criticaledtech.com/2022/04/08/what-might-degrowth-computing-look-like/&lt;br /&gt;
* Isabelle Stengers “In Catastrophic Times” (…)&lt;br /&gt;
* Georgia Kareola “Solarpunk &amp;amp; Web3” https://zine.zora.co/solarpunk-web3-kareola&lt;br /&gt;
* “The Wickerman” &lt;br /&gt;
* “Land of Freedom” Ken Loach &lt;br /&gt;
* 2 articles of Juliette … &lt;br /&gt;
* Ursula K. Le Guin “The Dispossessed” (1974)&lt;br /&gt;
* Ursula K. Le Guin “Left hand of darkness” (1969)&lt;br /&gt;
* “Solarpunk” &amp;amp; the Pedagogical Value of Utopia http://www.susted.com/wordpress/content/solarpunk-the-pedagogical-value-of-utopia_2020_05/ &lt;br /&gt;
* Lauren Berlant “Infrastructures for troubling times”&lt;br /&gt;
* Karen Barad “Meeting the Universe Halfway”&lt;br /&gt;
* Instead of planned obsolescence, permacomputing practices planned longevity, reuse and repair of existing technology and approaches waste as a resource. https://wiki.xxiivv.com/site/permacomputing.html&lt;/div&gt;</summary>
		<author><name>Slvie</name></author>
	</entry>
	<entry>
		<id>https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Bulletin_1_Introduction&amp;diff=6023</id>
		<title>Bulletin 1 Introduction</title>
		<link rel="alternate" type="text/html" href="https://wiki2print.hackersanddesigners.nl/wiki/mediawiki/index.php?title=Bulletin_1_Introduction&amp;diff=6023"/>
		<updated>2023-07-13T10:44:34Z</updated>

		<summary type="html">&lt;p&gt;Slvie: punctuation &amp;amp; grammer&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Setting the scene ==&lt;br /&gt;
&amp;lt;span class=&amp;quot;author&amp;quot;&amp;gt;「 Anja Groten, Sylvie van Wijk 」&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This first edition of the H&amp;amp;D bulletin evolved in the period leading up to the H&amp;amp;D Summer Camp “Hopepunk: Reknitting Collective Infrastructures”, taking place from 17th to 27th of July 2023 at the campsite Het Wilde Weg in Sint-Oederode, The Netherlands. H&amp;amp;D is being given the opportunity to take over the entire campsite. We are going to move in and are excited to take good care of it while its owners are taking a break.&lt;br /&gt;
&lt;br /&gt;
Along with thirty co-habitants we embark on an adventure of learning, making and living together, working towards a holistic and intersectional way of practicing sustainability and regeneration (technically, socially, ecologically, economically, culturally). &lt;br /&gt;
 &lt;br /&gt;
The line “Hopepunk: Reknitting Collective Infrastructures” responds to the widespread onset feelings of anxiety, uncertainty and dread caused by geopolitical tensions, climate crisis and asymmetric distribution of wealth, power, and everyday resources, as accelerated by turbo-capitalist innovation and planetary-scale computing. The campsite will become our test site for reimagining and reknitting arbitrary boundaries between work, play, leisure, maintenance and care, that is, for managing “the meanwhile within damaged life’s perdurance.”&amp;lt;ref&amp;gt;Lauren Berlant, “The commons: Infrastructures for troubling times,” Environment and Planning D: Society and Space 34, no. 3 (2016): 393–419.&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== “It takes a village…” === &lt;br /&gt;
&lt;br /&gt;
Hope to us, is political and rooted in generosity and reciprocity. It means collectively imagining and putting into practice economies of care – humble forms of exchange, that take others into account, that understand take regeneration as non-negotiable, that resist greed, the artificial scarcity, that refuse gate-keeping of resources, extraction and privatization. &lt;br /&gt;
&lt;br /&gt;
Setting up a temporary H&amp;amp;D village is our attempt to imagine what is not-yet there, or to put it in the words of physicist and feminist scholar Karen Barad, it is a ‘Gedankenexperiment’. Such thought experiments are imaginative, reflective, concrete, practical, and consequential. According to &lt;br /&gt;
Barad, &#039;Gedankenexperiments’ are pedagogical devices. They are non-material eventualities, however, they do matter in material ways.&amp;lt;ref&amp;gt;Barad, in Diss&amp;lt;/ref&amp;gt; &lt;br /&gt;
&lt;br /&gt;
We will be experimenting with solar technologies, solar-cooking and food preservation, community forming through life action role play, in situ coding, gymnastics, repurposing electronic and food waste, tracing the water histories of the past and the current local water, building electric circuits of organic materials and more. &lt;br /&gt;
&lt;br /&gt;
=== Refusal === &lt;br /&gt;
&lt;br /&gt;
At this site we enter into an immersive experiment of living and working together, self-organizing experience-based learning and tool-sharing as a political practice and mode of refusal. On the one hand, this refusal is about resisting linearity, efficiency and a progress-based understanding of earthly co-existence. On the other hand, it is also about resisting despair and refusing to accept the status quo we refer to the “punk” in Hopepunk (or akin genres such as Solar-, Cyber-, Cypher, and Steampunk) – the countercultural, oppositional aspect of exercising hope. That is, hope does not operate at the expense of active resistance. Being hopeful is about taking the liberty to orient towards something that sets in the future, that is not there yet, like the warm illumination of a horizon charged with possibility, it pulls us into the future.&lt;br /&gt;
&lt;br /&gt;
=== Solarpolitics === &lt;br /&gt;
&lt;br /&gt;
In her book Solar Politics Oxana Timofeeva describes the sun as a comrade in kind who gives without asking in return.  She explores the question: what would a socio-political economy, informed and fuelled by the sun, look like? &lt;br /&gt;
&lt;br /&gt;
The sun, as the biggest source of energy within our solar system, provides us with an excess of free energy that cannot be exhausted or contained. It is a common. It cannot be privatized. Could an economy solely fuelled by the sun be one defined by gift, solidarity and altruism? Could a shift from a capitalist to such a solar (powered) economy be a Copernican transformation? Similar to how the discovery of the sun as the core of our universe, changed the perception of us earthly inhabitants and ultimately our relationship with our environment to be less human-centric, could a sun-based economy equally recalibrate our ways of living together with the earth?&lt;br /&gt;
&lt;br /&gt;
The sun in Solarpunk is often depicted as “a super-abundant resource that can (in theory) provide for all and “solar” is in this sense equated with optimism, but also with a political ambition to envision and build a harmonious future powered by clean energy”&amp;lt;ref&amp;gt;Johnson, &amp;quot;Solarpunk &amp;amp; the Pedagogical Value of Utopia&amp;quot; (2020), in: G. Kareola “Solarpunk &amp;amp; Web3” https://zine.zora.co/solarpunk-web3-kareola &amp;lt;/ref&amp;gt; The genre of Solarpunk has been acting as an orientation guide for H&amp;amp;D’s activities in the two years. The science fiction literary genre and art movement envisioned techno-futures in which humanity succeeded in solving major contemporary problems with the help of technology. Yet, as Georgia Kareola describes in “Solarpunk &amp;amp; Web3” the specifics of these imaginaries “vary depending on the politics of the dreamer” After all, the “sunlight does not fall on everyone equally.”&amp;lt;ref&amp;gt; G. Kareola “Solarpunk &amp;amp; Web3” https://zine.zora.co/solarpunk-web3-kareola&amp;lt;/ref&amp;gt; In a similar sense, technology is not accessible to everyone equally.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span class=&amp;quot;page-break&amp;quot;&amp;gt;&amp;amp;nbsp;&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Hopeful pragmatism === &lt;br /&gt;
&lt;br /&gt;
The intergenerational Solarpunk workshops&amp;lt;ref&amp;gt;https://hackersanddesigners.nl/s/Events/p/Solarpunk_Kids_%28Bring_Your_Own_Grown-up%29_%E2%80%93_Scavenger_hunt_in_and_around_Page_Not_Found&amp;lt;/ref&amp;gt; we developed in 2022 showed us that the optimistic outlook embodied by the genre provides interesting tangents and tensions when combined with hands-on practical approaches. Can oppressive regimes, such as capitalism, authoritarianism, sexism, racism, and ableism be undone by solar power? It seems unlikely. Perhaps the core of punk futures lies in the DIY and DIT mentality – our capacity for generating pragmatic hopefulness.&lt;br /&gt;
&lt;br /&gt;
We’d hope such pragmatic hopefulness leads us to overcome the dystopias as well as the nostalgia of Cyber / Steam / Cypherpunk without creating a totalizing image of a harmonious utopian society (as is sometimes the case in the Solarpunk genre). What should not be forgotten is the injustices embedded in (solar) technology and the ways that climate change affects people “differently, unevenly, and disproportionately,”&lt;br /&gt;
&lt;br /&gt;
In a time of simultaneous and exponential increase of digital dependency and environmental exhaustion, we, as a collective of hackers, designers, artists, and educators intertwined with and interested in technology, find it important to answer the following question(s): &lt;br /&gt;
&lt;br /&gt;
&amp;lt;blockquote&amp;gt;&lt;br /&gt;
How can we build, repair, maintain and manage our technologies to allow for the continuous operation of global communication and information sharing while prevailing forms of digital dependencies are injurious to human and non-human life? How do we organise ourselves to this end? &lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
&lt;br /&gt;
These questions, and their possible answers, are at the heart of the political and aesthetic movements such as Solarpunk, Hopepunk and also more recently Permacomputing, to which Timofeeva’s text seems intimately related. All describe speculative scenarios about the full transition to renewable energies, which take on board a movement towards sustainability in inter-human interactions as well: &lt;br /&gt;
&lt;br /&gt;
&amp;lt;blockquote&amp;gt;“Solarpunk runs starkly in opposition to the political and economic forces of late-stage capitalism by demanding a non-hierarchical, diverse, decentralised yet integrated world. A world with worker co-operatives, tool shares, maker spaces, and common-pool resources.” (Andrewism, 2022) &lt;br /&gt;
&amp;lt;/blockquote&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The contributions in this edition attempt to imagine, articulate, visualize and draw into the future a hope-based society through the use of community-based tool-building and use, active engagement of the imagination for possible futures and the production of small-scale prototypes to this end. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;span class=&amp;quot;page-break&amp;quot;&amp;gt;&amp;amp;nbsp;&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;References: &lt;br /&gt;
&#039;&#039;&#039;&lt;br /&gt;
* Andrewism - Why this gives me hope for the future  https://www.youtube.com/watch?v=u3aauiR9M88  (2022)&lt;br /&gt;
* Oxfama Timoteefa, Solar Politics (2022) &lt;br /&gt;
* Williams, R., (2019) “‘This Shining Confluence of Magic and Technology’: Solarpunk, Energy Imaginaries, and the Infrastructures of Solarity”, Open Library of Humanities 5(1), 60. https://olh.openlibhums.org/article/id/4597/ &lt;br /&gt;
* “What might degrowth computing look like?” https://criticaledtech.com/2022/04/08/what-might-degrowth-computing-look-like/&lt;br /&gt;
* Isabelle Stengers “In Catastrophic Times” (…)&lt;br /&gt;
* Georgia Kareola “Solarpunk &amp;amp; Web3” https://zine.zora.co/solarpunk-web3-kareola&lt;br /&gt;
* “The Wickerman” &lt;br /&gt;
* “Land of Freedom” Ken Loach &lt;br /&gt;
* 2 articles of Juliette … &lt;br /&gt;
* Ursula K. Le Guin “The Dispossessed” (1974)&lt;br /&gt;
* Ursula K. Le Guin “Left hand of darkness” (1969)&lt;br /&gt;
* “Solarpunk” &amp;amp; the Pedagogical Value of Utopia http://www.susted.com/wordpress/content/solarpunk-the-pedagogical-value-of-utopia_2020_05/ &lt;br /&gt;
* Lauren Berlant “Infrastructures for troubling times”&lt;br /&gt;
* Karen Barad “Meeting the Universe Halfway”&lt;br /&gt;
* Instead of planned obsolescence, permacomputing practices planned longevity, reuse and repair of existing technology and approaches waste as a resource. https://wiki.xxiivv.com/site/permacomputing.html&lt;/div&gt;</summary>
		<author><name>Slvie</name></author>
	</entry>
</feed>