Creative Crowd - Revision history

Hd-onions: /* Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on... */

2023-10-23T09:22:59Z

Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on...

← Older revision		Revision as of 11:22, 23 October 2023
Line 48:		Line 48:
	'''(H&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. Being used to somewhat 'intuitive' ways of working with layout software, that is, being able to see different versions of a layout very quickly, the process and outcomes of LaTex seemed rather stiff in comparison. It also seemed that LaTeX is very good at certain things – i.e. making a layout look very 'proper' but not so good at making surprising interventions. The wiki-scribus combination offered more flexibility. We basically used the wiki to edit and structure the publication collaboratively, and eventually used Pandoc to convert the wiki syntax to something we could import to and use in Scribus. We could simultaneously edit in the wiki and easily refresh the Scribus file with the new content without losing the styling we had done. But there was still this annoying break between writing/assembling of the content on the one hand and styling it on the other.		'''(H&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. Being used to somewhat 'intuitive' ways of working with layout software, that is, being able to see different versions of a layout very quickly, the process and outcomes of LaTex seemed rather stiff in comparison. It also seemed that LaTeX is very good at certain things – i.e. making a layout look very 'proper' but not so good at making surprising interventions. The wiki-scribus combination offered more flexibility. We basically used the wiki to edit and structure the publication collaboratively, and eventually used Pandoc to convert the wiki syntax to something we could import to and use in Scribus. We could simultaneously edit in the wiki and easily refresh the Scribus file with the new content without losing the styling we had done. But there was still this annoying break between writing/assembling of the content on the one hand and styling it on the other.

	It took us a while to move towards wiki2print. There were various other publishing experiments in between, like heart-beat to print<ref>https://hackersanddesigners.nl/s/Publishing/p/Heartbeat-to-print</ref>, and the iteration of Sarah Garcin's PJ Machine (Publishing Jockey Machine)<ref>https://hackersanddesigners.nl/s/Publishing/p/On_%26_Off_</br>		It took us a while to move towards wiki2print. There were various other publishing experiments in between, like heart-beat to print<ref>https://hackersanddesigners.nl/s/Publishing/p/Heartbeat-to-print</br></ref>, and the iteration of Sarah Garcin's PJ Machine (Publishing Jockey Machine)<ref>https://hackersanddesigners.nl/s/Publishing/p/On_%26_Off_</br>
	the_Grid_Publication</ref>.		the_Grid_Publication</ref>.

Line 58:		Line 58:

	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 them. We also like the idea of contributing to the larger collective effort to improve 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).<ref>https://hackersanddesigners.nl/s/Publishing/p/First</br>		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 them. We also like the idea of contributing to the larger collective effort to improve 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).<ref>https://hackersanddesigners.nl/s/Publishing/p/First</br>
	%2C_Then..._Repeat._Workshop_Scripts_in_Practice</ref> Wiki has a very useful feature for uploading new versions of files. Yet, in the Paged.js preview, the new file versions were 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 "overwrite images" check box<ref> https://wiki2print.hackersanddesigners.nl/</br></ref> which replaces the image with the last uploaded version.		%2C_Then..._Repeat._Workshop_Scripts_in_Practice</br></ref> Wiki has a very useful feature for uploading new versions of files. Yet, in the Paged.js preview, the new file versions were 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 "overwrite images" check box<ref> https://wiki2print.hackersanddesigners.nl/</br></ref> which replaces the image with the last uploaded version.

	'''(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.		'''(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.
Line 90:		Line 90:

	Karl brought back the Minor Tech newspaper from Transmediale. We 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 publication.<ref>https://hackersanddesigners.nl/s/Publishing/p/</br>		Karl brought back the Minor Tech newspaper from Transmediale. We 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 publication.<ref>https://hackersanddesigners.nl/s/Publishing/p/</br>
	First%2C_Then..._Repeat._Workshop_Scripts_in_Practice</ref> 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!		First%2C_Then..._Repeat._Workshop_Scripts_in_Practice</br></ref> 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!

	'''(Varia)''' Yes, the disappearing sentences, oof, they were so painful. What really helped was that we were 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 the cause of this issue. It was very 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't end up with big gaps in the text.		'''(Varia)''' Yes, the disappearing sentences, oof, they were so painful. What really helped was that we were 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 the cause of this issue. It was very 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't end up with big gaps in the text.

Hd-onions: /* Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on... */

2023-10-19T10:30:34Z

Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on...

← Older revision		Revision as of 12:30, 19 October 2023
Line 125:		Line 125:
	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 was 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.		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 was 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.

	~~<span class="page-break"> </span>~~

	<div class="smaller-image">		<div class="smaller-image">
Line 140:		Line 139:

	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 "cellular contributions" – 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.		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 "cellular contributions" – 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.


	<div class="smaller-image">		<div class="smaller-image">
	[[File:Toward-a-minor-tech-04.jpg\|thumb\|A quote included in the "cellular contributions" of the Toward a Minor Tech newspaper]]		[[File:Toward-a-minor-tech-04.jpg\|thumb\|A quote included in the "cellular contributions" of the Toward a Minor Tech newspaper]]
	</div>		</div>

			<span class="page-break"> </span>

	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 gave 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.		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 gave 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.

Hd-onions: /* Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on... */

2023-10-19T10:26:00Z

Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on...

← Older revision		Revision as of 12:26, 19 October 2023
Line 124:		Line 124:

	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 was 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.		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 was 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.

			<span class="page-break"> </span>

	<div class="smaller-image">		<div class="smaller-image">

Hd-onions: /* Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on... */

2023-10-19T09:46:06Z

Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on...

← Older revision		Revision as of 11:46, 19 October 2023
Line 146:		Line 146:


	... This conversation will be continued in the next ~~bulletin~~.		... This conversation will be continued in one of the next bulletins.

Hd-onions: /* Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on... */

2023-10-19T09:28:18Z

Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on...

← Older revision		Revision as of 11:28, 19 October 2023
Line 27:		Line 27:
	* Manetta Berends' work on Volumetric Regimes with Possible Bodies, published by Open Humanities Press in the * Data Browser series: https://volumetricregimes.xyz/ http://www.data-browser.net/db08.html		* Manetta Berends' work on Volumetric Regimes with Possible Bodies, published by Open Humanities Press in the * Data Browser series: https://volumetricregimes.xyz/ http://www.data-browser.net/db08.html
	* Martino Morandi's work on Wiki-to-pdf with TITiPI: https://titipi.org/wiki/index.php/Wiki-to-pdf https://titipi.org/wiki-to-pdf/pagedjs/Infrastructural_Interactions		* Martino Morandi's work on Wiki-to-pdf with TITiPI: https://titipi.org/wiki/index.php/Wiki-to-pdf https://titipi.org/wiki-to-pdf/pagedjs/Infrastructural_Interactions
	* ~~Hackers~~ & ~~Designer~~'s work on Making Matters: https://hackersanddesigners.nl/s/Publishing/p/Making_Matters._A_Vocabulary_of_Collective_Arts, https://wiki2print.hackersanddesigners.nl/wiki/Publishing:Making_Matters_Lexicon		* H&D's work on Making Matters: https://hackersanddesigners.nl/s/Publishing/p/Making_Matters._A_Vocabulary_of_Collective_Arts, https://wiki2print.hackersanddesigners.nl/wiki/Publishing:Making_Matters_Lexicon
	* Varia's work on Toward a Minor Tech with APRJA: https://darc.au.dk/publications/peer-reviewed-newspaper https://varia.zone/en/toward-a-minor-tech.html https://cc.vvvvvvaria.org/wiki/Wiki-to-print		* Varia's work on Toward a Minor Tech with APRJA: https://darc.au.dk/publications/peer-reviewed-newspaper https://varia.zone/en/toward-a-minor-tech.html https://cc.vvvvvvaria.org/wiki/Wiki-to-print

Hd-onions: /* Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on... */

2023-10-19T09:27:19Z

Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on...

← Older revision		Revision as of 11:27, 19 October 2023
Line 48:		Line 48:
	'''(H&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. Being used to somewhat 'intuitive' ways of working with layout software, that is, being able to see different versions of a layout very quickly, the process and outcomes of LaTex seemed rather stiff in comparison. It also seemed that LaTeX is very good at certain things – i.e. making a layout look very 'proper' but not so good at making surprising interventions. The wiki-scribus combination offered more flexibility. We basically used the wiki to edit and structure the publication collaboratively, and eventually used Pandoc to convert the wiki syntax to something we could import to and use in Scribus. We could simultaneously edit in the wiki and easily refresh the Scribus file with the new content without losing the styling we had done. But there was still this annoying break between writing/assembling of the content on the one hand and styling it on the other.		'''(H&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. Being used to somewhat 'intuitive' ways of working with layout software, that is, being able to see different versions of a layout very quickly, the process and outcomes of LaTex seemed rather stiff in comparison. It also seemed that LaTeX is very good at certain things – i.e. making a layout look very 'proper' but not so good at making surprising interventions. The wiki-scribus combination offered more flexibility. We basically used the wiki to edit and structure the publication collaboratively, and eventually used Pandoc to convert the wiki syntax to something we could import to and use in Scribus. We could simultaneously edit in the wiki and easily refresh the Scribus file with the new content without losing the styling we had done. But there was still this annoying break between writing/assembling of the content on the one hand and styling it on the other.

	It took us a while to move towards wiki2print. There were various other publishing experiments in between, like heart-beat to print<ref>https://hackersanddesigners.nl/s/Publishing/p/Heartbeat-to-print</ref>, and the iteration of Sarah Garcin's PJ Machine (Publishing Jockey Machine)<ref>https://hackersanddesigners.nl/s/Publishing/p/On_%~~26_Off_the_Grid_Publication~~</ref>.		It took us a while to move towards wiki2print. There were various other publishing experiments in between, like heart-beat to print<ref>https://hackersanddesigners.nl/s/Publishing/p/Heartbeat-to-print</ref>, and the iteration of Sarah Garcin's PJ Machine (Publishing Jockey Machine)<ref>https://hackersanddesigners.nl/s/Publishing/p/On_%26_Off_</br>
			the_Grid_Publication</ref>.

	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 (designer, writer, coder, copy editor...) are not so separate anymore. As a designer, you make different kinds of choices, you are perhaps more forgiving? 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 one could also question this so-called agency given by certain tools – the illusion of mastery they emanate.		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 (designer, writer, coder, copy editor...) are not so separate anymore. As a designer, you make different kinds of choices, you are perhaps more forgiving? 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 one could also question this so-called agency given by certain tools – the illusion of mastery they emanate.

Hd-onions: /* Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on... */

2023-10-19T09:26:29Z

Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on...

← Older revision		Revision as of 11:26, 19 October 2023
Line 85:		Line 85:
	One important thing to keep in mind is browser choice. We used 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!		One important thing to keep in mind is browser choice. We used 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!

	'''(H&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, <pre~~><br/~~><br/><br/><br/><br/><br/><br/><br/></pre>		'''(H&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, <pre><br/><br/><br/><br/><br/><br/><br/></pre>
	<pre>:-)))</pre>		<pre>:-)))</pre>

Hd-onions at 09:24, 19 October 2023

2023-10-19T09:24:44Z

← Older revision		Revision as of 11:24, 19 October 2023
Line 56:		Line 56:
	In 2022, we worked on the Making Matters publication <ref>https://hackersanddesigners.nl/s/Publishing/p/Making_Matters._A_Vocabulary_of_Collective_Arts</ref> for which we looked at the repository of Manetta for Volumetric Regimes for Possible Bodies<ref>https://volumetricregimes.xyz/ http://www.data-browser.net/db08.html</ref> and Martino for TITiPI<ref>TITiPI: https://titipi.org/wiki/index.php/Wiki-to-pdf https://titipi.org/wiki-to-pdf/pagedjs/Infrastructural_Interactions</ref>. 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. We added an elaborate ''Note about the design of the publication'' in which we acknowledged the work that has already been done, and mentioned other relevant projects and practices that inspire us. We felt so excited to read the colophon of Minor Tech and see the trail grow.		In 2022, we worked on the Making Matters publication <ref>https://hackersanddesigners.nl/s/Publishing/p/Making_Matters._A_Vocabulary_of_Collective_Arts</ref> for which we looked at the repository of Manetta for Volumetric Regimes for Possible Bodies<ref>https://volumetricregimes.xyz/ http://www.data-browser.net/db08.html</ref> and Martino for TITiPI<ref>TITiPI: https://titipi.org/wiki/index.php/Wiki-to-pdf https://titipi.org/wiki-to-pdf/pagedjs/Infrastructural_Interactions</ref>. 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. We added an elaborate ''Note about the design of the publication'' in which we acknowledged the work that has already been done, and mentioned other relevant projects and practices that inspire us. We felt so excited to read the colophon of Minor Tech and see the trail grow.

	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 them. We also like the idea of contributing to the larger collective effort to improve 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).<ref>https://hackersanddesigners.nl/s/Publishing/p/First%2C_Then..._Repeat._Workshop_Scripts_in_Practice</ref> Wiki has a very useful feature for uploading new versions of files. Yet, in the Paged.js preview, the new file versions were 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 "overwrite images" check box<ref> https://wiki2print.hackersanddesigners.nl/</br></ref> which replaces the image with the last uploaded version.		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 them. We also like the idea of contributing to the larger collective effort to improve 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).<ref>https://hackersanddesigners.nl/s/Publishing/p/First</br>
			%2C_Then..._Repeat._Workshop_Scripts_in_Practice</ref> Wiki has a very useful feature for uploading new versions of files. Yet, in the Paged.js preview, the new file versions were 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 "overwrite images" check box<ref> https://wiki2print.hackersanddesigners.nl/</br></ref> which replaces the image with the last uploaded version.

	'''(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.		'''(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.

Hd-onions at 09:23, 19 October 2023

2023-10-19T09:23:52Z

← Older revision		Revision as of 11:23, 19 October 2023
Line 47:		Line 47:

	'''(H&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. Being used to somewhat 'intuitive' ways of working with layout software, that is, being able to see different versions of a layout very quickly, the process and outcomes of LaTex seemed rather stiff in comparison. It also seemed that LaTeX is very good at certain things – i.e. making a layout look very 'proper' but not so good at making surprising interventions. The wiki-scribus combination offered more flexibility. We basically used the wiki to edit and structure the publication collaboratively, and eventually used Pandoc to convert the wiki syntax to something we could import to and use in Scribus. We could simultaneously edit in the wiki and easily refresh the Scribus file with the new content without losing the styling we had done. But there was still this annoying break between writing/assembling of the content on the one hand and styling it on the other.		'''(H&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. Being used to somewhat 'intuitive' ways of working with layout software, that is, being able to see different versions of a layout very quickly, the process and outcomes of LaTex seemed rather stiff in comparison. It also seemed that LaTeX is very good at certain things – i.e. making a layout look very 'proper' but not so good at making surprising interventions. The wiki-scribus combination offered more flexibility. We basically used the wiki to edit and structure the publication collaboratively, and eventually used Pandoc to convert the wiki syntax to something we could import to and use in Scribus. We could simultaneously edit in the wiki and easily refresh the Scribus file with the new content without losing the styling we had done. But there was still this annoying break between writing/assembling of the content on the one hand and styling it on the other.

	~~<span class="page-break"> </span>~~

	It took us a while to move towards wiki2print. There were various other publishing experiments in between, like heart-beat to print<ref>https://hackersanddesigners.nl/s/Publishing/p/Heartbeat-to-print</ref>, and the iteration of Sarah Garcin's PJ Machine (Publishing Jockey Machine)<ref>https://hackersanddesigners.nl/s/Publishing/p/On_%26_Off_the_Grid_Publication</ref>.		It took us a while to move towards wiki2print. There were various other publishing experiments in between, like heart-beat to print<ref>https://hackersanddesigners.nl/s/Publishing/p/Heartbeat-to-print</ref>, and the iteration of Sarah Garcin's PJ Machine (Publishing Jockey Machine)<ref>https://hackersanddesigners.nl/s/Publishing/p/On_%26_Off_the_Grid_Publication</ref>.

Hd-onions: /* Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on... */

2023-10-19T09:23:17Z

Wiki-to-print, Wiki2print, Wiki-to-pdf, and so on...

← Older revision		Revision as of 11:23, 19 October 2023
Line 27:		Line 27:
	* Manetta Berends' work on Volumetric Regimes with Possible Bodies, published by Open Humanities Press in the * Data Browser series: https://volumetricregimes.xyz/ http://www.data-browser.net/db08.html		* Manetta Berends' work on Volumetric Regimes with Possible Bodies, published by Open Humanities Press in the * Data Browser series: https://volumetricregimes.xyz/ http://www.data-browser.net/db08.html
	* Martino Morandi's work on Wiki-to-pdf with TITiPI: https://titipi.org/wiki/index.php/Wiki-to-pdf https://titipi.org/wiki-to-pdf/pagedjs/Infrastructural_Interactions		* Martino Morandi's work on Wiki-to-pdf with TITiPI: https://titipi.org/wiki/index.php/Wiki-to-pdf https://titipi.org/wiki-to-pdf/pagedjs/Infrastructural_Interactions
	* Hackers & Designer's work on Making Matters:		* Hackers & Designer's work on Making Matters: https://hackersanddesigners.nl/s/Publishing/p/Making_Matters._A_Vocabulary_of_Collective_Arts, https://wiki2print.hackersanddesigners.nl/wiki/Publishing:Making_Matters_Lexicon
	https://hackersanddesigners.nl/s/Publishing/p/Making_Matters._A_Vocabulary_of_Collective_Arts
	https://wiki2print.hackersanddesigners.nl/wiki/Publishing:Making_Matters_Lexicon
	* Varia's work on Toward a Minor Tech with APRJA: https://darc.au.dk/publications/peer-reviewed-newspaper https://varia.zone/en/toward-a-minor-tech.html https://cc.vvvvvvaria.org/wiki/Wiki-to-print		* Varia's work on Toward a Minor Tech with APRJA: https://darc.au.dk/publications/peer-reviewed-newspaper https://varia.zone/en/toward-a-minor-tech.html https://cc.vvvvvvaria.org/wiki/Wiki-to-print