A printed catalogue from our websites' data: what paper won't forgive

For an event in town we needed something to put in people's hands. A proper catalogue, on paper, something to leaf through. We had two options: lay it out by hand, listing by listing, or generate it automatically from the data we already use every day. We went for the second. The result was a 32-page A5, produced directly from the same public data interface that feeds our websites.

On paper, as it were, it looked simple: the data was already there, the photos were already there, the copy was already there. All we had to do was change the output format. In practice we found that the screen hides a great deal that print brings out, one item at a time, on every single page.

Why start from the public source

The first decision was where to pull the data from. We could have gone straight to the internal database, which holds far more. We didn't, and not out of laziness.

The interface the catalogue is built from is the same one that serves the websites: it exposes only what has already been published. And since September 2026 it no longer even carries the internal names of the properties, the ones we use among ourselves to recognise them at a glance. The result is a structural guarantee: only what is already public can end up in the catalogue.

On the web, if you get something wrong, you fix it and republish. With a catalogue that has been printed and handed out, you can't: once it's out, it's out. Starting from a source that by design contains nothing confidential means we don't have to ask ourselves, page after page, whether something internal has slipped in. It can't have, because it isn't there upstream.

The best filter isn't the one you add at the end; it's the one that makes the mistake impossible from the start.

Landscape photos on a portrait page

Our first clash with paper was a visual one. The photos in our listings are 16:9 landscape, made for screens: monitors, phones turned sideways, previews on the websites. An A5 page, on the other hand, is portrait.

The instinctive idea was the classic property-brochure approach: full-bleed photos running right to the edge of the page. But with a landscape image on a portrait page you can't do that without cropping away half the photo. And half a photo of a living room or a terrace isn't a bigger photo: it's a different photo, often a worse one, with the important part left out of frame.

We toyed with the idea of automatic cropping, but that wasn't really the point: we were trying to force the material into a layout designed for something else. So we did the opposite and rethought the layout around the shape of the photos. The images stay whole, in their original aspect ratio, and the page arranges itself around them. Less glossy-magazine cover, more respect for what the photographer actually framed.

It's a lesson that goes beyond print: when you generate a product from existing data, the shape of the data is in charge. You can design whatever you like, but if the design doesn't start from what you really have, you end up cropping.

Fonts that look fine on screen

The second problem was completely invisible. On the websites we use variable fonts: a single file containing every weight, handy and lightweight for the web. We let the generator use them for the PDF too, and on screen the result was flawless.

The trouble is that some rendering engines, when exporting to PDF, convert variable fonts into Type 3 fonts. It's a format that can cause output problems at the printer's: the PDF opens, looks fine, but there's no guarantee it will come off the press the way you see it.

The fix is trivial once you know it: for print, use the static versions of the fonts, one file per weight. The website carries on with the variable fonts, the catalogue uses the static ones. Same typography, two different packages depending on where it's going. The hard part is knowing in advance, because nothing on screen warns you.

The placeholder nobody had ever noticed

The third problem is the one that made us think hardest. A short text field in the listings, in some cases, still contained a placeholder value inherited from the old database: one of those stopgap labels you put in when the real data isn't available yet.

On the web it went unnoticed. A short field, tucked in a corner of the listing, among photos and descriptions: the eye just glides past. Printed across 32 pages, though, that placeholder stood out. On paper everything carries the same weight, readers browse at leisure and every line sits there, fixed, for good.

Since then we've had a firm rule: before printing, search the entire catalogue for the placeholder. Not a sample, not just the first few pages: the whole thing. It's also a reminder that the problem lay not with the catalogue but with the data. The catalogue merely made it visible.

What we're taking away

Generating a catalogue from the same database as the websites was the right call: no duplicated work, no copying and pasting, no risk of publishing anything confidential. But we've stopped thinking of print as "just another output format". It has its own rules, and they're stricter.

The checks we now run before sending a PDF to the printer:

• Source: data comes only from the public interface, never from the internal database.
• Images: the layout respects the shape of the photos, not the other way round.
• Fonts: static versions, never variable ones, in the file going to print.
• Text: a search for placeholder values across the whole catalogue, not just where we expect to find them.

The lesson, in a single line: data that works on the web isn't necessarily ready for paper. The screen is forgiving because it can be updated. Print is unforgiving and can't be updated: whatever comes off the press is final. That's why, when a piece of data is headed for paper, we treat it as its final version. Because it is.