Html2print as a practice of boilerplates

In the middle of 10 years of web-to-print practices and on the crossing of different ways of working with HTML and CSS to make printed matter, including html2print, OSPKit, CTRL+P and Paged.js, there is a lot of material lingering around in the OSP git repositories. It’s hard to find time for digestion when being in the middle of commissioned work, projects and other jobs. As satellite member and resident, we found some time for it.

Where to start if you want to explore the web-to-print practices of OSP?

We compiled an list of repositories below, annotated with notes and bits of context, to provide some handles for navigation.

As these repo’s bundle a set of traces of a moment in time, you could say that these repositories are operating as boilerplates, crossing with multiple people, organisations, ideas, tools, aesthetics and timelines. The term “boilerplates” also came up during an online radio conversation hosted by Varia, in which OSP was invited to speak about their web-to-print practices. The snippets below are a selection of this conversation, focused around this term.

---

Alex Leray, Amélie Dumont, Gijs de Heij and Doriane Timmermans (OSP) in conversation with Simon Browne and Manetta Berends (Varia) at the OSP studio, in the late afternoon of Wednesday the 7th of September 2022.
Initially broadcasted in the context of the Publishing Partyline, a two day event in October 2022. The full conversation can be accessed and listened to here: https://cc.vvvvvvaria.org/wiki/Standards_and_work_arounds

Gijs: Html2print is a kind of a recipe or a boilerplate, which I think was initially created by Stéph [Stéphanie Vilayphiou], where you try to make a minimal version of what a book or printed publication is, using HTML and CSS and specifically CSS Regions. And possibly some Javascript to make things easier for you. For example to have not a fixed set of pages, but to use Javascript calculate how many pages you need. In the sense that this boilerplate, this HTML page, is really a document that’s filled with <div>’s, and these <div>’s have specific classes, like a page class or a crop-bar top-left, or a bleed-box. And a certain basic CSS that sets the dimensions of the page and also the dimensions of bleed-box.

But we also realized today that there are like a plethora… there are so many versions of this recipe, they’re many plugins. And we also realized that often when we do a project with html2print, we kind of copy this boilerplate and start to modify it. So in a way we all have a different version of it, it’s kind of personal. And there is also intentionally… It’s quite similar to vim, the editor, which I personally don’t use… but this idea that it’s a personal tool that you make your own, that there are plugins available and that you extend it.

What is also interesting about it is… We use git in our practice to share projects amongst each other, but also the html2print, this collection of HTML files, the actual structure of the pages with the content, is also part of the repository. So it’s like… It kind of is ingrained within the project.

Manetta: So you would say it’s difficult to see html2print without the practice, the content, the people?

Alex: Yeah for me, I think, but that’s my personal opinion, I think we have 4 different opinions around the table, but for me it has never really been a tool, a fixed or solid tool. And I think that is maybe the reason why we never managed to make a proper package of it, like as a project. And for me it’s more like a collection of practices and the tools that support these practices. The tools and all this kind of knowledge we accumulated over the years are dispersed. It’s really difficult to separate this from the projects.

Gijs: So for our own practice, I think that in a way Médor was… Or no sorry, first it was Balsamine, it started there. There was this intimate relationship with the theater or at least with the artistic directors of the theater, who gave us the space to do this experiment.

Manetta: Balsamine is the theater in Brussels here right?

Gijs: Yes and so in a way they’re part of the tool or at least they’re part of the history of the tool. And there is something about the role of the tool at Médor. Because I think all the journalists are very aware of this tool being used, and it being part of the making of the layout. There are people who use the boilerplate outside of OSP. But in a way, in our git repository, we see the projects that we have done with it. I don’t know and have personally no idea of the scope of the usage of it.

Doriane: On this idea of html2print as a tool versus html2print as an approach, I think now in the Médor context, when we think about html2print, it comes with the CSS Regions. Which we will talk about later. It is dependent on one specific browser which we had to develop to be able to use CSS Regions.

So sometimes, even though it’s more of an approach then a tool, you end up in a context we’re you’re like, okay, I want to do web-to-print, but I kind of have to choose between using this browser, which CSS Regions, or other web-to-print tools like Paged.js. Even if it’s an approach, sometimes this approach can materialize itself into a choice of tools, that are more specific and more material.

Manetta: Can we call this a boilerplate practice?

Alex: Yes, there are many boilerplates around. Like almost every project is a boilerplate. In my case I often start with finding a project that fits the new project and try to take bits here and there. And recreating and gathering all the tools I need for the new project.

I think the boilerplate that is the most complete, that combines all the features would be Médor, because in a way it’s like the most, not advanced that is not the right term… It has been going on for a long time and we had time to consolidate a lot of stuff. It involves almost all the requirements, like going to the printer, turning the PDF into CMYK. In my case it’s a bit THE boilerplate.

But at the same time, it’s also split it into different bits. Like CMYK conversion is a separate git repository, that is dedicated to taking a bunch of RGB files and having some make scripts to turn a PDF into a CMYK PDF. But even there, you have to adapt it to your project, because you have to generate the right color profiles. And you have to change the code to make to right number of pages for the booklets and so on. So it’s not something you can just take as a tool. It’s really like a boilerplate.