Quirks of positioning background images

Tinkering with web to print

I'm helping with the layout and design of a publication called Troubles dans les collections, an online publication focusing on the problems related to artefacts stolen and kept/collected by colonial powers, from colonized places.

For now, this publication is only accessible as a website, and the idea was to create print versions of all the issues and articles using web-to-print. More specifically PagedJs, which takes content from a html source and transforms it to lay out the content on the pages by getting paper size, margins, and all of that, to finally output a PDF.

This tool like many similar ones (html2print, padatrad, Gabarit Abrüpt, etc) is still in a stage where it's not quite ready to fit into your regular designer's toolbox, so it requires a bit of tinkering and a clever approach to HTML, CSS, and here-and-there use of JavaScript to tackle some more detailed needs and wants. For uncomplicated design it rocks. The structure of pages is respected, you can add numbering and marginal decorations, create an implied typographic grid with the line-height property, set fonts, backgrounds, all that and more.

I did get into a bit of a mess of course, as I way too often bite off more than I can chew (see MOTIC, my first typeface). First off, for an A6 version of the publicaton, I needed to lay out one image over a spread of two pages, as A6 is very small and the images are a little too detailed to be displayed in such a small size. One problem: PagedJs doesn't really consider spreads as a thing. It lays content out as if the pages were in one continuous column. Here, the usual DTP (DeskTop Publishing) solution of sizing an image over the spread of two pages won't work.

The solution I implemented.

As PagedJs structures its output in elements with classes (.pagedjs_pagebox is the one for the whole page) nested one inside another (I'm HTMLsplaining here), the quickest solution is to create one image element on each of the distinct pages, linking to the same image file, and positioning them as needed for the seamless side-to-side join to take effect. But what if your source content was on a collaborative tool online called an EtherPad and other people probably need it too? - what if you also needed the same content file for three different paper sizes, only one of which needs a two-page image? That was my case. Putting two images in the source content would work for my A6 version but would greatly disturb the A4 and A3 sizes. In short I desperately needed a CSS-only solution. This could have been my love letter to CSS but I missed the mark.

The only option with CSS is to set the background-image of both pages to link to the same source image. It's a mess. I did it, and set the background-size to 160% (which means it would take up 80% of my spread) and the background X position to -100% on the second page. This means that the background on the second page will have its top left corner start horizontally one full page width to the left of the actual page. Perfect. What's that? the background is repeating and tiling? THe background of both pages showed a mosaic of the same image at 160% size. This is annoying, as it's neither intended nor does it allow me to add a nicely readable description of the image. So I added the background-repeat: no-repeat property. And the part of the image on the right page moved far away from its intended position. So I tried positioning it at 100%, then 160%, -160%, 40%, -40%, even 80%. every time, there was a white gap between the left and the right image. This is infuriating.

Okay so I don't actually know the technical specification, but from empirical evidence it looks like positioning a background image of an element outside of its left and top bounds using percentages doesn't actually work. When i set the background not to repeat, what I got was an image whose left edge was positioned exactly where its right edge was intended to be. This is a little technical, but bear with me. The process in the background seems to always de facto tile the background image, only when background-repeat: no-repeat is set, what it does is prevent you from seeing the other tiled copies of the image, and only shows you the first one. But when positioned with percentage values and not pixels or actual units, the image it shows you is the first one whose top lef corner is inside the bounds of the element. Silly me. Hypothesis: it does so with all relative units such as em, rem, vh, vw, etc? Can anyone confirm?

I intended to use percentages so as not to bother with actually calculating what pixel or millimeter size i want it to be. Since it didn't work I was pretty sure using fixed actual units wouldn't either. But setting both background-sizes to 165mm and setting the right-page background to start at -105mm (A6 short side or width) worked perfectly, at least in this instance, at least on Chromium, and at least with Paged.js. Ha! I'm happy I cracked the code.

The second problem.

The second problem is that printing on an A6, the size of your fingers relative to that of the page is non-negligible. I was inspired by revue Curseurs with a problem-solving detail I had mistaken for purely stylstic and decorative in the first issue. Around the vertical middle, on the left edge of the page there is a little triangular nudge of white space around which the text goes. It's intended to keep your thumbs from hiding any words you might be reading. Nice, right? I thought that implementing this in an A6 on a smaller scale could help with that as well.

As I understand it, there are ways of shaping the layout of text so that it doesn't appear as a straightforward rectangle, using an empty HTMl element with a float:left CSS property, a shape-outside property and a clip-path property both set to a polygon using percentages as coordiantes, and a width and height for that element. That's supposed to make the text on the adjacent element flow around the edges of the polygon. Here's the issue: I don't have precise sizes to set the width and height of the polygon to, since my margins are calculated relative to the text size. Ugh. I also lack an element on the left of the text paragraphs (multiple elements) that I could apply all those text-flow-bending properties to. And since I don't exactly know how my source content will be paginated, I can't determine where exatcly to place these elements were I to create them in the source document.

The only option I see is to inject javascript running after paged.js that will insert those elements inside the page content boxes, once it's all been laid out. Once again, I have no idea how. Please help.

Here's why that's interesting

The DTP method of laying out a publication, and the WYSIWYG (what you see is what you get) DTP interfaces such as InDesign and Scribus involve visual trickery. In fact, the processes going on in the background are much more complicated than what you can see. I don't know the InDesign Markup Language (IDML) or XML (which it was based on) but I'm positive that behind the scenes, when you lay an image so as to cover a full spread, i.e. the left and right page, there are two occurences of that image across the finished documents. Both are styled in a way that the second one blends seamlessly with the first one when placed adjacently. If when printing there are two pages with an image, there are de facto two images. But this has to be obvious for most of you. Where it gets fun is that this trickery, as much as it's helpful to spare time and work, prevents you from ever thinking about the real structure of a document, the way it really works, and coming closer to understanding how your tool operates.

I realize we're part of a privileged few, those of us who had the chance to discover and know to some extent web design and development, even among the designers in this world alone. But it makes sense to want to know the tool you use to a bigger extent than "the red button does x the blue button does y in this otherwise black box". I wonder if we can create interfaces that simplify and ease the process of creation and at the same time invite you to tinker more and to know more about the tool you're using. Something that would straightforwardly suggest that the owls are not what they seem, that your one image on a spread is actually two images. Something to counter Bob, for my second Twin Peaks reference, to counter the evil that WYSIWYG apps do. I really have to rewatch that show