Latex on Melabit

Modifiche a colpo d'occhio con SubEthaEdit

Mon, 27 Nov 2023 06:00:00 +0000

– Fonte: Possessed Photography su Unsplash.

SubEthaEdit (SEE per brevità) è un editor per macOS discreto, che fa più o meno tutto ciò che ci si aspetta da un editor moderno (con alcune mancanze significative), e che in più ha la particolarità di permettere a più utenti collegati di lavorare in modo collaborativo allo stesso documento.

Di queste caratteristiche generali ho già scritto nell’articolo precedente. In questo articolo, invece, voglio soffermarmi sulla funzione di SEE che mi ha colpito di più in assoluto, cioè la possibilità di mettere bene in evidenza tutte le modifiche effettuate su un documento di testo anche quando non si collabora con altri utenti, una funzione molto particolare ma che in certi casi può diventare davvero un toccasana.

Modifiche in evidenza

A che serve evidenziare le modifiche ad un testo? Serve tutte le volte in cui si debba mostrare in modo chiaro e tracciabile all’editore, al committente, al cliente, o semplicemente ai colleghi, cosa è stato cambiato in un dato documento, come succede molto spesso nell’editoria scientifica ma anche in tanti altri settori professionali.

Con un wordprocessor non è un problema, Word e i suoi cloni hanno uno strumento integrato di revisione del testo che, per quanto pesante e implementato in modo farraginoso, fa il suo lavoro. Ma come può fare chi preferisce scrivere in modalità solo testo, usando LaTeX o il sempre più popolare Markdown?

Questi due strumenti permettono di segnalare le modifiche inserendole all’interno di tag dedicati (\hl{testo modificato} per LaTeX e {==testo modificato==} per Markdown), ma è fastidioso dover aggiungere i tag mentre si procede alla revisione del testo, con il rischio di perdere il filo del discorso e di allungare i tempi di lavoro.

Come mi sono accorto da poco, SEE può essere un ottimo strumento per risolvere questo problema.

La funzione di evidenziazione del testo modificato di SubEthaEdit può essere attivata una volta per tutte selezionando l'opzione `Highlight Changes when not collaborating posta in cima al pannello `General` delle Preferenze, e sarà valida per tutti i nuovi documenti aperti nel programma.

Se vogliamo attivarla anche nel documento corrente, dobbiamo andare nel menu View e selezionare la voce Highlight Changes.

Da questo momento in poi, tutte le modifiche o le aggiunte al testo corrente verranno messe in evidenza da un fondo colorato in giallo (il colore si può cambiare nella sezione Collaboration delle solite Preferenze).

Un caso personale

Alcune settimane fa dovevo modificare un articolo scritto in LaTeX che richiedeva la riscrittura o l’aggiunta di grosse porzioni di testo, nonché la correzione di un bel po’ di errori di inglese, il tutto con la necessità di mettere bene in evidenza tutte le modifiche effettuate, anche al livello delle singole parole.

LaTeX ha una funzione specifica per mettere in evidenza il testo modificato (\hl, che sta per highlight), il problema è che, quando le modifiche sono tante, è difficile riuscire a ricordarsi di circondare anche il più piccolo pezzetto di testo modificato con \hl{...} senza perdere il filo del discorso e finire per dimenticare qualcosa di importante.¹

Ho provato i miei soliti editor,² per vedere se potevano offrire qualcosa che faceva al caso mio ma, a parte (ovviamente) Emacs,³ non ho trovato niente più del solito diff, uno strumento da Terminale molto usato dai programmatori che mette a confronto due file diversi e segnala quali righe sono state modificate.

Ma, appunto, con diff possiamo vedere quali righe sono cambiate, non cosa è cambiato in ciascuna riga! Per un programmatore non è un problema, perché le righe di codice sono brevi ed è facile notare le differenze, ma in un documento LaTeX una singola riga può corrispondere ad un lungo paragrafo di testo, ed è quindi molto più difficile notare a prima vista cosa è cambiato rispetto al testo originale.⁴

Ci sono altri strumenti a linea di comando che avrebbero potuto fare al caso mio, come wdiff, che bisogna installare con Homebrew, oppure git diff --word-diff, ma usarli avrebbe complicato ulteriormente un lavoro già di per sé piuttosto complesso.

Un po’ per caso un po’ per fortuna ho lanciato SEE, che avevo installato sul Mac senza usarlo mai più di tanto, e mi sono accorto che faceva perfettamente al caso mio.

Con questo editor il lavoro di revisione è stato semplicissimo: mi bastava prendere un blocco di testo dal file originale in LaTeX, copiarlo nella finestra di SEE e inserire via via le correzioni, vedendole tutte chiaramente e in tempo reale con il loro fondo giallo. Una volta finita la revisione di tutto il blocco, potevo circondare tutte le parti di testo evidenziate con hl{...}, per poi sostituire il testo rivisto a quello del file originale LaTeX.

Vi assicuro, descrivere la procedura è molto più complicato che realizzarla, tanto che sono riuscito a completare tutta la revisione in appena un paio di giorni, perché SEE mi permetteva di concentrarmi esclusivamente sulla riscrittura del testo, rimandando la gestione minuta delle modifiche solo alla fine della correzione dell’intero blocco.⁵

Perché tutta questa trafila di copia e incolla da LaTeX a SEE e viceversa? Non sarebbe stato più semplice lavorare solo in SEE? Certo, ma l’articolo originale era su Overleaf e volevo che i colleghi potessero continuare ad accedere all’ultima versione anche mentre io ci lavoravo. E poi SEE ha un grosso difetto, perché non conserva le evidenziazioni quando si salva un documento e lo si riapre una seconda volta. Sarebbe bastata quindi una distrazione, un blocco imprevisto del Mac o magari un banale calo di tensione per perdere di colpo traccia di tutte le modifiche più recenti. Non potevo permettermelo e non ho voluto rischiare.⁶

A questo proposito, ho chiesto agli sviluppatori di rendere permanenti le evidenziazioni del testo, ma dopo due mesi non ho avuto risposta e temo che la richiesta non sarà soddisfatta, almeno in tempi brevi.

Dal personale al generale

Ma questa funzione particolare di SEE serve solo a chi, come me, si muove nell’ambito dell’editoria scientifica? Non credo, in realtà mettere bene in evidenza le modifiche ad un documento è una funzione molto utile in svariati settori professionali, e spesso sono proprio i committenti o i clienti a richiedere esplicitamente che il documento contenga una visualizzazione chiara di tutti i cambiamenti subiti.

Non a caso la funzione di revisione con evidenziazione delle modifiche effettuate è molto usata da chi scrive in Word, sia quando lavora in collaborazione con altri che quando deve semplicemente correggere un documento altrui.

L’implementazione delle revisioni in Word è molto macchinosa (e come poteva essere diversamente?) e le modifiche possono essere visualizzate in molti modi diversi, una flessibilità che però tante volte genera solo confusione quando si aprono dei documenti altrui. Nella modalità di visualizzazione più dettagliata si arrivano a vedere le singole lettere aggiunte o cancellate, e il tutto diventa presto un guazzabuglio incomprensibile di testo barrato e testo colorato, con configurazioni e colori diversi per ciascun utente. Considerazioni analoghe si possono fare anche per altri sistemi di scrittura come LibreOffice Writer o Google Docs, che forse riescono a fare persino peggio di Word.

In ogni caso, Word sarà anche molto popolare ma tanti, come me, preferiscono usare sistemi di scrittura basati sul testo puro, come LaTeX o il popolarissimo Markdown, che ha parecchi segni speciali per gestire le evidenziazioni di un blocco di testo ({==testo evidenziato==}), così come le aggiunte ({++testo aggiunto++}), le ~~cancellazioni~~ ({--testo cancellato--}), e perfino le ~~modifiche~~ sostituzioni ({testo precedente>testo sostituito~}).

Quando le modifiche da fare sono tante, come ci si può concentrare sul testo da rivedere senza perdere il filo del discorso, quando bisogna inserire di continuo i tag, piuttosto complessi in verità, che indicano tutti i cambiamenti effettuati?

SubEthaEdit può essere un’ottima risposta a questo problema.

Una funzione analoga ce l’ha anche Markdown, che usa i tag {== e ==} per mettere in evidenza il testo compreso fra essi. Purtroppo non tutti gli interpreti Markdown supportano questi tag (fra cui, purtroppo, l’interprete usato da Wordpress.com), una particolarità che crea non poca confusione.
Per aggirare il problema, si può usare la coppia di tag standard HTML5 <mark>testo evidenziato</mark>, che di default produce un testo con uno sfondo giallo (ma si possono usare facilmente altri colori). ↩︎
Per i più curiosi, i miei editor sono, in ordine di preferenza, TextMate, BBEdit e Visual Studio Code, che ho dovuto adottare al posto del defunto Atom. Uso anche la versione per macOS di GNU Emacs, ma ammetto di farlo molto meno spesso di quanto vorrei. ↩︎
Emacs dispone dell’highlight-changes-mode che avrebbe fatto perfettamente al caso mio, ma c’erano dei motivi pratici che mi impedivano di usarlo. ↩︎
E comunque diff lavora su due file diversi, una cosa che nel mio caso particolare avrebbe aggiunto un ulteriore livello di complicazione. ↩︎
L’ho già detto ma è meglio ripetere: a differenza di altri strumenti che confrontano due file separati, uno contenente il testo originale e l’altro quello modificato, SEE opera in tempo reale e direttamente sul testo in lavorazione, semplificando parecchio il lavoro di revisione ↩︎
In effetti ci sarebbe un’altra opzione, usare Meld. Ma fino a poco tempo fa, per motivi che mi sfuggono, Meld si rifiutava di partire sul mio Mac con macOS Monterey, per cui non ho provato nemmeno ad usarlo per questo lavoro. Da un po’ però funziona, per cui potrebbe essere argomento per un prossimo articolo. ↩︎

Qual è la somma? Soluzioni

Mon, 14 Dec 2020 06:00:00 +0000

– Foto di NeONBRAND su Unsplash.

Ed ecco la soluzione promessa al problema di ieri. Anzi, LE soluzioni, perché ce ne sono parecchie, più o meno complicate o, meglio, più o meno adatte al modo di pensare di ciascuno.

Il problema era:

Ciascun termine di una serie geometrica è il doppio del precedente. In una certa serie geometrica, la somma del settimo, ottavo e nono termine fa 3. Qual’è la somma del quarto e quinto termine?

