Open Source Publishing was a graphic design research work-group that used only Free Software tools. Now it has grown into an independent project from Constant.
Closely affiliated with Constant, OSP was created in 2006 as an experimental project to test the possibilities and realities of doing graphic design using an expanding range of Free Software tools. Over time it has grown into a diverse collaborative practice. In 2013 OSP has become an association independent from Constant.
OSP is serious about testing the possibilities and limitations of Open Source software in a professional design environment, without expecting to find the same experience as the ones we are used to. In fact, OSP is interested in experimenting with everything that shows up in the cracks.
The design caravan Open Source Publishing invites you for a design education experiment this summer "” from 26 until 30 August 2013
By and large, graphic design students bring a laptop to school, (...)
OSP (Open Source Publishing) is a graphic design collective that uses only Free, Libre and Open Source Software. At the first OSP Public Meet you are invited to finally discover 9000 km of (...)
For the annual art book fair PA/PER VIEW, Agency (Kobe Matthijs) speculates on the question: How to include book making in art practices? How are typeface designers, book binders, lay-outers, (...)
A two day workshop on F/LOSS cartographic tactics
Even if cartography is generally produced from a bird’s eye perspective, details cannot be drawn from a remote location; they must be (...)
5 members of the design-collective OSP travel to Ho Chi Minh City in Vietnam to participate in Open Design Week. From 3-10 April they tour through the Mekong Delta to meet local F/LOSS fans (...)
A two day workshop on F/LOSS cartographic tactics at the Israeli Center for Digital Art in the framework of the International Conference ’Open Sources versus Military Culture?’ organised by Tsila (...)
The theme of the 2010 edition of the Make Art festival is in-between design: rediscovering collaboration in digital art. OSP will give a presentation and will be part of the exhibition with the (...)
The Constant book Tracks in elect(ron)ic fields won a Fernand Baudin Prize in 2009. This month, the accompanying exhibition travels to Paris for the avant-première of a tour throughout (...)
July 1st marks the long awaited launch of OSP-foundry, a small but growing collection of Libre Fonts designed by OSP with other type collaborators. Complete typefaces, typographic thoughts, works (...)
As invited guest to the Empyre mailinglist, Andrew Murphie, Mat Wall" Smith and OSP will discuss design in relation to this months’ topic Publishing In Convergence.
From the introduction by (...)
It's such a pleasure to be able to contribute to this blog (again) and
to announce my residency period at OSP here. :--)
From a very nice freshly installed desk in the back of the OSP studio,
I'm taking the time to reflect and write about design
practices that actively question their way of working, both in relation
to the tools they use and from an interest in collective practices.
The desk that I am working from is a slightly wobbly very nice prototype
of an open source desk, which in a way resonates with me doing a
proto-residency at OSP between April and June 2023,
to explore how such format could possibly work out for them.
Since 2016, I have been working with F/LOSS publishing tools as well,
mostly in the context of a collective space called
Varia in Rotterdam. There, my practice of design
and publishing crossed with questions emerging from feminist approaches
and collective infrastructure. At Varia we run a collective digital
infrastructure for ourselves and accidentally also for nodes and people
around us. We work with a set of publishing tools such as
octomode,
logbot,
a Multifeeder,
wiki-to-print and
distribusi. With these
tools we made things such as the SomeTimes/Af en
toe and Toward a Minor
Tech. We started to refer
to these ways of working as resonant publishing and became interested
in finding minimal viable approaches for collective work. Next to
working on/with software and publications, Varia also organises collective learning sessions
and other type of events, such as the Publishing
Partyline, the Read
and Repair series, or the
Feminist Hack
Meetings.
While scrolling through the OSP archives during this first week of my residency, I found a blog post written by former member Harrison in 2006 called Ok, it is time now., in which he writes: "Is it possible to get a graphic design professionnal workflow with open source softwares?". Now, 17 years of OSP practice later, there is a lot to speak about and many perspectives to take. And while I'm personally not too interested to work from the question when a practice is "professional" (or not), it feels important to try to articulate (again) what implications this way of working has today.
I will work from the lens of (inter-)dependency relations and focus
on how they shape these design and publishing practices in specific
ways. You can think of (inter-)dependency between for example
practitioners, tools, web standards, and the community of practice
around F/LOSS design in Europe (and/or beyond).
Where do these practices (inter-)depend on?
Which stories or moments in time make (inter-)dependency relations visible?
What does it mean, really, to inter-dependent on someone or something else?
How to understand the difference between dependency, inter-dependency, in-dependency, or other variations?
How can design or publishing practitioners co-shape their dependencies?
What makes these practices precarious (or not)?
And how does F/LOSS based and collective work have an impact on working conditions?
Or, to phrase it differently: what can be (re)learned from operating shoulder-to-shoulder (or not)?
I'm writing "(inter-)dependency" on purpose in this way btw, as there
are probably many examples to be encountered in this research where it
is difficult to unravel who depends on who exactly, and when or how a
dependency turns, or could turn, into a multi-directional situation and
become an inter-dependency.
Concretely, I will depart from a moment in time that has a big impact on
the practice of OSP: the story around the CSS Regions, a CSS property
that was removed from modern browsers in 2013, triggering 10 years of
html2print practice based on workarounds and alternate technological
realities.
Publishing environments such as web-to-print are being held together
with awkward and joyful hacks, and I'm looking forward to spend time with them.
And each morning when I arrive at the OSP studio, I am reminded to cherish such mini-inventions.
Report written by our friend Manetta Berends from Varia
It was a last minute decision to join this year’s LGM. Until the very last moment we weren’t sure if we could make it. In the end Stéphanie, Ludi, Pierre and I (Manetta) joined on the Friday and followed most of Saturday’s programme. We borrowed a car from a friend (thanks Nicolas for the car!), had a last glass in a Supra Brussels café, went one-more-time to the toilet and zoefff, off we were, on the road to Saarbrücken, following the Belgium, French and German highways south/eastwards to this year’s LGM.
Passenger seat: never miss a moment to work!
This edition presented a range of incisive questions around F/LOSS practices, regarding their vocabularies, (political) values and the need for advocacy or arguments to introduce F/LOSS practices in other environments. Different presentations, workshops and conversations touched upon these questions, such as Manufactura Independente’s thoughts about terminology, Livio Fania’s five profiles of users and their concerns, Larisa Blazic’s workshop around Bauhaus and Libre Graphics, Eylul Dogruel’s presentation on the open source tools that she uses in her photography classes, or the multiple strategies to introduce F/LOSS to students that were discussed during the 80column educators gathering initiated by ginger coons and Larisa Blazic. Notes of that conversation can be found here: https://pad.vvvvvvaria.org/lgm-floss-educator-bof.
It was cool to see these questions appear throughout the programme, next to the always wide range of presentations of tools, technical details and various practices.
Manufactura Independente, which is the name of the design studio of Ana Isabel Carvalho and Ricardo Lafuente, presented different vocabularies used by graphic designers using or working on F/LOSS. Their remarks specifically concerned the ideologies and connotations of the terms open design and open source design. In the case of open design, they stated how the word open is a very ambiguous term, leaving too much space to be misunderstood as freedom in the sense of individual liberty or free in the sense of gratis products. Using the term open source design is in their view a more precise way to describe a practice, as it particulary points to a field of software development. It is a term that is for example used by the Open Source Design initiative, which aims to connect designers to open source software projects. However, Ana and Ricardo openly questioned how useful the term still is, in case the design work for an open source project is produced with proprietary software. Apparently this was the case in the example of Ubuntu, where its design department worked on Mac OS using the Adobe Suite. This way of contributing to a software project is not sufficient in the eyes of Ana and Ricardo, who see the use of F/LOSS in a daily design practice as the most vigorous type of contribution to a larger ecosystem. Which is a very fair point! I read the presentation of Ana and Ricardo mostly as a trigger for further conversations, to unravel the multiplex of nuances and ideologies that are at play within the F/LOSS design field and to call for a need of precision when choosing words. Also for Manufactura Independente the question of what term to use to describe their practice is still an unresolved one. They left the audience with two (explicitly questionmarked) proposals that they currently consider to use: libre design and F/LOSS design.
After a first day of this year’s LGM, which was the Friday in our case, Pierre happily noted how the vector had received already quite a bit of attention. And indeed, it is not often the case that the curvy, bendable drawing instrument wins it from the always at hand bitmap tools during an LGM. Raph Levien presented a new spline as an additional type of curve next to the Bezier, Hobby or Spiro curves; Pascal Bies presented the vector drawing tool ommpfritt that makes it possible to draw vectors in an object-oriented way, Ricardo Lafuente and Stuart Axon presented the Python drawing library Shoebot which supports exporting to SVG.
Pascal Bies presenting ommpfritt
And Pierre himself shared a workflow to make a multipage color-separated publication in Inkscape, featuring illustrations made with Raph Levien’s Spiro curve. The metaphorical loop crossed its own curve! And in line of all these control-pointed shapes, Stéphanie, Quentin and I took a moment to present this year’s ideas behind the (now ongoing) Relearn curve.
Pierre, maître de son corps.
It was great to be introduced to Raph Levien’s long tail of research and many years of contributions to vector drawing tools. During this LGM he presented a follow up on the playful and stubborn spiro curve: a yet-to-be-named new spline, which is another word for the algorithm and math behind the bending of a curve. This new spline will be less expressive and easier to learn (compared to the famous bezier curve) and less “wild” (compared to the spiro curve). An HTML demo of this new spline can be found online at https://spline.technology/demo/. More material, including a first research paper, can be found at https://github.com/raphlinus/spline-research. We can’t wait to give this spline a try!
Gro[o|u]pie picture with Raph Levien.
The last hours of our LGM were filled with a workshop on Paged.js, a browser-based layout rendering tool to make and preview paged media in a web environment. Workshop host Julie Blanc described how Paged.js is built as a polyfill, which is a software strategy to use CSS standards from W3C which are not implemented yet in either old browsers or current browsers. The idea of Paged.js as a polyfill is to extend the paged media functionalities of a browser and fill the gaps of missing support when needed. Julie showed us how you can easily insert running headers with chapter titles in your pages, how to generate a table of content with page numbers, or how to define varying layouts for different sections or elements of a book. Although we were curious to hear about support for the option to work with multiple threads in one document, we were also quite impressed by the promising robustness of the tool.
It was a sweet trip with sweet people and a good occasion to see familiar faces again while meeting some new ones as well. Many thanks go to the local organizers of this edition (thank you!) and the international organizing team (thanks!).
Report written by our friend Manetta Berends from Varia
It was a last minute decision to join this year’s LGM. Until the very last moment we weren’t sure if we could make it. In the end Stéphanie, Ludi, Pierre and I (Manetta) joined on the Friday and followed most of Saturday’s programme. We borrowed a car from a friend (thanks Nicolas for the car!), had a last glass in a Supra Brussels café, went one-more-time to the toilet and zoefff, off we were, on the road to Saarbrücken, following the Belgium, French and German highways south/eastwards to this year’s LGM.
Passenger seat: never miss a moment to work!
This edition presented a range of incisive questions around F/LOSS practices, regarding their vocabularies, (political) values and the need for advocacy or arguments to introduce F/LOSS practices in other environments. Different presentations, workshops and conversations touched upon these questions, such as Manufactura Independente’s thoughts about terminology, Livio Fania’s five profiles of users and their concerns, Larisa Blazic’s workshop around Bauhaus and Libre Graphics, Eylul Dogruel’s presentation on the open source tools that she uses in her photography classes, or the multiple strategies to introduce F/LOSS to students that were discussed during the 80column educators gathering initiated by ginger coons and Larisa Blazic. Notes of that conversation can be found here: https://pad.vvvvvvaria.org/lgm-floss-educator-bof.
It was cool to see these questions appear throughout the programme, next to the always wide range of presentations of tools, technical details and various practices.
Manufactura Independente, which is the name of the design studio of Ana Isabel Carvalho and Ricardo Lafuente, presented different vocabularies used by graphic designers using or working on F/LOSS. Their remarks specifically concerned the ideologies and connotations of the terms open design and open source design. In the case of open design, they stated how the word open is a very ambiguous term, leaving too much space to be misunderstood as freedom in the sense of individual liberty or free in the sense of gratis products. Using the term open source design is in their view a more precise way to describe a practice, as it particulary points to a field of software development. It is a term that is for example used by the Open Source Design initiative, which aims to connect designers to open source software projects. However, Ana and Ricardo openly questioned how useful the term still is, in case the design work for an open source project is produced with proprietary software. Apparently this was the case in the example of Ubuntu, where its design department worked on Mac OS using the Adobe Suite. This way of contributing to a software project is not sufficient in the eyes of Ana and Ricardo, who see the use of F/LOSS in a daily design practice as the most vigorous type of contribution to a larger ecosystem. Which is a very fair point! I read the presentation of Ana and Ricardo mostly as a trigger for further conversations, to unravel the multiplex of nuances and ideologies that are at play within the F/LOSS design field and to call for a need of precision when choosing words. Also for Manufactura Independente the question of what term to use to describe their practice is still an unresolved one. They left the audience with two (explicitly questionmarked) proposals that they currently consider to use: libre design and F/LOSS design.
After a first day of this year’s LGM, which was the Friday in our case, Pierre happily noted how the vector had received already quite a bit of attention. And indeed, it is not often the case that the curvy, bendable drawing instrument wins it from the always at hand bitmap tools during an LGM. Raph Levien presented a new spline as an additional type of curve next to the Bezier, Hobby or Spiro curves; Pascal Bies presented the vector drawing tool ommpfritt that makes it possible to draw vectors in an object-oriented way, Ricardo Lafuente and Stuart Axon presented the Python drawing library Shoebot which supports exporting to SVG.
Pascal Bies presenting ommpfritt
And Pierre himself shared a workflow to make a multipage color-separated publication in Inkscape, featuring illustrations made with Raph Levien’s Spiro curve. The metaphorical loop crossed its own curve! And in line of all these control-pointed shapes, Stéphanie, Quentin and I took a moment to present this year’s ideas behind the (now ongoing) Relearn curve.
Pierre, maître de son corps.
It was great to be introduced to Raph Levien’s long tail of research and many years of contributions to vector drawing tools. During this LGM he presented a follow up on the playful and stubborn spiro curve: a yet-to-be-named new spline, which is another word for the algorithm and math behind the bending of a curve. This new spline will be less expressive and easier to learn (compared to the famous bezier curve) and less “wild” (compared to the spiro curve). An HTML demo of this new spline can be found online at https://spline.technology/demo/. More material, including a first research paper, can be found at https://github.com/raphlinus/spline-research. We can’t wait to give this spline a try!
Gro[o|u]pie picture with Raph Levien.
The last hours of our LGM were filled with a workshop on Paged.js, a browser-based layout rendering tool to make and preview paged media in a web environment. Workshop host Julie Blanc described how Paged.js is built as a polyfill, which is a software strategy to use CSS standards from W3C which are not implemented yet in either old browsers or current browsers. The idea of Paged.js as a polyfill is to extend the paged media functionalities of a browser and fill the gaps of missing support when needed. Julie showed us how you can easily insert running headers with chapter titles in your pages, how to generate a table of content with page numbers, or how to define varying layouts for different sections or elements of a book. Although we were curious to hear about support for the option to work with multiple threads in one document, we were also quite impressed by the promising robustness of the tool.
It was a sweet trip with sweet people and a good occasion to see familiar faces again while meeting some new ones as well. Many thanks go to the local organizers of this edition (thank you!) and the international organizing team (thanks!).
I've been meaning to document my OSM to SVG process for a while now, I just had to run the process again recently, so here was a new chance to take screenshots along the way. The basic idea is to process a portion of Open Street Map data into a vector paths and shapes. One of the ways I have been able to accomplish this is using an xml conversion tool, in my case, xsltproc but there are many others. Before we can convert the dot osm xml, here is how I obtain the osm data in the first place:
Note: this process is greatly aided by this page on the OSM wiki, but a lot of the info and links are out of date, hence this document. It remains a good place to start. [https://wiki.openstreetmap.org/wiki/Osmarender/Convert_osm_data_from_OSM_file_to_an_SVG_image]
Getting the data
It is possible to extract bits of OSM using the API, making a GET request in this format https://api.openstreetmap.org/api/0.6/map?bbox=-0.5,51.3,-0.4,51.4 but if your request is too big, the OSM api will refuse to treat your request. Most of the time I simply download a full country file from geofabrik http://download.geofabrik.de/europe.html
about the bounding box
Just for reference, a selection area can in this case be called the bounding box. In my experience, most tools that function with OSM expect the bounding box to be set as left,bottom,right,top. Depending on the api or tool, those values will be differenly seperated, but that order seems to be consistent, thank goodness.
Mine was of these values:
-6.59 52.87 -6.21 53.23 meaning left=-6.59 bottom=52.87 right=-6.21 top=53.23
I know there probably are better ways to do this, but I still get my box coordinates from this online tool from geofabrik again: http://tools.geofabrik.de/calc/#type=geofabrik_standard&bbox=-6.588098,52.879038,-6.214317,53.220207&tab=1&proj=EPSG:4326&places=2
That tool only gives you the coordinates, now we need to cut out our selection from the large file downloaded earlier.
cut out the piece you need
osmosis is used to cut out section of the map for easier work using a command like this, assuming you want to work with the compressed file* :
you could also uncompress the file, and use the desktop Java OSM editing tool called JOSM. With JOSM, you can open and edit (it's main purpose) OSM data directly.
convert the OSM xml to svg using stylesheets from osmarender
Now comes the complex part of transforming OSM xml into SVG xml. See, OSM after all is basically one enormous xml database. This is an interesting but potentially problematic thing, long term. See emacsen's post about the serious troubles of OpenStreetMaps
If you're reconciled with OSM for now, we need to convert the section of the map DB to svg, for which we need to rule-render the OSM xml to SVG xml. This is done using a stylesheet that can be obtained from osmarender.
OSMarender seems to have an xml processor built in but I couldn't get it to function on my system so I used *xsltproc* which reads rules from an xsl file + a stylesheet to convert all xml to all xml.
OSMarender gives us access to a load of zoom-level stylesheets. However when I tried to obtain these using my packet manager, all official links were dead, luckily, clones were made, so get yourself a copy of the OSMarender stylesheets from a place like this https://github.com/pnorman/osmarender-testclone
the xsltproc manual suggest this command structure as a general example: xsltproc -o map.svg osmarender.xsl osm-map-features-z17.xml but in my case, I use the xml fields to select a data file, so the command looks a bit more like this:
!! Depending on the zoom level you choose, and the size of your bb, this operation can take multiple hours, be aware of this, and keep an eye on your system, the cpus will have pretty intense xml crunching to deal with !!
Note that this stylesheet includes a section of options in the file header that looks like this:
Contour lines
Unfortunately, the OSM db does not include any contour lines data. Thankfully, out bounding box can be a query element for earthexplorer using phyghtmap that will give us a .osm export of the bounding box we're interested in.
phyghtmap --earthexplorer-user=colm --earthexplorer-password=********** -a -6.59:52.87:-6.21:53.23
phyghtmap expects left:bottom:right:top as noted above
phyghtmap will need login credentials from earthexplorer, so you'll need an account from there before you can download any of that data. I'm unsure how phyghtmap queries earthexplorer exactly, but in my case, the bounding boxes I set often result in multiple files. To merge the two or more files that your phyghtmap query returns, I use JOSM, import both datasets as different layers and then merge them from the program. This is not exactly a necessary step, but as I'm bringing in the contour lines as a separate svg layers, when merged, the contour lines layer will be exactly the same size as the OSM data we converted earlier, meaning it can be easily aligned to the baselayer.
Next, you need to convert this other OSM-type data into svg also, using a similar xsltproc command. Here this repo was essential again https://github.com/pnorman/osmarender-testclone
merging the two
Bringing together your different svg layers is done with inkscape of course and now you have multiple paths to chose to handle your data. If you're just doing on screen renders, then I believe this text will be enough for you. If you intent is flat printing, I can't help you there yet, as my interests have been around plotting these maps; for this read on.
First of all, I had to (re)discover some inkscape tricks to help me work on the different parts of the maps. I listed some of these below, I may add to this list later:
resize svgs + content to different sizes
https://graphicdesign.stackexchange.com/questions/6574/in-inkscape-resize-both-the-document-and-its-content-at-the-same-time
Find replace tool in inkscape:
CTRL + f, open options, uncheck all types, select text or paths to create a dynamic selection that can then be moved to a separate layer.
osmarender follows SVG practices pretty nicely, but if you're tying to convert objects to paths, inkscape will complain about working cloned objects. The
I'm still looking for a way to save one single inkscape layer as it's own SVG, any ideas on this topic are appreciated.
Later, I process the SVGs either to HPGL or to GCODE. If your machine uses the latter, I suggest using the ! now built in ! gcodetools extension. If gcode in inkscape is your path, I personally got to grips with the extension with this published method: https://www.norwegiancreations.com/2015/08/an-intro-to-g-code-and-how-to-generate-it-using-inkscape/
I've been meaning to document my OSM to SVG process for a while now, I just had to run the process again recently, so here was a new chance to take screenshots along the way. The basic idea is to process a portion of Open Street Map data into a vector paths and shapes. One of the ways I have been able to accomplish this is using an xml conversion tool, in my case, xsltproc but there are many others. Before we can convert the dot osm xml, here is how I obtain the osm data in the first place:
Note: this process is greatly aided by this page on the OSM wiki, but a lot of the info and links are out of date, hence this document. It remains a good place to start. [https://wiki.openstreetmap.org/wiki/Osmarender/Convert_osm_data_from_OSM_file_to_an_SVG_image]
Getting the data
It is possible to extract bits of OSM using the API, making a GET request in this format https://api.openstreetmap.org/api/0.6/map?bbox=-0.5,51.3,-0.4,51.4 but if your request is too big, the OSM api will refuse to treat your request. Most of the time I simply download a full country file from geofabrik http://download.geofabrik.de/europe.html
about the bounding box
Just for reference, a selection area can in this case be called the bounding box. In my experience, most tools that function with OSM expect the bounding box to be set as left,bottom,right,top. Depending on the api or tool, those values will be differenly seperated, but that order seems to be consistent, thank goodness.
Mine was of these values:
-6.59 52.87 -6.21 53.23 meaning left=-6.59 bottom=52.87 right=-6.21 top=53.23
I know there probably are better ways to do this, but I still get my box coordinates from this online tool from geofabrik again: http://tools.geofabrik.de/calc/#type=geofabrik_standard&bbox=-6.588098,52.879038,-6.214317,53.220207&tab=1&proj=EPSG:4326&places=2
That tool only gives you the coordinates, now we need to cut out our selection from the large file downloaded earlier.
cut out the piece you need
osmosis is used to cut out section of the map for easier work using a command like this, assuming you want to work with the compressed file* :
you could also uncompress the file, and use the desktop Java OSM editing tool called JOSM. With JOSM, you can open and edit (it's main purpose) OSM data directly.
convert the OSM xml to svg using stylesheets from osmarender
Now comes the complex part of transforming OSM xml into SVG xml. See, OSM after all is basically one enormous xml database. This is an interesting but potentially problematic thing, long term. See emacsen's post about the serious troubles of OpenStreetMaps
If you're reconciled with OSM for now, we need to convert the section of the map DB to svg, for which we need to rule-render the OSM xml to SVG xml. This is done using a stylesheet that can be obtained from osmarender.
OSMarender seems to have an xml processor built in but I couldn't get it to function on my system so I used *xsltproc* which reads rules from an xsl file + a stylesheet to convert all xml to all xml.
OSMarender gives us access to a load of zoom-level stylesheets. However when I tried to obtain these using my packet manager, all official links were dead, luckily, clones were made, so get yourself a copy of the OSMarender stylesheets from a place like this https://github.com/pnorman/osmarender-testclone
the xsltproc manual suggest this command structure as a general example: xsltproc -o map.svg osmarender.xsl osm-map-features-z17.xml but in my case, I use the xml fields to select a data file, so the command looks a bit more like this:
!! Depending on the zoom level you choose, and the size of your bb, this operation can take multiple hours, be aware of this, and keep an eye on your system, the cpus will have pretty intense xml crunching to deal with !!
Note that this stylesheet includes a section of options in the file header that looks like this:
Contour lines
Unfortunately, the OSM db does not include any contour lines data. Thankfully, out bounding box can be a query element for earthexplorer using phyghtmap that will give us a .osm export of the bounding box we're interested in.
phyghtmap --earthexplorer-user=colm --earthexplorer-password=********** -a -6.59:52.87:-6.21:53.23
phyghtmap expects left:bottom:right:top as noted above
phyghtmap will need login credentials from earthexplorer, so you'll need an account from there before you can download any of that data. I'm unsure how phyghtmap queries earthexplorer exactly, but in my case, the bounding boxes I set often result in multiple files. To merge the two or more files that your phyghtmap query returns, I use JOSM, import both datasets as different layers and then merge them from the program. This is not exactly a necessary step, but as I'm bringing in the contour lines as a separate svg layers, when merged, the contour lines layer will be exactly the same size as the OSM data we converted earlier, meaning it can be easily aligned to the baselayer.
Next, you need to convert this other OSM-type data into svg also, using a similar xsltproc command. Here this repo was essential again https://github.com/pnorman/osmarender-testclone
merging the two
Bringing together your different svg layers is done with inkscape of course and now you have multiple paths to chose to handle your data. If you're just doing on screen renders, then I believe this text will be enough for you. If you intent is flat printing, I can't help you there yet, as my interests have been around plotting these maps; for this read on.
First of all, I had to (re)discover some inkscape tricks to help me work on the different parts of the maps. I listed some of these below, I may add to this list later:
resize svgs + content to different sizes
https://graphicdesign.stackexchange.com/questions/6574/in-inkscape-resize-both-the-document-and-its-content-at-the-same-time
Find replace tool in inkscape:
CTRL + f, open options, uncheck all types, select text or paths to create a dynamic selection that can then be moved to a separate layer.
osmarender follows SVG practices pretty nicely, but if you're tying to convert objects to paths, inkscape will complain about working cloned objects. The
I'm still looking for a way to save one single inkscape layer as it's own SVG, any ideas on this topic are appreciated.
Later, I process the SVGs either to HPGL or to GCODE. If your machine uses the latter, I suggest using the ! now built in ! gcodetools extension. If gcode in inkscape is your path, I personally got to grips with the extension with this published method: https://www.norwegiancreations.com/2015/08/an-intro-to-g-code-and-how-to-generate-it-using-inkscape/
Septième saison associés avec le Théatre de la Balsamine!
Et pour celle-ci, sous le signe obligé mais d'une certaine jouissance, l'arte povera numérique d'OSP en auteur visuel et à l'écriture de modes d'emploi.
Déplier une table pliante, bricoler un piège à mouche, tenir les voiles pendant la tempête, nouer ses lacets avec un dead knot,
faire un cunnilingus, construire une barricade... Le tout en courbes spiro torréfiées bruit imagemagick.
↑ Entre autres références, Les économies au féminin, Skip, 1980
Le poster dans le métro en prémices Inkscape, avec son historique fournis de sept saisons de logos.
Septième saison associés avec le Théatre de la Balsamine!
Et pour celle-ci, sous le signe obligé mais d'une certaine jouissance, l'arte povera numérique d'OSP en auteur visuel et à l'écriture de modes d'emploi.
Déplier une table pliante, bricoler un piège à mouche, tenir les voiles pendant la tempête, nouer ses lacets avec un dead knot,
faire un cunnilingus, construire une barricade... Le tout en courbes spiro torréfiées bruit imagemagick.
↑ Entre autres références, Les économies au féminin, Skip, 1980
Le poster dans le métro en prémices Inkscape, avec son historique fournis de sept saisons de logos.
It is with great sadness that we learned of the unexpected death of our board member Bram Crevits.
We will miss Bram’s energy and his persistent interest in the parcours of OSP. We first met him in 2009, as director of the Cimatics festival for which we made a typeface. Many encounters followed, among which the Open Tools workshop Bram organised at the KASK in Gent. We were honoured when Bram accepted to be a board member when we formed an association. Most recently Bram has connected OSP with the “Color research” project between art and science, where we experiment on a playground drawn by a plotter that uses a set of colours based on living organisms—like the algues produced by María Boto Ordóñez in her Biolab at KASK.
Our condolences go to his family and close friends. A non-religious ceremony will be held this Saturday 7 April at 10:30 am - KASK - Zwarte Zaal / Louis Pasteurlaan 2 - 9000 Gent.
Lieve Bram,
Dearest Bram,
Je omarmde projecten voor een betere wereld, vaak was je de eerste. Je hebt ons je vertrouwen geschonken, je hebt ons project verdedigd, je scherpe blik heeft ons vooruit geholpen. Zoals wij zijn er zovelen. Vandaag treuren we samen.
You embraced projects for a better world, often you were the first. You gave us your confidence, you defended our project, and your sharp mind helped us advance. And there are so many like us. Today we mourn together.
↑ Entre autres références, Les économies au féminin, Skip, 1980
