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 (...)
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/
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.
Dirty variables workshop is about variable fonts with some distance and manual interpolation (with stroke fonts inside), with La Cambre master students in type media, Brussels, on the 26 + 27 March 2018.
We are using Fonttools and the ttx format, which is a clear xml dump of every table present in a (variable) font. See github.com/fonttools/fonttools.
All the documentation we gathered before and during the workshop follows, in a quite rough way!
Variables fonts past and present
OpenType Font Variations is the new feature of the OpenType Font Format specification version 1.8. The first public announcement of this new version happened in Warsaw during ATypI 2016.
To be a bit more clear on what and who :
OpenType format was developped by Microsoft, Apple and Adobe since 1996, to stop the war between Postscript (Adobe) and Truetype (Microsoft + Apple) formats. Because of their need for emoji fonts, Google join the group more recently. Apple and Microsoft share the same concern.
«The new OpenType format allows for a single file to contain an entire family, or multiple related families, of font instances.
Previously if you wanted to license an entire font family with a range of weights for your website (like Light, Regular, Medium, Bold, Extra Bold, and Ultra) the type foundry would generate a separate font file for each style. But now it's possible for type foundries to put all of these styles into a single file.»
— from cjtype.com/dunbar/variablefonts, an article on Dunbar “n”, a single glyph font 'n' as the "first" var font !
To dive into the variable fonts also brings us to revisit the different spaces and tables that are around and contained in a font.
In the mid-nineties, Adobe has proposed Multiple Masters fonts, an interpolation system to generate fonts from two masters embeded into the font itself.
In the same time, Apple introduce a more refined but similar system called Apple Advanced Typography (AAT).
Both system proves the technical feasability but were not largely used by designers.
https://en.wikipedia.org/wiki/Multiple_master_fonts - https://en.wikipedia.org/wiki/Apple_Advanced_Typography
Designers have not catch up these tools, but type designers begon to use the same kind of tools, but externally of the font, in the font editors* mainly. The designation “design space” one of way to name it. This space gathers or deploys the informations describing the relations between the masters, the sources of a font. It defines for exemples the relations between the light and the bold version of a same font. A design space store all the datas needed for variable font interpolations. It it was is not into the font, meaning it is not about the drawing of the font, the meta infos...
We could say that now with Open Type 1.8 specification, this design space become more concretely embeded into the font and not depending on extrapolation tools. The design space is called variation space in the specification and it is the range of variability in the variable font.
The design space is defined by
axes (names and dimensions of the axes)
sources (links to the ufo, otf, ttf...)
instances (the steps you wants to generate)
rules (sketche on how conditional stuff could work)
Axis names have to be a string, that can't be longer than 4 letters. Axis tags are predefined axes. 'wght': weight, 'wdth': width, 'ital': italic, 'slnt': slant, 'opsz': optical size.
To ensure a good start of the technology (everyone was remembering the failed attempt of MM and AAT...), the four giants agreed to announce it in one go, along with external commenters
Erik van Blokland from Letterror, part of the OpenType 1.8 comitee
Just Van Rossum from Letterror, (probably) the creator of ttx, neffew of Guido van Rossum, programmer who creates Python
Thomas Phinney, font and typography expert and consultant. In his day job, Thomas is President of FontLab, the font creation/editing software company. He is also treasurer of ATypI, the international typographic association. From 1997-2008 he did type at Adobe, lastly as product manager for fonts and global typography. After that he spent five years as senior technical product manager (a.k.a. “guru”) of fonts and typography at Extensis, including managing the font library for the WebINK web font solution. His typeface Hypatia Sans is an Adobe Original (with help from Robert Slimbach, Miguel Sousa and Paul Hunt). His latest typeface is the Kickstarter-funded Cristoforo.
John Hudson of Tiro Typeworks, design wonderful top-of-the-line fonts in Vancouver. Tiro is increasingly involved in font technologies, and are avid advertisers for OpenType and work often with Microsoft and Linotype on projects. John has created or collaborated on typefaces for many writing systems. He is an expert contributor to Unicode, and a member of the W3C Web Fonts Working Group.
Adam Twardoch and Yuri Yarmola : programmers of FontLab
Georg Seifert and Rainer Erich Scheichelbauer : programmers of Glyphs
(Yes, Twitter remains a good node for typographic discussions)
["Of course there are skeptics and believers. A very interesting statement from Indra Kupferschmid in her talk during this year’s Robothon (2018) was when she warned type designers of the sometimes boring results of this new technology. I’m one of the believers and in this article I’ll try to explain why" - Irene Vlachou] (https://www.type-together.com/index.php?action=portal/viewContent&cntId_content=3614)
Gijs and me joined L'édition comme expérience at La Villa Arson last week.
Monday 12th and Tuesday 13th of March, two days to thread relations from Other ways, Consciousness raising to Montessori's esthetic, au pays de Célestin Freinet.
In parallel to the conferences and library books speaking, we crashed into learning by doing with a mixed group of students (from La Villa and Drap BTS).
As their first lines of html and css we built a live publication of the event: gathering texts from the presentations, pictures, indexes of books and drawings.
Our kit: Ethertoff on a raspberry, markdown, html, and css. In preparation for the event we designed the programme, a webpage using CSS grids that can be printed and folded into a booklet.
Based on OSP experiences during relearn, What's the Matter with Cooperation and f-u-t-u-r-e ethertoff felt like a fitting tool. We brought it installed on a raspberry pi only accessible from the local network. For only two days this added a layer of software but also brings the question of the infrastructure or the omniprescence of the cloud: “What? You've shut down the raspberry and now everything's gone from the web?”.
CSS grid appeared as a new playground for us and also as web layout track opening good discussion between the InDesign swiss grid and the web flow.
Our enthousiasm with it still hit quite some bricks in layouting for the print in such a quick time but Gijs already started some scripts to unfold the rows according to the lenght of the content.
We recognized ourselves in the setup of Freinet, put the machine in the middle of the room and starting directly with complexity.
Thanks Céline Chazalviel for the organisation and invitation. Bravo aux étudiant.e.s!
Gijs and me joined L'édition comme expérience at La Villa Arson last week.
Monday 12th and Tuesday 13th of March, two days to thread relations from Other ways, Consciousness raising to Montessori's esthetic, au pays de Célestin Freinet.
In parallel to the conferences and library books speaking, we crashed into learning by doing with a mixed group of students (from La Villa and Drap BTS).
As their first lines of html and css we built a live publication of the event: gathering texts from the presentations, pictures, indexes of books and drawings.
Our kit: Ethertoff on a raspberry, markdown, html, and css. In preparation for the event we designed the programme, a webpage using CSS grids that can be printed and folded into a booklet.
Based on OSP experiences during relearn, What's the Matter with Cooperation and f-u-t-u-r-e ethertoff felt like a fitting tool. We brought it installed on a raspberry pi only accessible from the local network. For only two days this added a layer of software but also brings the question of the infrastructure or the omniprescence of the cloud: "What? You've shut down the raspberry and now everything's gone from the web?".
CSS grid appeared as a new playground for us and also as web layout track opening good discussion between the InDesign swiss grid and the web flow.
Our enthousiasm with it still hit quite some bricks in layouting for the print in such a quick time but Gijs already started some scripts to unfold the rows according to the lenght of the content.
We recognized ourselves in the setup of Freinet, put the machine in the middle of the room and starting directly with complexity.
Thanks Céline Chazalviel for the organisation and invitation. Bravo aux étudiant.e.s!
Welcome to the new OSP blog! Happy to have you here. This post is titled reviving the OSP blog because in the last 5 years or so, the structure of our website has drastically changed. When this blog was started, on this day in 2006, Harrisson asked the question that has fueled this collective to this day. The point of this article is not to answer Harrisson's question, but rather to take the opportunity to look back a tiny bit, as this migration has exposed things to me that I never got the chance to see in the old blog.
The site changed a little over the next year or two, with it's last update to current form in 2016. Eric wrote about the precise proceedings of this on his own blog: i.liketightpants/and/. Somewhere in the mix of all this was also the move from the original domain name we had inhabited: ospublish.constantvzw.org to the current one: osp.kitchen. As the website was now an ambitious growing django app with a copy of all the git repositories we worked on, we moved to our own VPS to stop putting too much weight on the constant server.
All this meant that the blog, the original OSP site took a back seat. We kept publishing to it, but the rhythm clearly dropped. In fact, 2013 was possibly the year during which we posted the least to the blog. We attempted a rescue by fixing up the theme of the wordpress blog to fit in better with the rest of the main site, but there was nothing for it, we got too busy and had enough trouble keeping the icebergs properly updated. Bit by bit the plugins got deteriorated, and the wordpress admin felt more and more foreign. We're not really writing blog posts anymore. But this post is here to try to put a stop to this, and along with it, a whole new way of managing the blog.
In October, I found out that my favorite static site generator Pelican actually had a tool to import .xml exported wordpress archives. The script obviously heavily depends on pandoc but has recently fallen behind pandoc's latest usage models, so the import was not as clean as the tool said it would be. Not to fear, a fewregexscripts later and most of the wounds were patched.
In the process, I had to make a decision to facture Wordpress's liberal attitude towards categories and tags. Seemingly, WP allows a post to be part of multiple categories, as well as have loads of tags. The latter I have no issue with, the former, when moving to a file based static site generator confuses things deeply. So I squashed any category past the first one into tags, and now categories are based on what folder they come out of, which I thoroughly appreciate in pelican. Still, I screwed up one of the scripts somewhere, there are a lot of new single tags that are actually resulting from missing commas. This one, or this one, or this one.
Lastly, I hope this move lets us use the blog with more flexibility. It's markdown file based, so we could be simply publishing other documents we've written here, or actually use it as an archive. Gitlab pages actually takes care of SSGs with Pelican so that's one less thing to worry about. We'll see how we export the generated content to somewhere on our own server in due time.
Forgive the last few code or style bleeds in the content, we're working on those!
Ce texte a été initialement écrit pour la revue Back
Office. Pour des raisons de format,
il n'y sera pas publié, mais nous sommes heureux de le partager ici avec
vous dans sa version longue.
HTML2PRINT SANS SAUCE
Depuis sa création en 2006, Open Source Publishing dessine des mises en
page et code avec des logiciels libres ou open source. Il s'agit d'abord
de questionner nos pratiques avec ces médiateurs omniprésents que sont
les outils numériques et les communautés dont ils sont issus. Alors que
la matérialité de l'informatique s'efface derrière des interfaces
«intuitives»^2^, le logiciel libre,
par sa nature ouverte, invite à saisir l'épaisseur culturelle des
formats, interfaces et usages.
Splines spirographiques, filtres ImageMagick ou lignes de commande sont
quelques-unes des rencontres qui ont changé notre manière d'appréhender
le vecteur, le bitmap ainsi que la manière de construire et de partager
nos propres outils. Mais pour ce qui est de la mise en page, nous nous
retrouvons face à un dilemme cornélien: celui d'avoir à choisir entre
d'un côté une approche essentiellement visuelle, incarnée par Scribus et
InDesign, et de l'autre une approche intégralement programmatique
incarnée par TeX, LaTeX ou Context.
Dans sa tentative de simuler la manipulation directe de l'objet final,
l'approche WYSIWYG se heurte aux limites du paradigme papier/ciseaux.
Prisonnière de l'héritage de Gutenberg, elle ignore le potentiel de
réinvention du média numérique. L'approche programmatique s'avère elle
aussi décevante car systématique et linéaire. Fonctionnant à sens
unique, du code vers le visuel, elle fonctionne bien pour mettre en page
des flux continus mais permet très difficilement de débrayer et de créer
des mises en pages plus articulées, notamment car le format final n'est
plus éditable.
Après nous être au départ plus particulièrement concentrés sur des
objets imprimés, nous avons commencé Ã investir le web comme espace de
publication. Ce qui nous séduit dans le design web est l'approche
collaborative ainsi que le va et vient qu'il permet entre design visuel
et design par le code. Populaires, ultra-documentés et basés sur des
formats ouverts élaborés par différents acteurs dans un souci de
dialogue ^3^ et de continuité,
les langages du web sont de véritables lingua franca: ils sont
éditables par de nombreuses manières, «à  la main» et via un large
spectre de logiciels visuels ou programmatiques. Le navigateur web,
pièce maîtresse, réunit en un même espace ces différentes approches.
Par sa nature distribuée (une page étant généralement le résultat de
l'agrégation de nombreuses ressources telles des feuilles de style ou
des images), les formats du web permettent un travail collaboratif entre
des personnes aux compétences diverses, contrastant avec l'approche
solitaire des logiciels comme InDesign ou Scribus.
À divers niveaux tous les membres d'OSP ont une pratique du web et cette
question revient : «Ne pourrions-nous pas utiliser les mêmes
méthodologies et outils pour le design imprimé?». Après un petit audit
nous décidons de nous lancer. Le premier projet sera pour le programme
annuel du Théâtre la Balsamine. Mais si un grand nombre de propositions
pour l'imprimé sont déjà prévues par les standards CSS, de nombreuses
fonctionnalités indispensables (traits de coupe, pagination, titres
courants…) ne sont pas encore implémentées dans les navigateurs web.
Pour palier à ces lacunes, nous compilons une série de recettes pouvant
désormais servir de gabarits pour de futurs projets. Nous l'intitulons
html2print.
image issue de la première présentation d'OSP d'utilisation d'HTML pour
des documents multi-pages, Libre Graphics Meeting 2013, Madrid
SAUCE COCKTAIL
Mars 2015, après deux années de pratique d'html2print en interne pour
diverses commandes graphiques, nous pensons que l'outil est prêt à être
«bêta-testé» par d'autres, notamment par des designers qui ne sont pas
nécessairement développeurs. L'occasion d'un workshop à la HEAR de
Strasbourg tombe à pic: quatre journées pour apprendre les bases HTML +
CSSÂ et produire un objet imprimé.
Par ses contraintes de tailles d'écrans multiple devices, la mise en
page web se doit d'être adaptative, quelque part consciente de
l'environnement dans lequel elle s'installe. De ce point de vue, elle
s'oppose au design imprimé où la plupart des interfaces traditionnelles
gardent nos mains fixées sur les blocs de Gutenberg. Nous proposons aux
étudiants d'expérimenter les media queries, conditions CSSÂ qui
adaptent le design d'un site en fonction du dispositif de lecture
(ordinateur, tablette, GSM…) ou de la taille de l'écran du lecteur.
La fluidité du HTML rend très facile le changement de format: un
changement dans les dimensions de la page et le reste coule. Pour épicer
la sauce, nous proposons aux étudiants de travailler sur un Etherpad
^4^ permettant de produire ces différents
formats à partir d'un même document. La taille de la fenêtre du
navigateur change le format de la page imprimée ainsi que son design.
Et, le fait de partager un seul et même document rend l'apprentissage de
HTML et CSS beaucoup plus excitant et rapide. Les étudiants apprennent
par eux-mêmes en voyant les changements des autres en direct.
Le *pad* de la feuille de styles commune
Pour profiter pleinement de l'outil, nous proposons de travailler Ã
partir d'un contenu d'une certaine longueur, avec plusieurs niveaux
d'informations. Nous glanons sur le projet
Gutenberg^5^ The Belgian Cook Book de
Mrs. Brian Luck, une compilation de recettes d'émigrés belges au
Royaume-Uni en 1915. L'avantage de cette archive étant que les livres y
sont proposés dans différents formats dont HTML.
La première journée est consacrée à un cours accéléré sur les
expressions rationelles (grep)^6^ et syntaxe
de base des langages HTML/CSS. Le jour suivant, des groupes ad hoc et
perméables se forment autour de plusieurs chantiers: nettoyage et
optimisation des contenus en utilisant des expressions rationnelles;
structuration sémantique des contenus HTML (titres, sous-titres, termes
techniques, listes, etc.) et enfin la définition des styles visuels
communs à tous les formats imprimables.
Puis, cinq équipes sont formées, chacune prenant en charge un format
d'impression: A7 → micro-format travaillant sur une mise en page en
miroir; A6 paysage → fiches de cuisine cannibale où les ingrédients sont
remplacés par des noms de personnes avec grep; 215×330mm → grand format
à consulter posé sur une table; 990×1075mm → affiches sérigraphiées avec
zoom sur les adverbes avec grep; multi-format → grâce à la propriété
float de CSS, les blocs de recettes coulent de gauche à droite comme
du texte, la mise en page s'adapte ainsi d'elle-même selon la taille du
livre. Une sixième équipe se consacre à la réalisation d'illustrations
ASCII via Etherpad.
Le *pad* de la feuille de styles commune
Nous travaillons sur Etherpad^4^,
un éditeur de texte collaboratif. C'est un des points clés du workshop:
la mise en commun du code rend son apprentissage beaucoup plus excitant
et rapide. Les étudiants apprennent les uns des autres en voyant les
changements en direct. Un seul document définit l'ensemble des objets Ã
produire: la taille de la fenêtre du navigateur change le format de la
page imprimée ainsi que son design, suivant les règles de tailles,
définies en CSS.
Le dernier jour du workshop est consacré à l'impression, à  la prise de
vue^8^ et présentation des objets
éditoriaux. Les fichiers sources et l'historique du projet sont mises en
ligne sur GitHub. ^9^.
Concevoir un objet imprimé avec HTML est une expérience nouvelle pour
tous et la différence de niveaux des étudiants (degré d'étude,
connaissances techniques) ne s'est pas manifestée. Html2print est un
outil pédagogiquement intéressant car il supprime le clivage
écran/imprimé. De plus, les navigateurs web étant par conception
tolérants à l'erreur, ils permettent toujours d'obtenir un résultat,
même imparfait. Par ailleurs, le fait d'avoir plusieurs objets sur un
même document était très stimulant pour les étudiants qui pouvaient Ã
tout moment suivre leur évolution. Au-delà leur intérêt
ortho-typographique, les expressions rationnelles furent grandement
utilisées pour tordre les contenus et leur design. Enfin, le fait que
les technologies abordées dans le workshop soient très populaires et
documentées sur le web, en anglais mais aussi en français, aiguise la
motivation des étudiants.
SAUCE SAMOURAI
Suite au workshop donné à la HEAR Strasbourg, la sauce html2print
commence doucement à prendre et continue de s'imprimer sur papier. Ainsi
deux participants au workshop ont poursuivi leur travaux: Hugo Serraz et
Léna Robin.
↑ Entre autres références, Les économies au féminin, Skip, 1980
