Quando dico che sto scrivendo un libro, chi mi ascolta immagina un documento. Nella mia testa invece c’è un repository con dei profili di build, e il PDF non è il libro: è l’artefatto che esce quando il libro compila.

La differenza si vede subito nella regola più rigida che ho: non lancio mai il compilatore a mano. Passo sempre da latexmk con i profili che stanno versionati nel repo. Non è pedanteria, è che invocare il motore direttamente rompe la corrispondenza tra sorgente e PDF, e quella corrispondenza è ciò che mi permette di cliccare su una formula nel PDF e ritrovarmi sulla riga esatta del sorgente che l’ha prodotta. È esattamente la stessa ragione per cui in un progetto software non compili a mano un file per poi chiederti perché il debugger non trova più i simboli.

La parte che mi diverte di più è che lo stesso sorgente produce tre formati fisici diversi. C’è il paperback da 7.5 per 9.25 pollici, che è il formato di riferimento. C’è la versione per lettori e-ink di grande formato, dieci pollici, che uso io per rileggermi in poltrona. E c’è la copertina rigida, 7 per 10 pollici, che ha un problema tutto suo: cambiando le proporzioni della pagina, il testo si ridisporrebbe e le pagine non coinciderebbero più con quelle dell’edizione economica.

Ho risolto con un fattore di scala applicato all’intero blocco di testo. La gabbia dell’hardcover è la stessa dell’economica, ingrandita quel tanto che serve a riempire una pagina più grande. Il risultato è che le tre edizioni hanno la stessa impaginazione pagina per pagina: quando un lettore mi scrive che a pagina 214 c’è un errore, quella è pagina 214 per tutti, e un errata corrige vale per l’intero catalogo. Se avessi lasciato che ogni formato si riorganizzasse per conto suo, avrei tre libri da mantenere invece di uno.

Da questa ossessione è nato lo script di cui vado più fiero, che si chiama drift.py e fa una cosa sola: misura di quanto si è spostata la paginazione tra due build. Sembra una preoccupazione da tipografo e invece è puro controllo di regressione. Aggiungi tre righe al capitolo 3 e ti si muove tutto quello che viene dopo, compresi i riferimenti incrociati e le voci dell’indice analitico. Il drift ti dice in un colpo d’occhio se la modifica di stamattina è costata zero pagine oppure sette, e sette pagine su un libro già impaginato sono un lavoro serio.

C’è anche un debito tecnico dichiarato, che è giusto raccontare. Compilo con pdfLaTeX, mentre il ramo che genererebbe un PDF accessibile e correttamente taggato passa da un motore diverso e da mesi non lo tocco più. L’ultima volta che l’ho provato produceva file cinque volte più grandi e un centinaio di avvisi, per incompatibilità tra i pacchetti che uso per i riquadri e le tabelle e la macchina della marcatura semantica. Un PDF accessibile è una cosa che voglio, non una cosa che ho, e preferisco scriverlo qui piuttosto che fingere il contrario.

Il resto della catena assomiglia a qualunque progetto: una sola bibliografia condivisa tra tutte le edizioni, gli indici generati, e nessuna integrazione continua, perché l’unico committente sono io e la build gira sulla mia macchina a ogni salvataggio.

Un libro lo scrivi una volta. Poi lo compili trecento.

Ultima modifica 06/07/2026