Un catalogo stampato dal database dei siti: cosa la carta non perdona

Per un evento in città ci serviva qualcosa da mettere in mano alle persone. Un catalogo vero, di carta, da sfogliare. Avevamo due strade: impaginarlo a mano, scheda per scheda, oppure generarlo in automatico dai dati che già usiamo ogni giorno. Abbiamo scelto la seconda. Ne è uscito un A5 di 32 pagine, prodotto direttamente dalla stessa interfaccia dati pubblica che alimenta i nostri siti.

Sulla carta, appunto, sembrava semplice: i dati ci sono già, le foto ci sono già, i testi ci sono già. Basta cambiare il formato di uscita. In pratica abbiamo scoperto che lo schermo nasconde molte cose che la stampa invece mette in evidenza, una per una, su ogni pagina.

Perché partire dalla fonte pubblica

La prima decisione è stata da dove prendere i dati. Avremmo potuto attingere direttamente al database interno, che contiene molto di più. Non l'abbiamo fatto, e non per pigrizia.

L'interfaccia da cui nasce il catalogo è la stessa che serve i siti: espone solo ciò che è già pubblicato. E da settembre 2026 non contiene più nemmeno i nomi interni degli immobili, quelli che usiamo tra noi per riconoscerli al volo. Il risultato è una garanzia strutturale: nel catalogo può finire solo ciò che è già pubblico.

Con il web, se sbagli, correggi e ripubblichi. Con un catalogo stampato e distribuito no: quello che è uscito resta uscito. Partire da una fonte che per costruzione non contiene niente di riservato significa non doversi chiedere, pagina per pagina, se qualcosa di interno sia scivolato dentro. Non può esserci, perché non c'è a monte.

Il filtro migliore non è quello che metti alla fine, è quello che rende impossibile l'errore all'inizio.

Le foto orizzontali su una pagina verticale

Il primo scontro con la carta è stato visivo. Le foto dei nostri annunci sono in 16:9 orizzontale, pensate per gli schermi: monitor, telefoni girati, anteprime nei siti. Un A5 invece è verticale.

L'idea istintiva era quella classica dei cataloghi immobiliari: foto a pieno vivo, che riempie la pagina fino al bordo. Ma con un'immagine orizzontale su una pagina verticale non si può fare senza tagliare metà della foto. E metà di una foto di un soggiorno o di una terrazza non è una foto più grande: è un'altra foto, spesso peggiore, con il pezzo importante finito fuori.

Abbiamo provato a immaginare ritagli automatici, ma il punto era un altro: stavamo cercando di forzare il materiale dentro un impaginato pensato per altro. Così abbiamo fatto il contrario e ripensato l'impaginato intorno al formato delle foto. Le immagini restano intere, nel loro rapporto originale, e la pagina si organizza attorno a loro. Meno effetto copertina di rivista, più rispetto per quello che il fotografo aveva inquadrato.

È una lezione che vale oltre la stampa: quando generi un prodotto da dati esistenti, il formato dei dati comanda. Puoi disegnare quello che vuoi, ma se il disegno non parte da ciò che hai davvero, finisci a tagliare.

I font che a schermo vanno benissimo

Il secondo problema non si vedeva affatto. Sui siti usiamo font variabili: un solo file che contiene tutti i pesi, comodo e leggero per il web. Abbiamo lasciato che il generatore li usasse anche per il PDF, e a schermo il risultato era perfetto.

Il guaio è che alcuni motori di stampa, quando esportano in PDF, trasformano i font variabili in font Type 3. È un formato che in tipografia può dare problemi di resa: il PDF si apre, sembra a posto, ma non è detto che in macchina esca come lo vedi tu.

La soluzione è banale una volta che la conosci: per la stampa si usano le versioni statiche dei font, un file per ogni peso. Il sito continua con i variabili, il catalogo con gli statici. Stessa tipografia, due confezioni diverse a seconda della destinazione. Il difficile è saperlo prima, perché a schermo niente ti avverte.

Il segnaposto che nessuno aveva mai notato

Il terzo problema è quello che ci ha fatto più riflettere. Un campo di testo breve degli annunci, in alcuni casi, conteneva ancora un valore segnaposto ereditato dal vecchio database: una di quelle diciture provvisorie che si mettono quando il dato vero non c'è ancora.

Sul web passava inosservato. Un campo breve, in un angolo della scheda, in mezzo a foto e descrizioni: l'occhio scivola via. Stampato in 32 pagine, invece, quel segnaposto diventava evidente. Sulla carta tutto ha lo stesso peso, il lettore sfoglia con calma e ogni riga è lì, ferma, per sempre.

Da allora abbiamo una regola precisa: prima di stampare si cerca il segnaposto in tutto il catalogo. Non a campione, non sulle prime pagine: in tutto. Ed è anche un promemoria che il problema non era del catalogo, ma dei dati. Il catalogo l'ha solo reso visibile.

Cosa ci portiamo a casa

Generare un catalogo dallo stesso database dei siti è stata la scelta giusta: niente doppio lavoro, niente copia e incolla, nessun rischio di pubblicare qualcosa di riservato. Ma abbiamo smesso di pensare che la stampa sia «solo un altro formato di uscita». Ha regole sue, e sono più severe.

I controlli che ora facciamo prima di mandare un PDF in tipografia:

• Fonte: i dati arrivano solo dall'interfaccia pubblica, mai dal database interno.
• Immagini: l'impaginato rispetta il formato delle foto, non il contrario.
• Font: versioni statiche, mai variabili, nel file destinato alla stampa.
• Testi: ricerca dei valori segnaposto su tutto il catalogo, non solo dove ci aspettiamo di trovarli.

La lezione, in una riga: un dato che va bene sul web non è per forza pronto per la carta. Lo schermo perdona perché si aggiorna. La stampa non perdona e non si aggiorna: quello che esce dalla macchina è definitivo. Per questo, quando un dato deve finire su carta, lo trattiamo come se fosse la sua versione finale. Perché lo è.