In un primo momento può sembrare un problema complicato, ma basta pensarci un po’ per accorgersi che in realtà la soluzione è abbastanza semplice.

Serie geometrica

Come spiega l’enunciato stesso del problema, una serie geometrica è composta da un numero in teoria infinito di termini, ciascuno dei quali è il doppio di quello precedente. Ad esempio, la serie geometrica più semplice che mi viene in mente è

1, 2, 4, 8, 16, 32, 64…

nella quale 1 è il primo termine della serie, 2 il secondo termine e così via, e ciascun termine (ad esempio 8) è il doppio di quello che lo precede (in questo caso 4). (Volendo ci sarebbe una serie geometrica ancora più semplice, composta tutta da zeri, 0, 0, 0, 0, …, ma è un caso particolare molto banale).

Ogni termine della serie può essere indicato con una variabile a cui viene associato un pedice (cioè un numero scritto più in basso rispetto al nome della variabile), che aiuta ad individuare più facilmente il termine della serie a cui ci stiamo riferendo. As esempio a₁, a₂, a₃, indicano rispettivamente il primo, secondo e terzo termine della serie. Per una serie geometrica, a₂ = 2 a₁, a₃ = 2 a₂ = 4 a₁, e così via.

Soluzione #1

In base a quanto appena detto, definiamo il settimo, ottavo e nono termine della serie come a₇, a₈ e a₉. Il problema ci dice che la somma di questi termini è uguale a 3,

a₇ + a₈ + a₉ = 3

Ma abbiamo anche altre informazioni, perché sappiamo che a₈ = 2 a₇ e a₉ = 2 a₈. Possiamo quindi scrivere un sistema di tre equazioni in tre incognite,

a₇ + a₈ + a₉ = 3 a₈ = 2 a₇ a₉ = 2 a₈

che può essere semplificato tenendo conto delle relazioni fra a₇, a₈ e a₉ e esprimendo le tre equazioni in funzione della sola a₇,

a₇ + (2 a₇) + (4 a₇) = 3 a₈ = 2 a₇ a₉ = 4 a₇

La prima delle tre equazioni del sistema diventa 7 a₇ = 3, cioè

a₇ = 3 ⁄ 7

A questo punto è facile, perché a₆ è la metà di a₇, a₅ un quarto di a₇ e a₄ un ottavo, sempre di a₇. Quindi

a₆ = 3 ⁄ 14 a₅ = 3 ⁄ 28 a₄ = 3 ⁄ 56

da cui si ottiene che

a₄ + a₅ = 3 ⁄ 28 + 3 ⁄ 56 = (2 × 3 + 3) ⁄ 56 = 9 ⁄ 56

che è la soluzione del problema.

Soluzione #2

In realtà non c’è bisogno di mettere su un rigoroso sistema di tre equazioni in tre incognite, perché dalla definizione di serie geometrica sappiamo immediatamente che

a₇ + a₈ + a₉ = a₇ + 2 a₇ + 4 a₇ = 3

da cui ricaviamo immediatamente che a₇ = 3, e tutto il resto è identico al caso precedente.

Soluzione #3

Questa soluzione funziona al contrario delle due precedenti, che partono dai termini di ordine maggiore per calcolare quelli di ordine inferiore. In base alla definizione di serie geometrica,

a₂ = 2 a₁, a₃ = 4 a₁, a₄ = 8 a₁, a₅ = 16 a₁, a₆ = 32 a₁, a₇ = 64 a₁, a₈ = 128 a₁, a₉ = 256 a₁

Di conseguenza,

a₄ + a₅ = 8 a₁ + 16 a₁ = 24 a₁

a₇ + a₈ + a₉ = 64 a₁ + 128 a₁ + 256 a₁ = 448 a₁ = 3

Da questa eguaglianza si ricava il primo termine della serie, a₁ = 3 ⁄ 448, e quindi

a₄ + a₅ = 24 a₁ = 24 × 3 ⁄ 448 = 72 ⁄ 448 = 9 ⁄ 56.

Soluzione #4, 5, …

Se qualcuno trova delle soluzioni diverse al problema, sarò ben felice di aggiungerle qui.

Markdown e LaTeX

Markdown mi piace moltissimo e infatti lo uso per scrivere tutti i miei post, così come tanti documenti di lavoro che non devono circolare oltre il circolo, purtroppo ristretto, di chi è in grado di scrollarsi di dosso Word. Purtroppo devo ammettere che il supporto a LaTeX è abbastanza inconsistente. Va benissimo finché si tratta di scrivere delle equazioni semplici, ma appena le cose si complicano, ad esempio quando si prova ad inserire un sistema di equazioni, sono dolori.

Ancora peggio è il fatto che la resa finale dipenda dal motore di conversione. Ad esempio, Marked converte quasi sempre perfettamente le equazioni fuori testo (quelle centrate in uno spazio apposito), sia quando si usano i simboli $$ prima e dopo l’equazione sia inserendole all’interno dell’ambiente \begin{equation} ... \end{equation}. Ma se l’equazione incapsulata fra $$ ... $$ contiene dei pedici (o degli apici) Marked dà un errore, che invece non compare se si usa l’ambiente \begin{equation} ... \end{equation} (meno usato perché molto più lungo da scrivere).

Ancora peggio è quello che succede con il motore LaTeX di Wordpress.com, che non supporta l’ambiente \begin{equation} ... \end{equation} e nemmeno la forma abbreviata $$ ... $$, ma che per integrare le equazioni nel testo in Markdown usa una sintassi non standard, $latex ... $ (dove il codice LaTeX va inserito al posto dei puntini).

D’altro canto Markdown nasce per essere uno strumento semplice per scrivere sul web, caricarlo di troppe opzioni (e di troppe responsabilità) sarebbe un controsenso. In casi come questi forse la cosa migliore è scrivere il testo direttamente in LaTeX, convertendolo poi in HTML puro tramite pandoc o simili.

Io avevo già scritto quasi tutto il testo quando mi sono accorto di questi problemi e per questa volta ho preferito eliminare il codice LaTeX ed usare solo il normale HTML per indicare i pedici o le frazioni, perché la resa grafica delle equazioni fuori testo era davvero pessima. Basta confrontare questa equazione scritta in LaTeX,

$latex \begin{array}{ll} a_7 + a_8 + a_9 = 3\ a_8 = 2 a_7\ a_9 = 2 a_8 \end{array}$

con questa in HTLM mescolato al normale codice Markdown,

a₇ + a₈ + a₉ = 3 a₈ = 2 a₇ a₉ = 2 a₈

per rendersene conto. Purtroppo l’HTML non riesce a gestire bene le frazioni (o forse sono io che non so come fare), prometto di far meglio la prossima volta.

Qual è la somma?

Sun, 13 Dec 2020 06:00:00 +0000

– Foto di Antoine Dautry su Unsplash.

È domenica, bisogna stare in casa (perché voi cercate di stare il più possibile in casa, vero?), perché non dedicarsi ad un piccolo problema di matematica? Il problema è:

Ciascun termine di una serie geometrica è il doppio del precedente. In una certa serie geometrica, la somma del settimo, ottavo e nono termine fa 3. Qual’è la somma del quarto e quinto termine?

La risposta richiede un po’ di matematica al livello della scuola superiore oppure una certa pratica con i rompicapi stile Settimana Enigmistica (“Giovanni ha la camicia verde ed è stempiato. Luca ha l’ombrello. … Di chi è il cane?”). E magari anche un po’ di attenzione nell’osservare certi dettagli…

Per chi non riuscisse a trovare la soluzione, appuntamento a domani. Sarà anche l’occasione per provare un po’ meglio come Markdown (con cui scrivo tutti i miei post) gestisce le equazioni scritte in LaTeX.

Il CNR è anche questo: un po' di codice

Tue, 01 Dec 2020 06:00:00 +0000

XKCD, Good code.

Per concludere nel miglior modo possibile questa serie di articoli (qui la prima e la seconda parte), cosa ci può essere di meglio di un po’ di codice?

Estrarre il testo da un file PDF

Cominciamo dallo script in R, pdf2csv.R, che estrae il testo da un file PDF, (che in questo caso specifico ho usato per estrarre i dati dalla domanda di partecipazione ad un concorso precedente). Qui sotto trovate l’immagine dello script, realizzata con Carbon (perché così è molto più bello), su GitHub c’è il sorgente vero e proprio, per chi voglia provare ad usarlo.

Per eseguire lo script è necessario aver installato sul proprio computer, non importa se è un Mac o un PC con Linux o Windows, l’ambiente R (in questo momento è disponibile la versione 4.0.3), meglio ancora se accompagnato da RStudio Desktop, che è di gran lunga il migliore sistema integrato di sviluppo (IDE) che abbia mai usato, oltre che uno strumento efficacissimo per affacciarsi all’uso di R.

Il codice è molto semplificato, ho tolto tutto ciò che non è strettamente necessario a far funzionare lo script. La chiave di tutto è la libreria pdftools per R. Di librerie per estrarre dati dai file PDF ne ho provate moltissime, sia per R che per Python, ma pdftools le batte tutte per potenza, semplicità e velocità. Ci sono dei tool che convertono un PDF in testo al ritmo di una pagina al minuto, pdftools riesce a convertire (molto bene, peraltro) un file di 400 pagine come questo in appena 5-6 secondi. C’è altro da aggiungere?

Lo script può essere utilizzato dalla linea di comando (per capirci, dal Terminale), lasciandolo esattamente com’è ed eseguendo il comando pdf2csv.R seguito dal nome dal file da convertire (se il nome del file contiene degli spazi va scritto fra virgolette),

	./pdf2csv.R file-da-convertire.pdf

che produrrà due file .csv contenenti il testo estratto dal file PDF. Il primo, con lo stesso nome del file di partenza, ha le righe numerate e cerca di riprodurre per quanto è possibile il layout del file originale. Nel secondo, salvato con il suffisso -clean, mancano i numeri di linea e vengono rimossi tutti gli spazi in eccesso, rendendolo più adatto ad una analisi automatica, in particolare quando il testo si estende per tutta la pagina (il primo file, invece, è molto più utile quando il testo è organizzato in colonne).

Prima di usare per la prima volta pdf2csv.R bisogna renderlo eseguibile tramite il comando chmod (ne ho già scritto diffusamente qui).

	chmod u+x pdf2csv.R

In alternativa si può lanciare lo script tramite il comando Rscript installato con R, senza che sia necessario renderlo eseguibile.

	Rscript ./pdf2csv.R file-da-convertire.pdf

