Non ho mai avuto problemi, salvo dover imparare qualche comando per librerie poco usate (exam, per preparare verifiche, soluzioni e test a risposta multipla è un’ottimo pacchetto, ma deve essere studiato!); l’uscita di default in PDF assicura la visualizzazione voluta, che non si modifica con la stampante selezionata (sto guardando proprio te, MS Word…), non taglia inaspettatamente a metà una tabella o una figura, permette di dedicarsi al contenuto e solo in seguito alla forma.
Per quanto riguarda l’editor da usare: ne esistono un bel po’, a partire da quelli forniti con le installazioni LaTeX fino a editor appositi, di solito anche opensource e gratis (tra i quali segnalo l'ottimo Texstudio), che semplificano ulteriormente il lavoro con piccole procedure, per inserire un'immagine, creare una tabella, ecc...
Poi mi è venuta l'idea di diffondere qualcosa di quel che ho imparato strada facendo, caso mai servisse ad altri; in altre parole, sto provando a scrivere un piccolo manuale di problemi di Fisica...
Qui la situazione cambia: mentre su un telefono aprire un PDF è una cosa che si fa senza pensarci, leggere un documento a formato fisso su un reader, che può essere un Kindle, un Kobo, Apple Books o Google Libri, è un'altra cosa: i lettori ormai si aspettano di poter cambiare a piacimento font, dimensioni e orientamento. Un PDF si presenta bello a vedersi, ma su uno di questi lettori, di dimensioni minori di una normale pagina (se escludiamo qualche modello costoso) la lettura diventa acrobatica, tra zoom avanti e indietro e link che spostano la visione.
In più (e dico purtroppo), sappiamo che Fisica non è molto amata (a parte la divulgazione, che non equivale allo studio): se ancora aumentiamo gli ostacoli, non arriveremo mai. Per cui, niente da fare: il formato deve essere un ePUB, accettato da tutti i dispositivi: così si possono seguire le preferenze di tutti i lettori, anche quelli che vogliono scritte bianche su fondo scuro.
ePUB è un formato basato su html, il linguaggio del web, che quindi si adatta alle dimensioni della pagina. Infatti un ePUB non è altro che un file zip, con all'interno codice html con tutto quello che serve a costruire la pagina: stili, immagini, ecc... Se qualcuno è curioso, può dare da terminale il seguente comando:
unzip <nome_file>.epub -d <cartella_uscita>
Nella cartella di uscita saranno visibili tutti i file html e le immagini contenute nel libro, assieme agli stili per il formato di partenza, dimensioni e posizionamento delle figure.
Ecco il problema: esiste un metodo per la trasformazione LaTeX ➝ ePUB? Sì, è un'altro pacchetto LaTeX: tex4ebook, che prima trasforma il codice LaTeX in HTML e poi costruisce l'ePUB finale. Solo che per avere quello che vogliamo, occorrono molte personalizzazioni da inserire in codici di stile. In più, non sempre tutte le formule, che in LaTeX sono bellissime, lo sono altrettanto alla fine.
Avendo tempo, mi son detto: possibile che non ci siano altri metodi? Per cui mi son dedicato a cercare alternative, prima di cominciare a scrivere: meglio partire col linguaggio giusto, invece di doverlo tradurre in seguito!
Qualcuno usa direttamente MS Word: moltissime possibilità di formattazione, ma gestione delle formule non adatta ad un libro che ne è pieno. Apple Pages sarebbe quasi perfetto: non ha tutte le possibilità del corrispettivo Microsoft, ma ha un editor LaTeX per inserire formule, che si adattano anche alla dimensione del carattere scelto. Esporta in ePUB e si carica direttamente su Apple Books; purtroppo (vedremo) ci sono problemi di compatibilità con alcuni eReader. Sia Word che Pages (o alternative come Libre Office, con un equation editor ancora diverso) creano file in formato proprietario o aperto, ma che comunque devono essere esportati se li vogliamo anche solo come testo. E comunque le formule non sono così belle a vedersi; se poi parliamo anche di numerarle, la cosa diventa difficile.
La prima alternativa vera in cui mi sono imbattuto (non avevo idea che esistesse!) è Typst: dovrebbe essere il successore di LaTeX, ma più semplice e più rapido. Si scrive in un file di testo con estensione .typ, proprio come LaTeX ha l'estensione .tex, ma con sintassi delle formule molto più semplice e intuitiva. Inoltre, mentre un'installazione LaTeX può arrivare anche a 5 GB, una di Typst richede qualche centinaio di mega e la compilazione è veloce. Indubbiamente una cosa da seguire; purtroppo anche qui l'esportazione a ePUB non esiste: è in scaletta da un po' di tempo, ma per ora il PDF è ancora il media preferito. Peccato: avrebbe anche un pacchetto apposito per la Fisica...
La seconda scoperta è usare direttamente il linguaggio Markdown: che poi, chiamarlo linguaggio è persino troppo: è un Markup Language come l'html ma con pochi simboli per la formattazione (titoli, grassetto, corsivo, liste...); non c'è la gestione iniziale del preambolo, il testo è ben leggibile. Se si usa l'extended syntax si possono inserire le formule direttamente in LaTeX. Tra l'altro, Markdown è il sistema usato spesso per fornire istruzioni per software e altro: dove possibile si legge una pagina ben formattata e strutturata (per esempio sui progetti GitHub); se non si ha il compilatore, il testo è facilmente leggibile (**abc** per il grassetto, *abc* per il corsivo e così via), senza l'appesantimento dei tag di html; l'esportazione in testo è praticamente immediata: basta un copia-incolla.
Da qui devo dire che mi si è aperto un mondo, che prima avevo soltanto scalfito: per esempio, il passaggio da markdown a ePUB viene fatto senza problemi installando pandoc, un piccolo software in grado di fare un mucchio di trasformazioni (qualcuna ottima, altre un po' meno...). Questo significa che se in seguito si scopre un metodo migliore, probabilmente pandoc sarà in grado di portare tutti i file nel nuovo ambiente! Quindi la prima idea è usare markdown con estensioni per tutto il libro.
Ma potevo fermarmi qui? Nooooo, ovviamente! Quando si è in cerca, non si sa mai quando si è raggiunto il risultato migliore!Alla fine mi sono fermato su Quarto: fornisce molto, senza aumentare la complessità. Si tratta di usare sempre il markdown esteso, con i suoi vantaggi (formato non proprietario, facilità di esportazione, testo ben leggibile anche senza un editor apposito), ma con alcune aggiunte importanti:
- le formule matematiche sono scritte in LaTeX, quindi niente necessità di imparare qualcosa di nuovo;
- se necessario posso usare Typst, quando mi pare che la sua sintassi sia più semplice;
- si possono inserire contenuti dinamici dipendenti da dati: per esempio un codice Python che fornisce un grafico, una procedure R per elaborazioni statistiche e alcuni altri;
- dallo stesso codice posso ottenere più formati in uscita: PDF, ePUB, HTML+CSS, ciascuno formattato con differenti opzioni;
- con un editor di testo, il terminale ed un browser si può vedere il risultato in tempo reale ad ogni salvataggio del file. L'unica cosa a cui fare attenzione è che i file di testo devono avere l'estensione .qmd (quarto markdown) invece della normale .md.
L'installazione è fatta tramite il download dal sito ufficiale (oppure, su macOS, tramite homebrew, il package manager) e occupa meno di un giga su disco;
brew install --cask quarto
inoltre, in questa installazione è compreso il comando pandoc e l'installazione di Typst (con qualche attenzione, li si può usare senza installazioni aggiuntive); infatti, se non esiste un'installazione LaTeX, tramite pandoc le formule LaTeX sono tradotte in Typst, che le porta in PDF; oppure pandoc può portarle in formato mathml per l'uso in html, cioè alla fine in ePUB; tutto questo in automatico.
Qualunque editor è sufficiente per scrivere in qmd; tuttavia, per alcuni (VS Code, Emacs, Neovim, SublimeText)) esiste anche un plugin che permette di vedere in anteprima la formula risultante, la colorazione della sintassi; questi plugin sono presentati nella pagina di Quarto apposita.Senza duplicare una riga di codice posso ottenere più formati: tutto viene gestito (ed è l'unica parte che possiamo definire di programmazione) dal file _quarto.yml, dove vengono indicati i file da compilare, con che struttura, quali formati in uscita servono e con quali scelte. Si possono anche aggiungere fogli di stile css, per modificare quello che non ci piace, ma i valori di default sono già buoni; esiste già pronta una simulazione di tcolorbox, per la creazione di box di evidenziazione.
Come esempio, supponiamo di aver definito nel file _quarto.yml 3 formati target: html, pdf, epub; per ottenerli tutti e tre, il comando è semplicissimo:
quarto render
mentre se volessimo solo il formato html, per un controllo veloce di come sta andando il progetto:
quarto render --to html
Se usiamo un editor senza il plugin, questo comando da terminale produce un html che può essere aperto da un browser. Se invece usiamo un editor col plugin di Quarto, sarà disponibile un pulsante in grado di fare tutto in automatico.
Per un libro di semplici problemi/soluzioni non ho bisogno di tutte le possibilità, soprattutto dei contenuti dinamici, ma posso non usarli ora (e Quarto diventa uguale al markdown) e se in futuro mi servisse una delle possibilità aggiuntive sarei pronto ad usarle.
Quindi, tutto finito? Posso partire a scrivere? Beh, beh,... c'è ancora un problema: abbiamo stabilito che il formato finale deve essere ePUB e Quarto è in grado di crearlo. Però dobbiamo scegliere come rendere le formule matematiche: il metodo più semplice è usare il formato mathml, un modo molto simile a html per costruire formule per il web (non si può usare mathjax, perché gli eReader non accettano codice javascript).
Il fatto è che tutti gli e-reader recenti supportano il formato mathml delle formule, ma quelli poco più vecchi no! Non siamo sicuri che un Kindle di qualche anno fa possa rappresentare le formule correttamente: le potrebbe saltare o presentare caratteri illeggibili... insomma, non va bene. O meglio: posso usare questo formato per Apple Books, ma non per gli altri (e pubblicare solo su Books significa perdere circa l'80% dei possibili lettori): qui sfrutterò Quarto, con cui creare un formato apposta per Books e uno differente per tutti gli altri (non posso distinguere tra i reader che accettano mathml e gli altri: non è previsto l'upload di versioni diverse a seconda del reader.
Quindi, come si risolve? Cercando un po' in giro e chiedendo aiuto all'AI, ho trovato che l'unico modo sicuro è trasformare le formule in grafica SVG: è un formato vettoriale, quindi scalabile come serve (per esempio, quando il lettore chiede una dimensione del carattere diversa dall'originale), può essere senza sfondo e cambiare colore (per quelli che preferiscono lo sfondo scuro, oggi molto di moda).
Per la trasformazione LaTeX ➝ SVG, Quarto può aiutare: il modo più semplice è di impostare il formato WebTeX: in pratica, durante la compilazione le formule sono spedite ad un sito web, che le elabora e le rispedisce indietro in SVG, dove vengono salvate e opportunamente linkate nel codice html. Però il procedimento non mi piace:
- il sito fornisce gratis la trasformazione fino a 1000 chiamate al giorno: sono tante, ma nel momento in cui si fanno delle prove sul libro finale, potrebbero non bastare;
- le formule viaggiano in rete: nulla di privato, ma non mi piace lo stesso;
- nulla mi garantisce che il sito resti attivo fino a quando mi servirà.
Per cui, altra ricerca in rete e aiutino dall'AI: potrei fare in locale la stessa cosa che fa oggi il sito: entrare con la formula scritta in LaTeX dentro un codice markdown, usare un piccolo software chiamato GladText, che con l'aiuto di pandoc e una installazione LaTeX (in cui deve essere presente dvisvgm) trasforma le formule in grafici svg, li salva e li collega al codice html; Quarto poi si occupa di costruire l'ePUB. Se necessari, inseriremo qualche codice css se gli allineamenti tra testo e figure non saranno perfetti.
I passaggi sono quindi:
file cmd ➝ gladtex ➝ dvisvgm (LaTeX) ➝ gladtex ➝ pandoc ➝ epub
In questa catena non compare Quarto: infatti è il direttore d'orchestra, che fa partire il primo passo e alla fine chiama chi di dovere per la costruzione dell'epub finale.
Però non voglio occupare spazio sul mio Mac con una installazione LaTeX (per le verifiche ho sempre usato compilatori online); poi dovrei aggiungere anche dvisvgm e gladtex. Allora la soluzione è una sola: un bel docker container, da distruggere quando non mi servirà più, tanto posso ricostruirlo senza problemi dal dockerfile.
Nel passare dalla teoria alla pratica, ho incontrato alcuni problemi: sia perché a qualcuno potrebbe servire, sia per mia memoria, pubblicherò qui tutti i passaggi necessari con spiegazioni.
Ma tutto alle prossime puntate!
--- --- ---





