diff --git a/content/residency/8-years-of-medor-css-regions-and-ospkit.md b/content/residency/8-years-of-medor-css-regions-and-ospkit.md index 665a7740ae6be177d7b4160600b1a299a861ac26..7a6617fb4b70d48c812b82888aa42d8951ec2706 100644 --- a/content/residency/8-years-of-medor-css-regions-and-ospkit.md +++ b/content/residency/8-years-of-medor-css-regions-and-ospkit.md @@ -1,9 +1,9 @@ --- Title: 8 years of Médor, CSS Regions and OSPKit -Date: 2023-06-23 17:00 +Date: 2023-07-20 11:00 Author: Manetta Tags: shoulder-to-shoulder, css-regions -Slug: visiting-medor +Slug: 8-years-of-html2print-at-medor Status: draft --- @@ -15,7 +15,7 @@ A couple of weeks ago I visited the Médor office during one of the production w <small class="caption">A picture of the design team working on Médor n°31, May 2023.</small> -A few words about the magazine itself first. The magazine started as a printed magazine, but later also became available in an online form. Médor works with a membership model, the layout is made with free software, illustrations are often released under open licenses and there is a rotating editorial team. Médor currently has 2872 members and 1766 associates, and if you are curious to know more you can read [this super nice page on their website with a description of how Médor started](https://medor.coop/medor-cest-quoi-cest-qui/notre-histoire/). +A few words about the magazine itself first. The magazine started as a printed magazine, but later also became available in an online form. Médor works with a membership model, the layout is made with free software, illustrations are often released under open licenses and there is a rotating editorial team. Médor currently has 2872 members and 1766 associates, and if you are curious to know more you can read [this nice page on their website with a description of how Médor started](https://medor.coop/medor-cest-quoi-cest-qui/notre-histoire/). It has been 8 years now since Médor started and 4 issues are made every year. The layout of each issue is made by a group of 3 or 4 designers in the timeframe of 3 weeks, in which they closely work together with the editors, journalists and illustrators. The group of designers who works on Médor rotates, every issue is made by a different constallation of people, of which some are members of OSP and others not. @@ -23,9 +23,9 @@ It has been 8 years now since Médor started and 4 issues are made every year. T <small class="caption">A list of tools that OSP was working with around 2013 *and other magicks*.</small> -At the time that Médor started, OSP worked with a range of tools: Scribus, Inkscape, ConTeXt, Gimp, Graphviz, FontForge, Libre Office, amongst other scripts and *magicks*. Alongside, they also started to work with html2print. The ongoing work for the local Balsamine theater was one of the first commissioned projects in which html2print was explored, which continued during the making of Médor: the magazine is made with html2print from the very beginning. But! Not only. Some of the pages in the magazine are made in Scribus and Inkscape, which was an interesting discovery. +At the time that Médor started, OSP worked with a range of tools: Scribus, Inkscape, ConTeXt, Gimp, Graphviz, FontForge, Libre Office, amongst other scripts and *magicks*. Alongside, they also started to work with html2print. The ongoing work for the local Balsamine theater was one of the first commissioned projects in which html2print was explored, which continued during the making of Médor: the magazine is made with html2print from the very beginning. But! Not only. Some of the pages in the magazine are made in Scribus and Inkscape, which was an interesting discovery for me. -<!-- It turned out that the final PDF of a Médor issue is not rendered from one document. Instead, a workflow is set up that makes it possible to produce the final PDF in chunks, and each chunk is produced by a different person and also with different tools. Most of the article pages are made with html2print for example, but a special page like the announcement page (see above) explaining how someone can become a member of Médor, is made with Scribus. --> +It turned out that the final PDF of a Médor issue is not rendered from one document. Instead, a workflow is set up that makes it possible to produce the final PDF in chunks, and each chunk is produced by a different person and also with different tools. Most of the article pages are made with html2print for example, but a special page like the announcement page (see above) explaining how someone can become a member of Médor, is made with Scribus. The html2print setup that OSP uses to make Médor heavily relies on CSS Regions for text fragmentation and predictable image placement. However, CSS Regions were at the time not available anymore in any of the *updated* browsers. After trying multiple polyfills and browser alternatives, it eventually triggered the production of OSPKit: a light weight very minimal browser based on Qt-WebKit 5.212 with CSS Regions support. @@ -37,8 +37,6 @@ How does the Médor workflow break away from linear editorial workflows? How is <small>Alex Leray & Manetta Berends in conversation at the OSP studio, in the morning of Friday the 26th of May 2023.<br></small> -XXX [add: the part about the consideration of a custom toolset workflow at first] - There is this schematic that I just showed you, that Ludi and Louis made for this Toulouse presentation.  @@ -47,15 +45,15 @@ There is this schematic that I just showed you, that Ludi and Louis made for thi There is the cloud first, it's basically nextcloud, but I remember that there were a lot of questions at the beginning. Like wheter we should make our own writing and ask everyone to work in that tool, whether it's a pad or a CMS or whatever. And there were already issues with that, because Médor is not only the team of Médor but also external journalists that they work with, or the proof reader. If we take for instance the proof reader, he has its own tools and methodologies and for instance a plugin for Microsoft Word, to check spelling errors and micro typography and stuff. And tracking changes is used a lot too. -And also because they often collaborate with journalists, some are recurring and come back, but some just work with them for one artice. So it was really too much to ask everyone to work with the same set of tools. And also it is very intimate to work with specific tools. +And also because they often collaborate with journalists, some are recurring and come back, but some just work with them for one article. So it was really too much to ask everyone to work with the same set of tools. And also it is very intimate to work with specific tools. -So in the end that was also why we work with a cloud. The cloud is a nextcloud installation that we have. We have this repository of files online, where everyone can drop all the kind of documents that they want, wheter it is odt, docx, jpg, tiff, whatever is good for the articles. +So in the end that was also why we work with a cloud for file sharing. The cloud is a nextcloud installation that we have. We have this repository of files online, where everyone can drop all the kind of documents that they want, wheter it is odt, docx, jpg, tiff, whatever is good for the articles. -Basically the journalists and proof reader work with the odt or docx documents. And once it has gone through the proof reading and the text content is validated, only then we switch to the CMS where we encode the articles. +Basically the journalists and proof reader all work with the odt or docx documents. And once it has gone through the proof reading and the text content is validated, only then we switch to the CMS where we encode the articles. -**What do you mean with "encoding"** +**What do you mean with "encoding"?** -Encoding is copy-pasting the content into the CMS. The docx or odt's are mainly text and a bit of structure, but we have some additional structures in the CMS that can be used. For example, if you want to encode a portfolio, you have to use a gallery block. And then it also can be translated into the web version of the article, so it is displayed as a gallery. +Encoding is copy-pasting the content into the CMS. The docx or odt's are mainly text and a bit of structure, but we have some additional structures in the CMS that can be used. For example, if you want to encode a portfolio, you can use a gallery block. And then it also can be translated into the web version of the article, so it is displayed as a gallery. And once we went through the whole process of writing the articles and proof reading, we create an article page in the CMS, inside of an issue page. @@ -81,7 +79,7 @@ The problem with this spreadsheet based flatplan is that it is not so practical, At some point we came up with this idea to make a tool to fetch from the website the list of articles in order, to generate some kind of automatic flatplan in HTML, to be able to move things around and push the new order back to the website. And this was working for a while, but then we switched CMS and it did not work anymore. -**And now you're back to the spreadsheet.** +**And now you're back to the spreadsheet?** Yes back to the spreadsheet. @@ -129,7 +127,7 @@ Yes the HTML output was very nice, it was much more simpler. Yes. I know that Doriane reminded me that the HTML output is way simpler, and she suggested to go back to that. -It was a choice to switch to JSON, because usually all the article follow the same structure, but sometimes we have a special need for the layout. A simple example is the use of subhead. We have a specific CSS class for that. But sometimes you want this subhead to be... eh... wait, what is the contrary of subhead? When something is below a header, but you want it to be above? Adove-head? +It was a choice to switch to JSON, because usually all the articles follow the same structure, but sometimes we have a special need for the layout. A simple example is the use of subhead. We have a specific CSS class for that. But sometimes you want this subhead to be... eh... wait, what is the contrary of subhead? When something is below a header, but you want it to be above? Above-head? When you want to change the order, it is an issue with HTML output, because we had to go through Javascript to reorder things. We could also have made two divs and two different CSS flows, but it's extra work, when you just want something to be in a different order. @@ -149,7 +147,7 @@ Yes. The set of tools that we made to connect to this API, retrieve the JSON content and turns it into a HTML chunk through templating. This is done in Javascript with Vue.js. -So we have a setting.js file. And it contains a token to connect to the API. And if we look at one of the articles that is in the layout directory, let's say the *Edito*. So what happens is that at the end of the file you have a kind of HTML tag, it's a custom one: <art>. +So we have a setting.js file. And it contains a token to connect to the API. And if we look at one of the articles that is in the layout directory, let's say the *Edito*. So what happens is that at the end of the file you have a kind of HTML tag, it's a custom one: \<art\>.  @@ -203,7 +201,7 @@ This image for example is placed at a specific position, at the bottom of the pa <small class="caption">Image positioned at a predefined place: at the bottom of the page.</small> -And if you go to "computed" you have a very feature to see from which region it is flowing. So if I click there, it will bring me to the div element that contains the flow. Not from where it originates but to where it flows. +And if you go to "computed" you have a feature to see from which region it is flowing. So if I click there, it will bring me to the div element that contains the flow. Not from where it originates but to where it flows.  @@ -219,7 +217,7 @@ Maybe in another article. **Ah you can see the different articles in html2print? That is really useful.** -Yes in the script... "make json" probably, yes. You see all the pages inside the layout document, and it will generate all these pages. +Yes in the script... "make json" probably, yes, you see all the pages inside the layout document, and it will generate all these pages.  @@ -253,13 +251,13 @@ Something else, and you're going to like it... The table of content is the only place where we use CSS grid. I think CSS grid is really nice. But we had a nasty little issue. For some reason it cut the descendant of the text in italics on the left side of the text box. Is it clear? Let me draw you the situation... ------------ +<!--  <small class="caption">Scan of the drawing that Alex made to illustrate how letters are cut off in CSS grid when they fall outside of the text box.</small> ------------ +--> Let's say we have a big piece of text, like a big J, I don't know how to draw a J, let's say it looks like this. And the J is in italic. And for some reason with CSS grid it would just cut the J on the left. It was quite disturbing, it was not overflowing. @@ -288,7 +286,7 @@ Pure black is oke, it stays the same after the conversion. But for the other colors, it's hard to be sure to know what is going to happen. -On this page it is silly, we did the layout in ospkit. And then we did import the pdf in Scribus and imported each page of the pdf in Scribus, select the element that needed to be printed in silver and replace the spot color. This is possible because these are vectors. And you cannot set a spot color in html2print. +On this page it is silly, we did the layout in ospkit. And then we imported each page of the pdf in Scribus, select the element that needed to be printed in silver and replace the spot color. This is possible because these are vectors. And you cannot set a spot color in html2print. There was also a spot color in the bitmaps. And scribus support the possibility to replace colors in bitmaps. When you describe the colorname in Photoshop and Scribus the same, the connection will be made by the printer. You can make an extra channel in Photoshop I think, and as long as the names are the same, it will work.