È preferibile che il file PDF da convertire si trovi nella stessa cartella di pdf2csv.R. In caso contrario il testo estratto viene comunque salvato nella cartella dove si trova la script (ve l’avevo detto che lo script era molto semplificato!).

Per eseguire pdf2csv.R all’interno di RStudio bisogna commentare la linea 12 (basta aggiungere un # all’inizio della riga) e attivare la riga 14 o 15 (ma solo da una delle due) togliendo il # iniziale. Se si attiva la riga 14, si deve anche modificare la stringa file-da-convertire.pdf, sostituendola con il nome del file da convertire. Se invece si attiva la riga numero 15, al momento dell’esecuzione dello script comparirà una finestra grafica da cui selezionare il file PDF desiderato.

Nel repository su GitHub di questo articolo ho inserito dei file PDF di complessità crescente con cui fare qualche prova, fra cui un documento di quasi 1000 pagine (un vecchio manuale di riferimento del formato PDF, potevo scegliere qualcosa di diverso?), che può essere utile per valutare la velocità di conversione dello script. Non è necessario farlo a mano, il tempo di esecuzione di un qualunque programma o script si può misurare in modo preciso dal Terminale anteponendo il comando di sistema time, come mostrato qui sotto.¹

	time ./pdf2csv.R PDFReference.pdf

Come piccola chicca finale, ho aggiunto al repository su GitHub un file PDF contenente del testo (apparentemente) nascosto, provate a convertirlo e vi accorgerete di quanto sia banale recuperare il testo completo.

Generare automaticamente dei documenti con AWK

Tirar fuori il testo contenuto in un file PDF è quasi sempre solo il primo passo del lavoro, perché quello che vogliamo veramente è filtrare il contenuto del documento mantenendo solo le informazioni che ci interessano. Nel caso specifico, io avevo bisogno di selezionare dalla domanda di concorso precedente solo i dati relativi ad una specifica tipologia di attività (ad esempio tutti gli articoli scientifici pubblicati), salvandoli in un file ad hoc. E, già che c’ero, volevo anche costruire una tabella LaTeX per ciascun articolo. Una cosa abbastanza facile da fare con AWK.

Di AWK ho già parlato tempo fa e non mi ripeterò, dirò solo che è un linguaggio ideale per analizzare un file di testo una riga alla volta, verificando se si presentano determinate condizioni ed eseguendo le operazioni programmate corrispondenti.

Nonostante i suoi tanti pregi, AWK ha una limitazione piuttosto seria: per come è strutturato, AWK deve per forza di cose esaminare tutto il file senza poter tornare indietro, e quindi è piuttosto difficile fargli eseguire delle operazioni basate su condizioni multiple complesse. È molto meglio (quando è possibile) scrivere più script AWK, da eseguire in sequenza sullo stesso file di partenza o sull’output generato dallo script precedente, piuttosto che cercare di combattere con le limitazioni del linguaggio, complicando a dismisura il codice.

In una prima versione di questo articolo avevo pensato di utilizzare un breve estratto della mia domanda di concorso precedente per descrivere il funzionamento degli script in AWK. Ma mentre scrivevo mi sono accorto che il discorso sarebbe stato così specifico da essere quasi inutile. Ho preferito quindi preparare un piccolo file PDF tratto dagli ultimi post pubblicati su Melabit, con l’intestazione in YAML² di ciascun post seguita dalla prima frase del testo in Markdown e, quando c’è, dal link all’immagine iniziale. L’ho scelto perché la struttura di questo file assomiglia moltissimo a quella della mia domanda di concorso ma, allo stesso tempo, può essere uno schema di partenza applicabile a casi più generali.

Questo file PDF può essere considerato come la stampa di un piccolo _database_ di informazioni correlate, dove ogni post è un _record_, suddiviso a sua volta nei vari _campi_, rappresentati dalle righe di intestazione e dalla frase di testo.

Il file PDF si chiama Melabit ultimi post.pdf e, come gli altri file PDF, è disponibile nel repository su GitHub di questo articolo. Se lo aprite con Anteprima, noterete subito che ci sono delle righe vuote che separano chiaramente un post (nel linguaggio dei database, un record) dall’altro. Ma convertendo il file in testo,

	./pdf2csv.R "Melabit ultimi post.pdf"

(le virgolette sono necessarie perché il nome del file contiene degli spazi), le righe vuote scompaiono e le uniche interruzioni presenti nei due file CSV prodotti dallo script di conversione corrispondono al cambio pagina. Non so se questo sia un baco o una caratteristica voluta di pdftools, ma sta di fatto che è una particolarità con la quale dobbiamo fare i conti se vogliamo analizzare il testo con AWK.

Sembra una sciocchezza, ma senza le giuste interruzioni non è immediato riconoscere la fine di un record prima di iniziare ad esaminare quello successivo, in modo da chiudere correttamente la tabella LaTeX corrispondente al record appena esaminato e ad aprire quella relativa al record successivo. Inoltre, mentre in questo caso specifico la struttura del file PDF è volutamente molto semplice e ripetibile, nella maggior parte dei casi reali il documento da cui estrarre i dati può contenere informazioni strutturate in modi diversi, i campi da analizzare possono essere distribuiti in modo irregolare o mancare del tutto e ci possono essere incongruenze nella loro denominazione. Gestire tutti i casi possibili con un unico script lo renderebbe rapidamente troppo complesso.

Molto meglio affrontare il problema un pezzetto alla volta, utilizzando uno script specifico per ciascun tipo di informazione da estrarre (io ho avuto bisogno di 6 script AWK per eseguire tutto il lavoro di esportazione dei dati, o meglio quasi tutto il lavoro, perché per i casi meno frequenti ho preferito il buon vecchio copia-incolla manuale). In fondo è la stessa logica di Unix, che mette a disposizione un gran numero di strumenti semplici che messi insieme, come tanti mattoncini Lego, riescono a fare cose incredibili.

Un primo script, addblanklines.awk, può servire per inserire nel file CSV di partenza una riga vuota prima di ogni record (una cosa piuttosto semplice da fare in questo caso, dato che ogni post inizia sempre con la stringa “layout: post”). Lo script, appena quindici linee di codice, lo trovate “in bella” nell’immagine qui sotto (ma anche in questo caso il sorgente è su GitHub).

Bastano solo due linee di codice, la #4 e la #9, per aggiungere le righe vuote al posto giusto. Ma già che ci siamo, è conveniente dare anche una ripulita al file CSV togliendo le righe inutili, come quelle che contengono il numero di pagina o la stringa --- che segna l’inizio e la fine dell’intestazione in YAML (linee #5 e #12). Eseguendo lo script sul file CSV originale, si ottiene un nuovo file CSV con i vari record ben separati uno dall’altro.

	./addblanklines.awk "Melabit ultimi post-clean.csv" > file-con-righe-vuote.csv

Fatto questo, il passo successivo è semplice. Basta scansionare il file CSV appena generato, file-con-righe-vuote.csv, in cerca della stringa target layout: post e, ogni volta che se ne trova una, generare una nuova tabella LaTeX riempiendola con i dati tratti dalle voci (o più propriamente campi) successive. Il codice del secondo script, cvs2table.awk, è visibile nell’immagine qui sotto (mentre il sorgente è sempre su GitHub).

Lo script è relativamente lungo, sono più di 80 linee di codice, compresi commenti e righe vuote, ma una gran parte serve per implementare la funzione (linee #3-25) che riarrangia le informazioni presenti su più linee consecutive del file CSV in modo che vengano stampate su un’unica riga, e per generare la struttura di base del documento LaTeX (linee #35-42 e #83).

Tolte queste, il resto del codice è semplice, si tratta più che altro di scrivere le stringe giuste al momento giusto e di tenere conto dei casi in cui le informazioni si estendono su più linee consecutive (come succede ad esempio alle linee #61-62 e #66-73). Non entrerò nei dettagli di come funziona lo script, questo non è un corso di AWK (né tantomeno di R), basterà per ora dire che è scritto in modo da essere facilmente adattato a gestire esigenze analoghe. Per usarlo, si deve eseguire lo script usando come file di input file-con-righe-vuote.csv e salvando il risultato dell’elaborazione in un file LaTeX, che qui sotto ho chiamato (con la mia solita scarsa fantasia) lista-articoli.tex.

	./cvs2table.awk file-con-righe-vuote.csv > lista-articoli.tex

Mettere tutto insieme

Proviamo allora ad eseguire tutti insieme gli script presentati in questo articolo, in modo da ottenere il risultato finale desiderato. Dobbiamo prima di tutto convertire il file PDF in CSV con

	./pdf2csv.R "Melabit ultimi post.pdf"

che genera automaticamente il file “Melabit ultimi post-clean.csv”. Fatto questo, si eseguono in sequenza i due script AWK, salvando l’output del primo in un file intermedio.

	./addblanklines.awk "Melabit ultimi post-clean.csv" > file-con-righe-vuote.csv
	./cvs2table.awk file-con-righe-vuote.csv > lista-articoli.tex

Il risultato finale è un file LaTeX ben ordinato con una tabella per ogni articolo, come quello mostrato nella figura qui sotto la cui regolarità, messa in evidenza dai colori delle parole chiave, fa pensare ad uno spartito musicale.

Ma ha senso creare un file intermedio solo per trasferire l’output del primo script al secondo? Molto meglio usare il meccanismo di piping tipico in Unix, con il quale si può trasferire automaticamente il risultato dell’esecuzione di un comando all’ingresso di quello successivo, collegandoli con il carattere | (pipe)?³ Con il piping, i due comandi AWK precedenti possono essere eseguiti uno dopo l’altro in questo modo,

	./addblanklines.awk "Melabit ultimi post-clean.csv" | ./cvs2table.awk > lista-articoli.tex

evitando l’uso di un file intermedio. In questo caso non fa molta differenza, ma quando si devono trattare file molto grossi, il piping è molto più efficiente (con i velocissimi dischi SSD odierni non ce ne accorgiamo più, ma ai tempi dei dischi meccanici la scrittura di grossi file sul disco era un vero collo di bottiglia) e, cosa che non guasta mai, evita di intasare il disco rigido con un gran numero di file inutili.

E poi il piping è un meccanismo intrinsecamente elegante, che non a caso è stato adottato anche in alcuni linguaggi di programmazione odierni, come si può vedere nello script R mostrato nella prima parte di questo articolo (linee #24-25 e #35-37), dove il simbolo | usato in Unix è sostituito dalla strana combinazione di caratteri %>%, piuttosto fastidiosa da scrivere con una tastiera italiana (io almeno sbaglio sempre qualcosa).

Conclusioni

Chi ha l’occhio allenato si accorgerà facilmente che il file LaTeX risultante contiene alcuni errori piuttosto evidenti. Li ho lasciati apposta non solo per non complicare ulteriormente il codice, ma anche per mostrare quanto sia complicato il lavoro di estrazione automatica dei dati da file strutturati in modo non perfettamente regolare. Non è certo un caso che in questo campo ci sia una grossa attività di ricerca che prova a superare gli ostacoli e a rendere il tutto il più semplice e il più efficiente possibile.

Il comando time è presente di default nei sistemi operativi Unix come Linux e macOS. Su Windows time non esiste, ma si possono usare degli strumenti equivalenti. ↩︎
YAML è un linguaggio di markup particolarmente adatto per definire dei file di configurazione e, in generale, per rappresentare informazioni strutturate in modo semplice e leggibile, molto più facile da usare di strumenti più noti come XML e JSON. ↩︎
Il piping è uno dei meccanismi principali che rendono Unix una specie di Lego informatico. ↩︎

Il CNR è anche questo: concorsi in LaTeX

Sun, 08 Nov 2020 06:00:00 +0000

Nella puntata precedente ho raccontato della mia corsa contro il tempo dell’estate, una prova assurda come quelle di Giochi senza frontiere, ma senza allegria.

Inutile però dilungarsi ancora in dettagli poco comprensibili ai non addetti ai lavori. Meglio parlare invece di cosa ho fatto io per superare questa prova, cercando di sfruttare quel poco che so di LaTeX e di programmazione.

Perché, l’ho già detto ma mi ripeto, qualche nozione di programmazione può aiutare a cavarsela meglio con le tante rotture di cabasisi che dobbiamo affrontare ogni giorno.

Se c’è una cosa sulla quale sin dal primo momento non ho avuto il minimo dubbio, è che non avrei usato Word per preparare il curriculum professionale. Word non mi piace, si sa, ma in questa scelta non c’era nessuna prevenzione, era solo un modo per preservare la mia salute mentale.

Word ha grosse difficoltà a gestire strutture complesse come le tabelle. Una, due, tre, dieci tabelle vanno ancora bene, ma qui si trattava di creare centinaia e centinaia di tabelle diverse, una per ogni titolo – articolo, progetto, software, brevetto, insegnamento, incarico – inserito nel curriculum professionale. Dopo un po’ Word sarebbe letteralmente impazzito nel maneggiare tutte quelle tabelle, facendomi perdere un sacco di tempo prezioso.

Con LaTeX il problema non si pone. Un documento LaTeX è un normale file di testo e il fatto che contenga tabelle, liste o semplici paragrafi non fa molta differenza, sono solo delle porzioni di testo strutturate in modo diverso. Il peggio che può capitare è che il compilatore LaTeX impieghi qualche secondo in più a convertire il documento LaTeX in PDF.

Il fatto che i documenti LaTeX siano dei file di testo mi permetteva anche di generare automaticamente le tabelle relative a ciascun titolo inserito nel curriculum professionale, una cosa impossibile da fare con Word e che ha velocizzato moltissimo tutto il lavoro.

Già perché, non l’ho detto prima, il curriculum professionale andava sì scritto in Word, ma poi la sottomissione andava fatta in PDF,¹ utilizzando (ci credete?) la piattaforma online per i concorsi dismessa così improvvidamente. In pratica il modello in Word fornito dall’amministrazione serviva solo come indicazione di massima di come dovesse essere organizzato il curriculum, ma niente impediva di utilizzare altri strumenti. L’unica cosa davvero importante è che il layout del file PDF corrispondesse a quello previsto dall’amministrazione.

Riprodurre in LaTeX il modello originale in Word non è stato difficile: la classe memoir è molto flessibile ed è particolarmente adatta a produrre tutti quei documenti che escono dai canoni classici di LaTeX, mentre i package geometry, booktabs, multirow e titlesec permettono di regolare finemente i dettagli del documento finale.

Sia chiaro, preparare un modello di documento LaTeX partendo da zero non è mai facile, a meno di non essere dei veri esperti. Per fortuna avevo già fatto delle cose simili in passato e mi è bastato modificare qualche dettaglio per ottenere quello che mi serviva.²

Il modello LaTeX era però il problema minore, ciò che importava davvero era riuscire a riutilizzare il più possibile il lavoro fatto in passato. Come già detto nel post precedente, i soloni che ci governano non avevano previsto nessuna possibilità di esportare i dati già presenti sulla piattaforma online. L’unica possibilità era quella di partire dal curriculum in PDF preparato per un concorso precedente (del 2013, ben sette anni fa).

Per fortuna ho una certa esperienza nell’estrazione di dati dai documenti PDF, un problema molto attuale dato che tante istituzioni, non solo nazionali ma anche internazionali, sono molto restie a condividere i loro dati in formati standard utilizzabili da chi, come me, si occupa di estrarre informazioni dalle serie temporali di misure. Quando va bene il meglio che si riesce ad ottenere sono dei file PDF contenenti delle tabelle mal strutturate, che bisogna ingegnarsi a convertire in formati usabili per le analisi. Mi è bastato quindi adattare uno script in R sviluppato per altri scopi per riuscire a convertire la domanda in PDF in un file CSV ben ordinato.

Partendo dal file CSV e con qualche semplice script in AWK (un’altro tool di base di cui non potrei mai fare a meno) è stato quasi un gioco da ragazzi estrarre i dati relativi ai titoli già presentati in quel concorso, salvandoli in file differenti in base alla tipologia in modo che poi fosse più semplice aggiungere uno ad uno i titoli mancanti (dal 2013 ad oggi ce ne sono state di novità!). Il modello LaTeX si occupava poi di importare questi file nella sequenza corretta producendo il curriculum completo.

Già che c’ero, con gli stessi script potevo anche costruire automaticamente le tabelle LaTeX dove incasellare ciascun titolo. È una cosa più difficile da spiegare che da fare, ma che ha rappresentato un vantaggio incomparabile rispetto a creare le tabelle una ad una con Word.

Devo ammettere che gli script AWK non erano perfetti, purtroppo me ne sono accorto solo dopo aver iniziato il lavoro di inserimento dei nuovi titoli. Ma dato che questi script mi servivano solo una volta, ho preferito correggere a mano gli errori piuttosto che perdere altro tempo a perfezionarli.

Lavorare con file diversi per ciascuna tipologia (o fattispecie, il termine preferito dai nostri vertici amministrativi) aveva un altro grosso vantaggio. Avendo separato il modello LaTeX, che gestiva l’aspetto generale del curriculum professionale, dai dati riportati nei diversi file, potevo velocizzare parecchio la fase di (diciamo così) debugging del documento finale. In altre parole, se lavoravo sugli articoli scientifici scritti nel corso della mia carriera, potevo importare nel modello generale LaTeX solo il file relativo, lasciando fuori tutto ciò che riguardava le altre attività svolte. Analogamente per le altre tipologie di documenti. Sembra una cosa da niente, ma quando si passano le giornate ad inserire i dati di decine di nuovi documenti, avere a disposizione un file PDF più snello e poter controllare più rapidamente di non aver fatto errori e di non aver dimenticato niente può davvero fare la differenza.

Un altro aspetto chiave dell’usare LaTeX al posto di Word è stato il fatto di poter numerare a piacere le singole tabelle. Su questo la confusione era massima. Il principio generale era chiaro, i vari titoli delle Categorie A e B andavano inseriti rispettando un ordine temporale inverso, dal più recente al più vecchio, assegnando un numero progressivo a ciascuna tabella. Quello che non era affatto chiaro era il come.

Modello di curriculum professionale: titoli della Categoria A.

Modello di curriculum professionale: titoli della Categoria B.

C’era chi affermava che si dovessero numerare progressivamente i documenti della Categoria A, gli ormai famosi Prodotti della Ricerca, indipendentemente dalla loro tipologia ma tendendo conto solo della data, ricominciando la numerazione dal principio una volta passati ai titoli della Categoria B, dove invece i titoli andavano raggruppati in base alla tipologia. Altri pensavano che fosse preferibile raggruppare tutti i titoli della Categoria A per tipologia (prima tutti gli articoli, poi i capitoli di libri e gli atti di congressi, poi i brevetti, e così via), ordinandoli dal più recente al più vecchio e numerandoli progressivamente, continuando la numerazione con gli stessi criteri una volta passati alla Categoria B. Altri volevano numerare anche le tipologie, un po’ come si fa con i capitoli di un libro tecnico. Insomma, ogni partecipante al concorso aveva la sua idea.

Come ha scritto qualcuno in un gruppo WhatsApp, “le migliori menti del Paese non riuscivano a interpretare le istruzioni del bando di concorso”. Non so se al CNR ci siano davvero le migliori menti del Paese, ma è evidente che tutta questa confusione derivava dalla difficoltà di interpretare un gergo burocratico astruso e inconsistente, incomprensibile per chi è abituato per professione ad essere preciso e rigoroso. A ciò si aggiungeva un motivo più banale, il timore di fare degli errori nella stesura del curriculum e di essere penalizzati per questo dalle commissioni di valutazione.

Io non avevo scelta. Avendo raggruppato tutti i miei titoli in file differenti in base alla tipologia e importando i file uno dopo l’altro nel modello generale LaTeX, non potevo fare altro che numerare tutti i titoli della stessa tipologia in base alla data (dal più recente al più vecchio), proseguendo la numerazione una volta passato ad un’altra tipologia e continuando a numerare progressivamente allo stesso modo anche i titoli della Categoria B.

Mi sembrava anche la cosa più logica da fare, perché questo ordinamento facilitava il lavoro della commissione, che così trovava raggruppati prima tutti gli articoli scientifici (che sono senza ombra di dubbio i titoli più importanti per un ricercatore), poi tutti i capitoli di libri o gli atti di congresso, poi i brevetti, e così via. Se l’ordinamento primario per tipologia era previsto esplicitamente per la Categoria B, perché non fare lo stesso anche per la Categoria A? Se poi alla commissione non piacerà, pazienza!

Inutile dire che ho usato git – il sistema di controllo delle versioni che è ormai uno standard di fatto nel mondo dello sviluppo – per gestire le revisioni di tutti i file che mi servivano per produrre il curriculum professionale finale: il modello generale in LaTeX, gli script in R e AWK e tutti i file CSV e LaTeX generati dagli script.

Con il sistema di controllo delle versioni potevo aggiornare i vari file LaTeX dei titoli sapendo di poter tornare indietro anche in caso di errori troppo gravi per essere recuperati a colpi di undo. Per fare un esempio, a un certo punto mi sono accorto che avrei dovuto scambiare due righe in tutte le tabelle del file relativo agli articoli (si veda la figura qui sotto). Con un buon editor di testo è una cosa che si fa in cinque minuti, ma sapere di poter usare git anche per annullare ogni singola modifica è una cosa che si apprezza solo dopo essersi spupazzati una ad una un migliaio di righe di codice LaTeX.

Interfaccia grafica di git con la quale è possibile accettare o annullare ogni singola modifica ad un file.

Git è troppo complicato? Può darsi, ma un sistema di controllo delle versioni è come un backup, finché va tutto bene non si capisce a cosa serva, ma quando si presenta un problema si ringrazia il cielo di averlo usato.

Guardando a ritroso mi accorgo che la preparazione di questo curriculum professionale è stata in parte un lavoro di programmazione, tutto sommato abbastanza divertente, seguita da una lunga e noiosissima fase di inserimento dei nuovi dati e di controllo che tutto fosse a posto, una cosa che sembrava non dovesse finire mai. Lavorando una decina di ore al giorno ho impiegato quasi un mese per completare il lavoro, un pelo in anticipo rispetto alla scadenza prevista. Uno spreco di tempo assurdo per quello che dovrebbe essere un evento normalissimo nella vita professionale di chi fa questo mestiere.

La versione finale del mio curriculum ha 248 pagine, un numero che per un matematico (o un programmatore) ha un certo significato.³ Chissà se la commissione che lo giudicherà sarà dello stesso avviso.

(Continua…)

Una cosa più che ragionevole, visto che un file PDF è molto più difficile da manipolare del corrispettivo in Word. ↩︎
Detto fra parentesi, se c’è interesse per l’argomento, potrei scrivere dei post specifici su LaTeX e dintorni, toccando non solo le basi ma anche argomenti più avanzati come questo. ↩︎
Ammetto che arrivare a 271 o a 314 pagine sarebbe stato meglio, ma ci proverò la prossima volta. ↩︎

Word e LaTeX a confronto

Fri, 15 Mar 2019 06:00:00 +0000

Macchinetta del caffè. C’è anche un collega, simpatico, divertente, con un passato piuttosto “vissuto”, uno dei migliori colleghi con cui trascorrere la fatidica pausa caffè di metà mattinata.¹ A un certo punto inizia a raccontare di quando, da “giovane”, aveva dovuto usare LaTeX per scrivere, di quanto poco gli piacesse e di come trovi Word infinitamente più comodo da usare.

Io dico qualcosa, parlo di riferimenti incrociati, di equazioni, di bibliografia, roba semplice, non mi azzardo a toccare aspetti più sofisticati, semantica, separazione fra aspetto grafico e contenuto, formato dei file e compatibilità futura. Non ho voglia e tantomeno tempo di discutere, tanto so già che non c’è verso di convincerlo, per lui Word è la modernità, il progresso, LaTeX è un reperto archeologico da mettere in soffitta.

Per puro caso, lo stesso giorno mi decido a leggere questo articolo, Weighted differential evolution algorithm for numerical function optimization, che avevo messo da parte da mesi. L’articolo non solo non è un granché, ma è anche impaginato in modo orrendo. Leggere è così fastidioso che non riesco nemmeno a concentrarmi sul contenuto.

C’è chiaramente lo zampino di Word. Il massimo dell’orrore è in questa mezza colonna…

Fig. 1. Esempio di articolo scientifico scritto in Word. A sinistra l’immagine originale di una breve sezione dell’articolo, a destra la stessa immagine con gli errori più gravi messi in evidenza.

Non sono esperto di grafica, ma salta all’occhio perfino a me che la resa finale è sciatta e poco professionale. Nell’immagine a destra ho provato a segnare gli errori più marchiani in ordine (personale) di importanza, (1) la spaziatura eccessiva fra le parole, (2) le formule matematiche inconsistenti, (3) gli spazi arbitrari all’inizio della riga, ma sono sicuro di non essermi accorto di qualche altro e(o)rrore. Ho anche messo in evidenza in giallo due formule con spaziature differenti del segno di “=” (la seconda è sbagliata).

E allora ho voluto provare cosa veniva fuori con LaTeX. Ho scaricato dal sito della rivista che aveva pubblicato l’articolo il package per LaTeX e ho riscritto l’articolo con quello che tanti (non solo il mio collega) considerano solo un reperto archeologico.

Il risultato, considerando solo la sezione incriminata, è qui sotto, a sinistra si può vedere l’originale in Word, a destra l’equivalente in LaTeX con le marcature corrispondenti ai vari “errori” di Word (le stesse immagini senza marcature sono disponibili qui).

Fig. 2. Confronto fra Word e LaTeX. A sinistra l’immagine dell’articolo originale in Word, a destra la stessa sezione riscritta in LaTeX.

Tengo a precisare che non ho fatto niente per “aggiustare” l’output di LaTeX (infatti il numero dell’equazione è sbagliato), mi sono limitato ad usare lo stile fornito dalla rivista, che utilizza dei font differenti da quelli con cui vengono impaginati gli articoli pubblicati, probabilmente perché sono di proprietà della casa editrice (Springer).

Ma, a parte al questione font, il confronto fra Word e LaTeX è impietoso: LaTeX riesce a spaziare le parole senza creare “buchi” antiestetici, le righe sono allineate perfettamente, le formule sono scritte in modo consistente e gradevole da vedere, che rende più facile capirne il significato. Anche l’unica equazione fuori testo ha quel tanto di spaziatura dal resto del testo che riesce a metterla in evidenza, come è giusto che sia.

Niente male per un software “vecchio” da mettere in soffitta, sviluppato solo perché all’autore non piaceva come era stato impaginato il suo ultimo libro.

Da oggi in effetti è un ex-collega. ↩︎

Da Keynote a PowerPoint

Fri, 22 Jul 2016 06:00:00 +0000

Nell’articolo precedente abbiamo visto che PowerPoint domina incontrastato quando si tratta di preparare una presentazione e che spesso ci sono dei motivi tecnici che rendono ancora più difficile provare a non usarlo.

E allora, come si può riuscire in pratica ad usare lo stesso Keynote per preparare le proprie presentazioni? Semplice, basta essere flessibili ed avere pronta qualche soluzione alternativa. Anzi, preferibilmente più di una.

Alternativa #1: Usare Keynote

La soluzione preferibile se si ha l’accesso fisico al sistema di presentazione (computer e videoproiettore): si realizza la presentazione in Keynote, si collega il proprio MacBook o iPad (o persino l’iPhone) all’ingresso VGA o HDMI del videoproiettore e si usa il MacBook o l’iPad per tenere la presentazione. Semplice, pulito ed efficace.

L’ho fatto anche pochi giorni fa e, come sempre, mi sono stupito di quanto l’interfaccia touch dell’iPad sia comoda per tenere una presentazione. Ho anche avuto la fortuna di essere il primo a dover parlare dopo la pausa caffé, per cui ho avuto il tempo di armeggiare con il videoproiettore e l’iPad senza avere addosso gli occhi di tutto il pubblico.

Alternativa #2: Esportare in PDF

Se non si ha l’accesso fisico al al sistema di presentazione, la soluzione che assicura la maggiore fedeltà della presentazione all’originale è quella di esportare il file Keynote in formato PDF. Usare un file PDF è anche l’unica alternativa possibile se si vuole usare LaTeX per realizzare la propria presentazione.

Ovviamente è possibile usare un file PDF solo se non si infarciscono le presentazioni di animazioni, effetti speciali o video, tutte cose inutili (in particolare le prime due) o che difficilmente funzionano su un computer sconosciuto (per la legge di Murphy, la probabilità che manchi proprio il programma o il codec necessario per visualizzare il video è sempre altissima).

Se è assolutamente necessario mostrare un video, è consigliabile copiare sulla chiavetta USB una versione portable¹ di VLC per Windows, da usare per mostrare il video al posto degli strumenti integrati nel computer. Personalmente sono riuscito a vedere ben pochi video durante una presentazione, in genere si bloccano o non funzionano affatto, e fanno vare delle vere figuracce agli oratori.

Oltre a VLC, che non si discute, preferisco portare sempre sulla chiavetta anche un lettore leggero e portable di file PDF per Windows, come ad esempio Nitro PDF Reader, che è gratuito e non ha quell’orrida pubblicità dinamica che non si può di certo propinare al pubblico nel corso di una presentazione.

Alternativa #3: Esportare in PowerPoint

Qualche anno fa le slide esportate da Keynote in formato PowerPoint avevano solo una vaga somiglianza con quelle originali, ma le ultime versioni di Keynote fanno un buon lavoro e riescono ad esportare in PowerPoint una versione piuttosto fedele all’originale. Ma attenzione, anche se la versione in PowerPoint è fedele sul Mac, non è assolutamente detto che lo sia anche su un PC su cui gira Windows.

A differenza di Word, infatti, i file PowerPoint non integrano i font usati per la presentazione, ma usano quelli presenti nel sistema. Sul Mac non ci sono problemi, i font usati da Keynote sono installati nel sistema e sono utilizzabili da tutte le applicazioni, quindi anche da PowerPoint. Ma su un comune PC non è affatto detto che siano installati gli stessi font, per cui Windows usa il font che, secondo lui, approssima al meglio l’originale.

Purtroppo il significato di secondo lui è opinabile, e troppo spesso Windows sbaglia in modo così grossolano da portare a risultati disastrosi: slide con scritte troppo grandi o troppo piccole, parti di testo invisibili o che escono dai margini della diapositiva, tanti di quei problemi che è preferibile rifare tutto da zero che correggere gli errori uno ad uno.

La cosa migliore è scegliere un template per Keynote i cui font siano presenti di default anche in Windows o modificare il template di Keynote prescelto, in modo che usi un font presente anche in Windows.

Assolutamente fuori discussione è provare ad installare i font incriminati sul PC usato per le presentazioni: non solo per motivi di licenza o di copyright, ma anche perché non è detto che gli organizzatori ci permettano di mettere le mani sul PC (io non lo farei, anche per un semplice font). E persino nel caso fortunato in cui si riesca ad avere il permesso, non si può essere sicuri al 100% di riuscire a concludere l’installazione senza problemi (stiamo sempre parlando di Windows). E allora sarebbero dolori, la presentazione diventerebbe impresentabile, con relativa figuraccia (voglio essere buono) davanti al pubblico.

Alternativa #4: Usare Keynote tramite iCloud

In teoria, questa alternativa è particolarmente interessante e flessibile. Ci si collega da un browser installato sul computer usato per le presentazioni al proprio account iCloud, e si usa Keynote direttamente dall’interfaccia web. Nessun cavo, nessuna chiavetta, nessuna possibilità di perdere o dimenticare qualcosa (a parte la password di iCloud).

Ma metto questa possibilità solo al quarto posto perché sono convinto che, prima di metterla in pratica, sia fondamentale essere sicuri di avere un collegamento di rete stabile e veloce, preferibilmente tramite un cavo ethernet o tramite un router Wi-Fi o 4G affidabile.

Un collegamento di rete di questo tipo dovrebbe ormai essere la norma, ma in Italia non è così, soprattutto al di fuori dalle città principali o dalle reti di università e centri di ricerca. Rimanere a guardare la rotellina che gira nel bel mezzo della presentazione deve essere veramente molto imbarazzante.

A proposito, prima di accedere al proprio account iCloud da un computer pubblico, è consigliabile cambiare temporaneamente la password di iCloud con una usa e getta. Non bisogna dimenticare, infatti, che un computer usato da tanti utenti sconosciuti ospita di sicuro una ampia popolazione di virus, spyware, keylogger, che potrebbero fare parecchi danni al nostro account. Meglio non fidarsi mai. La password usata normalmente per iCloud può essere ripristinata con calma una volta conclusa la presentazione, oppure al ritorno a casa o in ufficio.

Alternativa #99: Usare PowerPoint

Se le alternative precedenti sono tutte improponibili, ad esempio perché siete innamorati delle animazioni o delle transizioni strane, o prevedete di non avere accesso fisico al sistema di presentazione, o non potete valutare preventivamente la bontà del collegamento di rete dell’albergo che vi ospiterà, non fidatevi di quello cheho scritto e realizzate la vostra presentazione con PowerPoint. Non sarà il massimo, ma almeno funziona ovunque.

Conclusioni

I principi sono importanti ma altrettanto importante è riuscire a presentare il vostro lavoro nel modo più efficace possibile, evitando che il pubblico si ricordi di voi non per quello che dite ma per quello che succede mentre lo dite.

Da quando c’è Keynote credo di non aver mai preparato una presentazione con PowerPoint e ho utilizzato sempre una delle prime tre alternative. Stando sempre attento ad avere più di una possibilità: presentazione in Keynote già caricata sull’iPad e su iCloud, più relativo file PDF, anche questo già caricato e pronto ad essere usato in Acrobat Reader per iPad. Più file PDF salvato su una chiavetta USB, formattata in modo che sia compatibile con Windows, e magari anche su Dropbox, just in case… E provando sempre ad usare preventivamente le varie alternative, in modo da sapere cosa fare se qualcosa vada storto (prima o poi succede, e quando succede tutto questo oscuro lavoro preparatorio paga, altro che se paga).

Ma tutto questo purtroppo non basta ancora. È molto importante sapere quali strumenti usare per realizzare una presentazione, ma è ancora più importante conoscere i principi base di una presentazione moderna ed efficace. Se interessa, se ne può riparlare.

Cioè una versione di un programma per Windows che non ha bisogno di installazione ma che può essere eseguita direttamente da una chiavetta USB oppure copiando il solo file eseguibile in una qualunque directory del computer. ↩︎

Vita oltre PowerPoint

Thu, 21 Jul 2016 10:00:00 +0000

Se Word è lo standard di fatto per la scrittura dei documenti di testo (nonostante in realtà abbia ben poco di standard), PowerPoint domina incontrastato quando si tratta di preparare una presentazione.

Con una differenza fondamentale. Word, piaccia o non piaccia, qualche concorrente ce l’ha: non solo LaTeX, in particolare in ambito tecnico-scientifico¹, ma anche LibreOffice e OpenOffice che girano su tutti i principali sistemi operativi, o Pages per il solo Mac. Tutti programmi che fanno praticamente tutto quello che fa Word, anzi a volte perfino di più. PowerPoint, invece, non ha praticamente concorrenti significativi.

Perché usare PowerPoint

L’esigenza di avere delle alternative a PowerPoint è meno sentita di Word non solo perché, in genere, si producono molti più documenti di testo che presentazioni, ma anche perché preparare una presentazione è molto più semplice e divertente di scrivere un documento complesso. La struttura stessa di una presentazione aiuta: poche parole per ogni slide (a parte casi veramente estremi), tante immagini e tabelle, la bibliografia ridotta all’osso, niente rimandi incrociati o indici. Una vera delizia rispetto ad un documento in Word di 200-300 pagine!

C’è anche un motivo più tecnico: se non si ha accesso fisico al connettore del video proiettore per collegarvi il proprio computer (o il proprio tablet), non c’è niente da fare: o si da agli organizzatori il file in PowerPoint oppure si opta per una presentazione in PDF statica e senza effetti (cosa sempre preferibile), sperando che sul computer in uso sia installato un visualizzatore decente di file PDF.

Insomma, PowerPoint fa il suo lavoro in modo decente e non crea problemi di compatibilità. Perché cambiare, perché cercare di usare qualcos’altro?

Perché non usare PowerPoint

A me succede diciamo nel 50% dei casi di trovare un sistema di videoproiezione professionale, dove il computer collegato al proiettore è annegato in un mobile praticamente inaccessibile e dove l’unico punto di accesso fisico al sistema è un connettore per la chiavetta USB. Ma nonostante ciò, sono molti anni che non preparo una presentazione con PowerPoint (e forse non l’ho mai fatto in assoluto). Perché?

Perché anche se ci sono delle complicazioni da affrontare, sono convinto che tutto sommato ne valga la pena.

Prima di tutto per un fatto, diciamo così, filosofico: guardarsi intorno ed esplorare è sempre meglio di adagiarsi e di adeguarsi passivamente a quello che fanno tutti gli altri. In secondo luogo, perché, anche se sono poco usati, esistano prodotti alternativi che permettono di preparare una presentazione in modo ben più rapido, comodo, ed efficiente dii PowerPoint.

LaTeX?

Per le presentazioni non uso e non ho mai usato LaTeX. Perché LaTeX è pensato per separare il contenuto dalla sua visualizzazione grafica, ma nel caso di una presentazione la visualizzazione grafica coincide ed è funzionale al contenuto, e le due entità sono inseparabili.

Però è anche vero che LaTeX contiene molti ottimi strumenti specializzati per le presentazioni, da Beamer a TeXPower, da Powerdot a fancyslides, fino a pdfscreen che, secondo me, è il più comodo da usare nonché il più dinamico, anche se non viene aggiornato da parecchi anni. Chi volesse usare Beamer, può leggere un ottimo tutorial su un numero di qualche anno fa di PracTeX Journal e consultare una guida alle combinazioni di temi e colori del package. Trovo in particolare molto comoda la possibilità di partire da una combinazione qualunque di temi e colori ed esaminare tutte le alternative possibili cliccando sui link situati nella sezione “Switch”. Se non ho sbagliato a contare ci sono in tutto ben 2.380 combinazioni! Per pdfscreen, invece, esiste un ottimo manuale, che mostra praticamente anche le capacità di navigazione da una slide all’altra del package.

Però, lasciatemelo dire, Beamer, pdfscreen e gli altri package sono di sicuro ben fatti, ma le presentazioni realizzate con questi strumenti non hanno niente a che vedere con quelle preparate con PowerPoint e soprattutto con Keynote, il programma che uso esclusivamente per le mie presentazioni fin dalla primissima versione.

Keynote

Non ho nessun dubbio, sul Mac Keynote è in assoluto il migliore programma per le presentazioni. Uso Keynote fin dalla primissima versione del 2003; allora costava non proprio poco, 99 dollari o 119 euro, ma li valeva tutti, fino all’ultimo centesimo. Ora che di fatto è gratuito (basta acquistare un Mac per poterlo installare liberamente su qualunque altro computer Apple in nostro possesso), non c’è ragione di usare altri strumenti. E se ci si iscrive ad iCloud si può usare la versione web di Keynote anche dagli altri sistemi operativi. Naturalmente quest’ultima non è comoda e veloce come quella nativa per il Mac, ma con un collegamento di rete efficiente si può utilizzare senza troppi problemi.

Ma perché Keynote è meglio di PowerPoint e probabilmente anche di qualunque altro software di presentazione che venga in mente? Forse perché Keynote è un prodotto Apple e perché questo blog ha un occhio di riguardo verso Apple?

Neanche per idea (né per l’una né per l’altra domanda).

Keynote è meglio perché semplifica in un modo mai visto altrove il lavoro di realizzazione di una presentazione. Non è solo una questione di gradevolezza grafica, anche se basta confrontare la schermata di presentazione di Keynote con quella di PowerPoint per rendersi conto che siamo ad anni luce di distanza.

[caption id=“attachment_2657” align=“aligncenter” width=“605”] Schermata di presentazione di Keynote.[/caption]

[caption id=“attachment_2658” align=“aligncenter” width=“605”] Schermata di presentazione di PowerPoint.[/caption]

In realtà i vantaggi di Keynote sono così sottili che è difficile descriverli in modo efficace e si notano appieno quando si prova ad usare veramente il programma.

Una delle cose più utili è l’adattamento dinamico della dimensione dei caratteri inseriti in una casella di testo. Sembra una sciocchezza, ma permette di non preoccuparsi del fatto che il testo inserito possa uscire dallo spazio assegnato o, peggio, che risulti nascosto alla vista. È vero che in una slide non bisogna mai scrivere troppo, ma ci sono casi in cui questa funzione serve parecchio, in particolare per le slide che mescolano testo e immagini, dove le caselle di testo sono più piccole del normale.

Altrettanto utili sono le linee guida gialle che spuntano fuori ogni volta che si prova ad allineare un oggetto contenuto in una slide con quelli circostanti (indipendentemente dal fatto che sia un box di testo, una forma, una tabella o una immagine). In Keynote le linee guida compaiono non solo quando gli elementi sono allineati fra loro o con i margini della slide, ma anche ogni volta che sono distribuiti in modo omogeneo nella slide stessa. Provate ad usarle una volta e non potrete più farne a meno.

Ancora più evidente è la comodità della funzione di inserimento delle immagini nelle slide: basta trascinarla all’interno della maschera di visualizzazione definita dal template e a dimensione dell’immagine si adatterà in modo automatico alla dimensione e alla forma della maschera. Diversamente da PowerPoint, con Keynote è molto facile modificare non solo la dimensione dell’immagine o la sua posizione all’interno dell’area di visualizzazione, ma perfino la maschera stessa, in modo da ottimizzare la porzione di immagine mostrata sullo schermo.

Non è infine da trascurare la possibilità di stabilire una gerarchia nelle slide, molto utile per raggruppare le slide che trattano lo stesso argomento o per mostrare o nascondere rapidamente interi gruppi di slide nella vista laterale delle miniature, rendendo molto più facile muoversi lungo la presentazione quando questa contiene un numero elevato di slide. Oppure la possibilità di saltare la visualizzazione di determinate slide senza rimuoverle dalla presentazione: le slide saltate possono essere molto utili come materiale di riserva, per spiegare meglio un determinato concetto o come supporto quando si deve rispondere alle domande del pubblico.

Le versioni più recenti di PowerPoint per il Mac, almeno quelle contenute in Office 2011 e Office 2016, hanno pescato a piene mani da Keynote e riproducono in modo piuttosto accurato alcune delle funzioni appena descritte di Keynote. Ma c’è sempre qualcosa che manca, qualche piccolo dettaglio che lascia l’amaro in bocca. Le linee guida di allineamento di PowerPoint sono molto meno visibili di quelle di Keynote e a volte scompaiono, troppo rapidamente perché si riesca a trovare la posizione giusta. Le immagini possono essere trascinate direttamente nelle maschere di visualizzazione definite dal template, ma il ridimensionamento funziona in modo inconsistente: la prima volta l’immagine si adatta automaticamente all’area definita, le altre volte… dipende, qualche volta lo fa, qualche altra no, vai a capire perché. Potrei andare avanti ma spero di aver reso l’idea.

Tutto il resto

Potrei parlare anche di Impress, il software di visualizzazione di LibreOffice/OpenOffice (accidenti a loro per questo inutile e dannoso fork), di Google Presentazioni, di Canva o di Prezi, di Haiku Deck, ma non si può concentrare tutto in un solo articolo. E poi, ne vale veramente la pena? Impress e Google Presentazioni sono cloni di PowerPoint, Canva mi sembra più orientato alla grafica che a mostrare dati e informazioni, Prezi fa venire il mal di testa, Haiku Deck è carino ma non mi ha mai colpito particolarmente.

Ma non è finita qui… a presto per la seconda parte.

Come ho già notato, la maggior parte delle riviste e delle conferenze di questo settore accetta contributi sia in Word che in LaTeX. ↩︎

Da LaTeX a Word (e ritorno)

Sat, 02 Jul 2016 06:00:00 +0000

Nei giorni scorsi ho lavorato con dei colleghi a due articoli per una conferenza. Ci siamo divisi il lavoro: un articolo l’ho gestito io, scrivendo il testo in LaTeX e utilizzando Overleaf per poter lavorare in contemporanea con gli altri sul testo (di Overleaf parlerò in dettaglio in un prossimo articolo). L’altro articolo è stato scritto da un coautore in Word. Dopo averlo rivisto, ho dovuto però inserire io stesso le correzioni, perché sarebbero state incomprensibili a chiunque altro.

Ogni volta che uso Word per più di una oretta mi chiedo come sia possibile che tutti (o quasi) trovino normale utilizzare questo programma per scrivere, senza porsi mai il problema di cercare alternative più adeguate. Naturalmente è successo anche questa volta.

Ma cosa c’è che non va in Word dal punto di vista di chi è abituato a scrivere usando sistemi più efficienti come LaTeX o, come per questo articolo, Markdown?

Scrivere documenti complessi in Word

Normalmente uso Word solo per scrivere lettere e relazioni, documenti relativamente semplici e con una formattazione poco sofisticata.

Un articolo per una conferenza è tutta un’altra cosa, sia perché deve rispettare un layout piuttosto rigido sia perché contiene, oltre al testo, una serie di elementi relativamente complessi e con un formato ben definito come le figure, le tabelle, le equazioni o la bibliografia.

In genere gli organizzatori delle conferenze forniscono un documento di esempio (template), che contiene gli elementi fondamentali del documento già formattati nel formato desiderato, rendendo così molto più facile rispettare le specifiche.¹

I template sono quasi sempre sia per Word che per LaTeX, ma per questa conferenza gli organizzatori hanno messo a disposizione solo un template per Word.

Dopo aver riprodotto il template fornito in LaTeX (una cosa piuttosto semplice, per fortuna) il lavoro sul primo articolo non ha avuto storia: correzioni al testo, aggiustamenti a tabelle e figure, bibliografia, tutto è filato via liscio e senza troppi problemi.

Con l’altro articolo la storia è stata ben diversa.

Manchevolezze di Word

Passare ad usare Word dopo giorni di immersione in LaTeX ha messo a nudo ancora più del solito le manchevolezze del programma di Microsoft. Il fatto che i due articoli fossero formalmente molto simili, con più o meno lo stesso numero di pagine, di figure e di tabelle, parecchie equazioni ed un numero analogo di elementi di bibliografia, ha reso ancora più impietoso il confronto fra i due sistemi di scrittura. Nonostante siano tutte cose note e stranote, credo che un buon ripasso ogni tanto non faccia male.

Velocità

L’articolo in Word è lungo appena 6 pagine e pesa appena 8 MB. Nonostante ciò è evidente che Word fatica a gestirlo. Scorrendo il documento si avvertono dei continui impuntamenti, che durano solo frazioni di secondo ma che non si verificano mai con l’altro articolo in LaTeX. Tutto ciò avviene usando un Mac di fine 2014, con processore i7, 16 GB di RAM e disco SSD, e l’ultima versione disponibile di Microsoft Office 2016 per OS X.

Il rallentamento dipende in parte dal meccanismo con cui Word gestisce la formattazione del testo e in parte dall’aver attivato lo strumento Revisioni, una delle cose (potenzialmente) più utili di Word.

Formattazione

Nessuno (o quasi) usa gli stili di Word, preferendo formattare a mano i vari elementi del documento. Se ad esempio si decide di cambiare il formato dei titoli dei capitoli da Times New Roman 14 punti italico a Arial 12 punti grassetto tutto maiuscolo, bisogna scorrere tutto il documento ed applicare a ciascun titolo le modifiche desiderate, sperando sempre di non dimenticarne qualcuno. Una cosa estremamente inefficiente e soggetta ad errori.

Purtroppo è lo stesso Word che incoraggia – o meglio, non scoraggia – questo modo di lavorare. Ma questo è ancora il meno. Il vero guaio è che dopo un po’ si perde il controllo di quello che succede. Basta cancellare una virgola o uno spazio qui e là per cambiare il font del testo adiacente, trasformare una parola in grassetto, o chissà che altro.

Perché succede? Nei linguaggi di markup come LaTeX o HTML, ci sono regole ben precise sul modo in cui devono essere annidati i comandi che definiscono lo stile del testo. Questi comandi esistono anche in Word, ma sono sempre invisibili all’utente. Dopo un po’ di cancellazioni, inserimenti, formattazioni e riformattazioni, i comandi nascosti di stile si mescolano fra loro in modo incontrollabile, complicando la gestione del testo da parte di Word e rallentando di conseguenza il programma.

Ci sono dei metodi per risolvere, o almeno limitare, il problema, ma con il template fornito dagli organizzatori non hanno funzionato. Probabilmente è il template stesso, che deriva da chissà che altro documento precedente, ad essere poco pulito, contribuendo al rallentamento di Word descritto sopra.

Figure e tabelle

Lo sanno tutti, inserire una figura (o una tabella, le due strutture si comportano esattamente allo stesso modo) in un documento di Word è una vera avventura, scappano di continuo da tutte le parti. Si mette una figura in un punto definito del testo, se ne fissa la posizione nella pagina ma dopo poche modifiche al testo la figura finisce chissà dove, preferibilmente in un’altra pagina o comunque in un punto in cui non ha nessun senso che vada. Dover riposizionare le figure e le tabelle dopo ogni minima revisione del testo diventa dopo un po’ una cosa esasperante, che fa venire voglia di liberarsi una volta per tutte e per sempre di Word e della Microsoft.

Didascalie

Word permette di associare ad ogni figura (o tabella) una didascalia che ne spiega il contenuto. Riesce perfino a numerarle automaticamente in un modo più o meno sensato. Però le posizioni delle didascalie non sono sincronizzate con quelle delle figure. Sembra incredibile (e contrario ad ogni logica), ma se si sposta una figura la didascalia non la segue automaticamente. A meno di non selezionare o di raggruppare entrambi gli elementi prima dello spostamento. Una cosa che però io, poco abituato a queste stranezze di Word, dimentico regolarmente. Ancora più curioso è che, tutte le volte che le figure si spostano da sole in modo incontrollato ed incontrollabile, le didascalie rimangono invece ben piantate al loro posto.

Ma se Word associa ad ogni figura la sua didascalia, perché poi non le tiene sempre insieme, come è giusto e logico che sia? E se Word ha al suo interno i meccanismi per fissare la posizione delle didascalie indipendentemente dal resto del testo, perché tali meccanismi non funzionano anche con le figure?

Equazioni

Le ultime versioni di Word usano per le equazioni un font (Cambria Math) e un formato ben definiti, che in teoria dovrebbero semplificarne l’uso. Solo in teoria. Perché se si copia da un altro documento una equazione formattata in modo diverso (magari perché così veniva richiesto dal template di quel documento), questa rimane sempre nel formato di origine e non c’è verso di farle acquisire automaticamente la formattazione del documento di destinazione. Inoltre, se si modifica la formattazione a posteriori per uniformarla al resto del documento, prima o poi, in genere salvando e riaprendo il documento, l’equazione torna nel formato originale.

Potrei sbagliarmi, ma l’unica soluzione efficace per evitare problemi con le equazioni è non usare il copia-e-incolla fra un documento e l’altro, ma riscriverle una ad una. Una cosa noiosissima, in un documento medio ci possono essere decine e decine di equazioni, non solo quelle normali fuori testo, ma anche i simboli matematici e le le equazioni incorporate nel testo.

Come se non bastasse, inserire una equazione in Word è un processo lentissimo, bisogna pianificare a priori come deve essere, selezionare uno ad uno i simboli tramite il menu e se si decide di cambiare qualcosa in corsa sono dei veri dolori. Secondo me è infinitamente più semplice e veloce farlo usando i codici testuali di LaTeX, più difficili da ricordare all’inizio ma decisamente molto più facili da scrivere o modificare.

Bibliografia

Scrivere la bibliografia degli articoli scientifici è una vera rogna. Ogni rivista ha il suo formato, in genere diverso in almeno qualche dettaglio da quello delle altre. C’è chi vuole prima il cognome e poi il nome degli autori e chi l’iniziale puntata del nome e poi il cognome. Chi preferisce l’anno di pubblicazione alla fine fra parentesi tonde e chi subito dopo gli autori, senza parentesi ma con un punto alla fine. Chi inserisce nella bibliografia il titolo degli articoli fra virgolette, chi senza virgolette ma in italico, e anche chi non mette proprio il titolo. Un vero delirio, assurdamente (e inutilmente) complicato.

Con LaTeX non ci si deve preoccupare di tutti questi dettagli. Per inserire la bibliografia in un documento LaTeX basta definire solo due elementi fondamentali: il file di stile che implementa il formato desiderato della bibliografia e il percorso ad un file BibTeX – più o meno un database testuale – che contiene i dati degli articoli da citare. Ci pensa poi LaTeX a prelevare dal file BibTeX i dati che gli servono e a formattarli come richiesto. Iniziare a gestire una bibliografia non è semplicissimo, ma una volta impostato uno o più database BibTeX, diventa veloce e molto pratico. Anche perché ormai i dati degli articoli si scaricano nella maggior parte dei casi dalla rete, senza doverli più inserire a mano.

Con Word gestire la bibliografia è decisamente più farraginoso. Anche Word implementa gli stili, ce ne sono una decina nell’ultima versione del programma, ma non si possono cambiare né modificare. E se anche fosse possibile farlo, di sicuro la cosa è più complicata di quanto sarebbe ragionevole.

Inoltre i dati di ciascuno degli articoli citati devono essere inseriti a mano, senza poterli importare da fonti esterne, a meno di non usare degli strumenti ad hoc² oppure di editare direttamente il file xml della bibliografia, una cosa non esattamente alla portata di chiunque usi Word. Finché la bibliografia si compone di una decina di articoli o se gli articoli citati sono sempre più o meno gli stessi, l’inserimento manuale dei dati è ancora fattibile. In tutti gli altri casi diventa indispensabile usare un gestore di bibliografie, come gli ottimi e diffusi EndNote, Papers (a pagamento), Zotero e Mendeley (gratuiti), che rispetto a BibteX hanno il difetto di avere ciascuno un formato di dati specifico e diverso da quello degli altri.

Revisioni

La gestione delle revisioni di un documento è uno punti di forza di Word e dovrebbe permettere a più persone di collaborare alla stesura di un documento, mettendo in evidenza le correzioni effettuate da ciascuno. Tutto questo in teoria.

In pratica le cose vanno diversamente. Word si perde a mostrare tutte le modifiche in modo così minuzioso da renderle incomprensibili. L’impostazione predefinita mostra tutte le correzioni in una finestra separata alla destra del documento, con decine e decine di linee che, partendo da questo elenco, puntano al testo modificato. Dopo un po’ non ci si capisce più niente. Molto meglio l’opzione che mostra le correzioni direttamente nel testo, anche se in questo caso si perde per forza di cose la visualizzazione del layout esatto del documento, perché sullo schermo compare contemporaneamente, con colori ed evidenziazioni specifiche, sia il testo cancellato che quello inserito in sua sostituzione. Contraddicendo così il concetto di mostrare sullo schermo esattamente quello che sarà il documento finale (WYSIWYG), che gli estimatori di Word considerano un punto di forza del programma (nonché di debolezza degli strumenti che, come LaTeX, separano la composizione del testo dalla sua resa grafica).

Inoltre, lo strumento Revisioni di Word contribuisce pesantemente a rallentare il programma. L’unico modo per evitare il rallentamento dovuto alla gestione delle revisioni è approvare (o rifiutare) abbastanza spesso le modifiche effettuate, perdendo così traccia della storia passata del documento, delle modifiche effettuate e degli autori di ciascuna correzione. A che serve allora uno strumento di revisione se dopo un po’ diventa di fatto inutilizzabile?

Conclusioni

Dopo aver usato più a lungo di quanto mi piaccia Word, sono ben contento di non doverlo fare troppo spesso. E trovo veramente incomprensibile che quasi tutti lo considerino un programma indispensabile, da usare supinamente ogni giorno per qualunque esigenza di scrittura.

Il bello (o il brutto) è che chi usa solo Word non si rende nemmeno conto di tutti i suoi punti deboli, e li considera una specie di necessità ineluttabile.

Dopo questo lungo articolo, mi piacerebbe moltissimo sapere cosa ne pensate. Trovate Word indispensabile per il lavoro di tutti i giorni o preferite usare programmi di videoscrittura alternativi come Pages o LibreOffice/OpenOffice? O magari usate strumenti non visuali, LaTeX, Markdown o chissà che altro? Usate la sezione dei commenti per esprimere la vostra opinione, anche e soprattutto se non siete d’accordo con quanto avete letto nell’articolo.

Approfondimenti

Per chi volesse approfondire, consiglio di leggere gli articoli o le pagine web seguenti.

Quando ho iniziato, nei primi anni ‘90, al posto del file del template si riceveva un foglio contenente le specifiche di tutti gli elementi del testo: margini, larghezza delle colonne, dimensione e tipo del font da usare per titolo, lista degli autori, testo, didascalie, e così via. Rispettare tutte le specifiche era un lavoro certosino, che richiedeva tanta pazienza e innumerevoli stampe di prova. ↩︎
Come ad esempio i plugin per Zotero o Mendeley. ↩︎

Markdown online

Tue, 31 Mar 2015 06:00:00 +0000

Markdown è uno strumento che permette di scrivere testi per il web utilizzando una sintassi semplificata rispetto a quella un po’ bizantina del linguaggio HTML e di convertire tali testi in codice HTML valido, pronto per essere incluso in una pagina web perfettamente funzionale.

Con il tempo, l’uso di Markdown si è esteso notevolmente ed ora è possibile usarlo per scrivere documenti di qualunque genere, convertendol in qualunque formato di testo significativo tramite Pandoc.

Io uso da tempo Markdown ogni giorno per scrivere di tutto, fra cui tutti i post di questo blog. Le uniche eccezioni sono gli articoli scientifici, per cui LaTeX è ancora insuperabile, e i documenti inviati dai colleghi, che mi obbligano ad usare l’odiato Word.

Quello che trovo però molto difficile è provare a spiegare l’utilità di Markdown a chi non l’ha mai usato. La risposta normale è “Perché mai imparare ad usare un altro strumento quando c’è già Word che va benissimo?”

Purtroppo in parte hanno ragione: finché non lo si prova è difficile rendersi conto dei vantaggi di Markdown e della sua estrema semplicità di uso.

Invece di provare a spiegare in teoria perché usare Markdown, non sarebbe meglio mostrare degli strumenti semplici semplici per iniziare ad usarlo senza troppi problemi?

E cosa c’è di meglio, oggi, che usare strumenti che funzionano direttemente nel browser, senza nulla da scaricare, installare o configurare?

Imparare Markdown

Per questo non c’è storia, il sito migliore è di sicuro This is Markdown, che insegna la sintassi di Markdown tramite una pagina web interattiva, che può essere modificata direttamente nel browser visualizzando immediatamente il risultato delle modifiche effettuate.

Strumenti di conversione

Anche qui non c’è molto da dire, lo strumento più interessante è Try pandoc!, che permette di usare Pandoc dal browser per convertire un documento scritto in Markdown (o in una dozzina di altri formati di testo) in formato HTML, RTF, LaTeX, oltre che in varie implementazioni di Markdown e in altri formati di testo meno noti.

Un altro strumento utile è Babelmark 2, che permette di valutare le differenze fra il codice HTML generato dalle varie implementazioni (dialetti?) di Markdown.

Detto fra parentesi, l’esistenza di svariate implementazioni di Markdown leggermente differenti l’una dall’altra è la vera debolezza di questo strumento di scrittura. Spero vivamente che prenda piede una implementazione standard come quella proposta da CommonMark (anche se criticata, a mio modesto parere un po’ scioccamente, da John Gruber, l’ideatore di Markdown).

Heck Yes Markdown fa il contrario: prende una pagina web e la converte in Markdown. Utilissimo per convertire in questo formato dei documenti scritti in passato in HTML, magari allo scopo di creare un archivio di pagine web in un formato uniforme o di riutilizzarli per un sito web statico. Ma forse altrettanto utile per implementare con il solo Markdown uno strumento simile a Readability. Da provare con i siti più pesanti e carichi di pubblicità e animazioni.

Editor online

In questo campo c’è solo da scegliere: gli editor online di Markdown sono fin troppi.

Per un uso occasionale consiglio, in ordine (molto) personale di preferenza, Dillinger, che permette di importare e salvare i documenti in Dropbox, Google Drive, One Drive e GitHub, StackEdit, il più completo e facile da usare, con sincronizzazione opzionale dei documenti con alcuni servizi cloud, Markdown Web Dingus di John Gruber, con una colonna con la sintassi di Markdown, Showdown, contenente una guida molto dettagliata alla sintassi di Markdown e Socrates, decisamente pulito e minimale. Tutti questi editor non richiedono registrazione e possono essere usati immediatamente, ma hanno lo svantaggio di non permettere il salvataggio dei documenti prodotti, a meno di non usare qualche servizio cloud come quelli citati sopra.

Per un uso più continuativo, oltre a Dillinger e StackEdit, consiglio di provare anche Beegit, che permette a più persone di collaborare alla stesura dello stesso documento, Draft, il più completo oltre che il più bello dal punto di vista grafico e Markable, che purtroppo, non so perché, mi fa pensare a un prodotto pensato per Windows.

Peccato solo per Editorially, un ottimo editor online che ha avuto però una vita molto breve.

LaTeX in offerta

Wed, 04 Mar 2015 15:30:00 +0000

Vorrei segnalare che oggi Packt Publishing offre gratis il volume LaTeX Beginner’s Guide di Stefan Kottwitz, una delle offerte più interessanti degli ultimi giorni.

Chi vuole scaricare il volume deve affrettarsi: l’offerta scade questa notte all’una, mancano poco più di 9 ore.