Word on Melabit

Fare una Maggie

Mon, 28 Jul 2025 06:00:00 +0000

L’ultimo articolo mi ha fatto letteralmente impazzire. Non per la lunghezza, anche se scrivere un testo di più di tremila parole e ventimila caratteri in due lingue diverse non è una sciocchezza.

Il vero problema è nato dal fatto che a un certo punto il file Markdown dell’articolo si è corrotto. Quando Hugo provava a convertirlo in HTML, il file generato conteneva, al posto delle lettere accentate italiane, il carattere di sostituzione �, quel rombo nero con dentro un punto interrogativo bianco che abbiamo visto in tante email e pagine web.

Ci ho perso ore prima di risolvere il problema.

Quando un file Markdown si corrompe

La prima ipotesi è stata che il file contenesse qualche carattere spurio, come uno spazio che non è davvero uno spazio, oppure una di quelle lettere strane che qualche anno fa hanno creato un certo scompiglio. Un bel problema cercarle nel testo, per cui ho fatto il contrario e ho scritto una espressione regolare che cercasse tutto ciò che non era normale, raffinandola via via che procedevo.

Alla fine l’espressione regolare è diventata questa.

[^a-zA-Z0-9àèéìòùÀÈÉÌÒÙ ,.;:`'"()\[\]\-^/_*#\n]

Una cosa molto terra-terra, ma l’importante è che funzionasse. Purtroppo non ha trovato niente di strano.

Per cercare di restringere il più possibile l’area che poteva contenere l’errore, ho iniziato a togliere parti di testo, prima poche righe e poi intere sezioni, ricompilando ogni volta il file tagliuzzato con Hugo. Niente, non c’era verso di togliere quegli stramaledetti rombi neri!

E qui ho fatto la cosa davvero decisiva: dopo aver provato e riprovato senza successo, ho lasciato perdere e sono andato a cena.

Sì, perché quando non si riesce a risolvere un problema – che sia risolvere un difficile esercizio di matematica, far funzionare un programma o scrivere l’attacco di quel post che ci frulla in testa da ore – la cosa migliore da fare è lasciare perdere e dedicarsi ad altro. Non so voi, ma con me funziona sempre alla grande.

E dopo cena mi è venuta l’idea: ho fatto una Maggie e tutto è andato a posto.

– Immagine generata da Google Gemini.

Fare una Maggie

Maggie è il diminutivo di Margaret Secara, diventata famosa per un trucco, semplice ma molto efficace, per recuperare un documento Word corrotto: cliccare sull’icona ¶ della Barra Multifunzione di Word per attivare la visualizzazione dei caratteri di formattazione (se la finestra di Word è stretta, l’icona potrebbe nascondersi all’interno della sezione dedicata ai paragrafi), poi selezionare tutto il testo tranne l’ultimo carattere di Invio (come mostrato in figura) e incollarlo in un nuovo documento vuoto.

Se non funziona, si può ripetere il procedimento copiando parti successive del testo in un nuovo documento, in modo da circoscrivere il più possibile la porzione corrotta.

La prima volta che ho usato questo trucco stavo lavorando su un documento di più di cento pagine, passato per parecchi colleghi e differenti versioni di Word, che era diventato ingestibile: ogni nuovo carattere impiegava secondi per comparire sullo schermo e Word andava continuamente in crash. Con la procedura descritta ho risolto il problema in un battibaleno.¹

Il trucco di Maggie funziona perché i file Word hanno una doppia struttura. La prima è quella che mostrata sullo schermo del computer, fatta di testo, immagini e tabelle, con divisioni in capitoli, sezioni e paragrafi, con grassetti, italici, sottolineature, con interruzioni di pagina, liste, rientri, tutte cose messe lì un po’ a casaccio dall’utente.

La seconda struttura è quella del file XML sottostante, che dopo un po’ di aggiunte, correzioni, cancellazioni, ripensamenti, diventa un fritto misto di tag XML innestati uno sull’altro, che rimangono però sempre invisibili all’utente e non vengono mai ripuliti e ristrutturati in modo coerente dal programma.

A meno di non farlo noi a mano, copiando tutto il testo in un nuovo documento, ma evitando come la peste l’ultimo carattere di Invio che, per qualche motivo arcano, contiene la chiave di accesso alle porcherie nascoste del documento Word.

Margaret Maggie Secara avrà scoperto questo trucco per caso, ma si è rivelato così utile da trasformare il suo soprannome in una parola vera e propria, come Kleenex, Band-Aid, Post-It, Tupperware o Google.

Ma sono documenti di testo!

Però i miei post li scrivo in Markdown, mica con Word. Ma anche così, ripartire da un documento fresco e copiarci dentro il contenuto di quello corrotto può rivelarsi il metodo più veloce per risolvere tanti problemi.

Ovviamente il trucco funziona con qualunque tipo di documento in testo puro, che sia scritto in Markdown, LaTeX, HTML, XML, JSON, Org mode… o in qualsiasi altro formato più o meno arcano che vi venga in mente.

Anzi, proprio perché, a differenza di Word, un documento di testo non nasconde nulla all’utente, non serve nemmeno evitare di copiare l’ultimo carattere di Invio; si può selezionare tranquillamente tutto il testo, copiarlo e incollarlo in un nuovo file vuoto.

Prima di farlo è sempre bene controllare che il testo non contenga dei caratteri spuri, utilizzando una espressione regolare simile a quella riportata più sopra.

E con questo l’articolo è finito. Le due sezioni qui sotto sono riservate solo ai più curiosi, che vogliono sapere cosa mi era successo davvero.

Solo per i più curiosi…

Perché il metodo funziona?

Una volta risolto il problema immediato, la curiosità ha avuto il sopravvento e mi sono chiesto perché il metodo descritto funziona con i documenti di testo. Come succede spesso, lavorare dal Terminale aiuta a risolvere i problemi più spinosi.

In un normale editor come BBedit o TextMate, il file corrotto appare perfettamente normale, ma se lo si visualizza nel Terminale con cat, si nota subito che tutti i caratteri accentati vengono sostituiti da dei ?, più o meno come succede convertendolo in HTML.

Il comando file dà poi la risposta definitiva. Se lo applico al file corrotto, file 2025-07-22-macos-tahoe-developer-beta-3.md, ottengo in risposta

Non-ISO extended-ASCII text, with very long lines (1264)

mentre con un qualunque altro file Markdown il risultato è (come è giusto che sia)

Unicode text, UTF-8 text, with very long lines (1264)

In altri termini, il file aveva perso la codifica UTF-8, trasformandosi in un generico file di testo non-standard.

Se me ne fossi accorto prima, avrei potuto usare iconv per correggere la codifica del file, ma in questo caso non c’è dubbio che il copia-e-incolla è molto più pratico.

Cos’è successo davvero?

Difficile a dirsi, ma ci sono degli indizi. Dato che l’articolo era molto lungo, l’ho scritto in più riprese un po’ sul Mac Mini e un po’ sull’Air.

In genere copio i file di lavoro in locale e li sincronizzo solo in un secondo momento. Ma questa volta cambiavo continuamente computer, per cui ho preferito lavorare direttamente sulla cartella sincronizzata (usando Syncthing, ma non credo che sia stato lui il responsabile; in quel caso avrei trovato dei file in conflitto, che invece non ci sono). Invece ci sono stati ogni tanto dei problemi di rete, e penso che sia stato proprio questo che ha finito per corrompere la codifica del file.

La morale? Lavorare in locale e sincronizzare solo quando si è finito. Oppure lavorare direttamente in rete solo quando il collegamento è stabile.

Ma quando non si può, meglio ricordarsi dei consigli della buona vecchia Maggie.

Pare che si possa recuperare un documento Word senza perdere traccia delle modifiche effettuate. La guida usa delle combinazioni di caratteri tipiche di Word per Windows, e quindi non è immediato applicarla alla versione per macOS. ↩︎

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. ↩︎

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. ↩︎

Il CNR è anche questo: concorsi senza frontiere

Sun, 25 Oct 2020 06:00:00 +0000

Lo so, è da un mese che non pubblico niente sul blog. Non che mi manchino gli spunti, tutt’altro, la lista di cose da scrivere si allunga ogni giorno di più. Ma è dall’inizio di agosto che mi trovo ad affrontare una scadenza importante dopo l’altra, e appena ne supero una eccone un’altra ancora più pressante. Dopo giornate come quelle delle ultime settimane, è difficile mettersi di nuovo alla scrivania la sera per aggiornare il blog.

Ma il mondo deve sapere… 😂😂😂😂😂 e quindi quello che segue è il racconto (lungo!) di cosa ha significato affrontare la scadenza più importante di tutte, che purtroppo è stata anche la più fastidiosa e frustante. Una gara contro il tempo che mi faceva pensare alle prove assurde di Giochi senza frontiere, ma senza la goliardia e il buonumore degli originali.¹

La storia interesserà, giustamente, solo a pochissimi frequentatori del blog. Tutti gli altri faranno bene a saltare direttamente alla seconda parte, deve racconto come ho affrontato questa prova con l’aiuto degli strumenti di cui parlo spesso in questo blog, LaTeX, R, script da Terminale, sistemi di controllo di versione.

Perché non è detto che uno debba imparare a programmare solo per fare delle cose serie. Anche riuscire a cavarsela meglio con le rotture di cabasisi di tutti i giorni può essere un’ottima scusa.

Tutto è cominciato ai primi di agosto, quando il CNR ha pensato bene di pubblicare i bandi di concorso ex Articolo 15 (dall’articolo del contratto che li prevede), per i passaggi di livello di ricercatori e tecnologi.² Erano dieci anni che non uscivano dei concorsi di questo tipo (che dovrebbero invece avere una cadenza biennale), cosa potevano scegliere i nostri ineffabili vertici se non il mese di agosto per pubblicare i bandi?

Estate rovinata. Perché partecipare ad un concorso per passare ad un livello superiore non è uno scherzo e può richiedere mesi di lavoro.

Lo so per esperienza. Nel 2013 partecipai ad un altro concorso (di tipologia differente) per passare a dirigente di ricerca, il livello più alto nel cursus honorum della ricerca italiana. Il bando (ovviamente!) uscì a luglio con scadenza a settembre ma poi, a causa del cattivo funzionamento della piattaforma web messa su in fretta e furia per gestire quel concorso, la scadenza venne rimandata più volte fino a novembre. Il motivo principale era la scarsa affidabilità della piattaforma web, che era tanto sovraccarica da andare continuamente in crash, cancellando senza pietà tutte le informazioni non ancora salvate. Mi ricordo ancora le alzatacce alle 4 del mattino, l’unico momento buono per inserire sulla piattaforma le informazioni tratte dalle centinaia di documenti richiesti per partecipare al concorso.³

Negli ultimi anni la piattaforma web è migliorata moltissimo e rappresenta ormai un archivio molto dettagliato dei documenti già presentati dai miei colleghi e da me ai vari concorsi a cui abbiamo partecipato nel frattempo. Un archivio che potrebbe essere molto utile per semplificare la partecipazione ai nuovi concorsi istituiti dal CNR.

E invece cosa pensano i soloni che ci governano e che, un pezzo dopo l’altro, stanno smontando quello che era uno dei migliori enti di ricerca multidisciplinari del mondo? Di abolire per questo concorso agostano la piattaforma web e di richiedere invece la compilazione di un modello di documento in Word (lo trovate in miniatura anche qui sotto), nel quale inserire tutte le migliaia di informazioni che costituiscono il cosiddetto curriculum professionale di ciascun partecipante al concorso. Aggiungendo danno al danno, i soloni suddetti non prevedono alcuno strumento per esportare le informazioni già inserite nella piattaforma online, costringendoci di fatto a ricominciare tutto da zero.

[gallery type=“thumbnails” columns=“3” autostart=“true” size=“medium” link=“file” ids=“4953,4954,4955,4956,4957”]

Il curriculum professionale è solo un lontano parente del normale curriculum vitae (CV), nel quale si condensano anni ed anni di lavoro in poche pagine leggibili. Qui si tratta invece di un dettagliatissimo e minuziosissimo elenco di tutto ciò che costituisce l’attività scientifica di un ricercatore: gli articoli pubblicati sulle riviste scientifiche o sugli atti delle conferenze, i libri o i capitoli di libri, i software sviluppati, i brevetti, i progetti, le attività di docenza, la partecipazione a commissioni tecnico-scientifiche e molto altro.⁴ Sono i cosiddetti titoli, ciascuno dei quali va inserito nel curriculum professionale in base alla sua fattispecie (un termine di estrazione giuridica che in questo contesto è improprio e che nel seguito sostituirò con tipologia).

Traduco per i non iniziati al gergo burocratico dell'ente. Per il CNR una fattispecie rappresenta un tipo specifico di attività svolta: un articolo scientifico è una fattispecie, un libro o capitolo di libro è un'altra fattispecie, i brevetti, i software, i progetti, gli incarichi, le docenze sono ulteriori fattispecie diverse, così come lo sono moltissime altre attività tecnico-scientifiche svolte nel corso della propria carriera.

Per confondere ancora di più le idee, tutte le attività di stampo più propriamente scientifico, e quindi gli articoli, i libri o i capitoli di libri, i brevetti, i software, vengono definite anche Prodotti della Ricerca, e sono suddivise a loro volta in fattispecie differenti (che naturalmente variano di concorso in concorso). Ciascun Prodotto della Ricerca, e più in generale ciascuna attività tecnico-scientifica svolta, rappresenta un titolo professionale, e va inserito in una tabella del curriculum professionale specifica per la sua fattispecie.

Se tutto ciò vi fa girare la testa, pensate a me che ho dovuto cercare di spiegarlo!

Inserire un nuovo Prodotto della Ricerca nell’orribile modello Word fornito dall’amministrazione non è uno scherzo: si deve selezionare la tipologia (o se preferite la fattispecie) giusta, duplicare la tabella originale vuota relativa alla tipologia scelta oppure una tabella già compilata, e infine (si fa per dire) inserire una ad una con molta pazienza le informazioni richieste. Alcune sono ovvie, come il titolo e gli autori di un lavoro scientifico. Altre sono piuttosto complicate da reperire, come l’indice di classificazione della rivista e il famigerato impact factor,⁵ informazioni che bisogna cercare consultando i siti web delle riviste oppure degli appositi database online, alcuni aperti a tutti, altri proprietari e a pagamento (sono carissimi, ma per queste inutili sciocchezze il CNR è sempre pronto a sprecare soldi). Infine ci sono le informazioni di cui non si capisce bene il senso, come il codice identificativo della rivista (ISSN) o peggio ancora il campo Altre informazioni, nel quale ognuno mette quello che gli pare.

E tutto ciò va fatto per ogni singolo Prodotto della Ricerca. I ricercatori più anziani come me, con una carriera ormai più che trentennale alle spalle e centinaia di prodotti della ricerca, partendo da zero hanno bisogno di parecchi giorni per inserire tutti questi titoli.

Ma questa è solo la prima parte della storia, quella che riguarda la produzione scientifica vera e propria e che va sotto l’ombrello di Categoria A. La seconda parte del modello Word se vogliamo è molto, molto peggio. Si tratta della Categoria B, quella che raccoglie tutte la attività di contorno alla ricerca vera e propria, le attività didattiche, quelle di diffusione della cultura scientifica, i premi, le partecipazioni ad organismi tecnici o scientifici, le responsabilità varie e soprattutto le partecipazioni ai progetti di ricerca.

Che è ciò che interessa davvero alla nostra amministrazione.

Perché i progetti di ricerca portano soldi, tanti soldi. I soldi che lo Stato non da più (il finanziamento ordinario copre ormai solo gli stipendi dei dipendenti), per cui se vuoi fare qualcosa devi partecipare a dei progetti di ricerca. Non importa quali, non importa se sono attinenti o no al tuo filone scientifico, non importa se sono davvero utili al progresso scientifico, o perlomeno alla società. L’unica cosa davvero importante è che i progetti portino soldi, perché sono quelli che fanno andare avanti la baracca. Nonché, attraverso rapine sempre più pesanti ai finanziamenti faticosamente acquisiti (preparare un progetto di ricerca è una faticaccia), permettono alla sede amministrativa centrale di prosperare alla grande, senza mai dare nessun supporto a questa faticosa attività di autofinanziamento.

Ormai sei un bravo scienziato se riesci ad acquisire finanziamenti, altrimenti sei uno sfigato qualunque. Potrai anche avere titoli scientifici inappuntabili, ma se non porti soldi puoi sognarti di vincere un concorso al CNR. Lo pensa l’amministrazione, ma lo pensano (purtroppo!) anche tanti colleghi rampanti, quelli che pesano le persone in base al denaro che hanno saputo conquistarsi, e che avrebbero fatto meglio a fare i broker piuttosto che i ricercatori.

Non a caso sono proprio i progetti a fare la parte del leone nella Categoria B del curriculum professionale. I progetti riguardano le prime due fattispecie della Categoria B e la varietà e quantità di informazioni richiesta è decisamente maggiore rispetto a tutte le altre tipologie: da dove sono arrivati i soldi, quanto ha introitato il progetto complessivo, quanto ha introitato il gruppo del CNR (Unità Operativa) di cui fa parte il candidato, quali erano gli obiettivi del progetto, quali risultati ha ottenuto, quanto è durato. E per come sono strutturati i progetti di ricerca, queste informazioni sono sparse su molteplici documenti, da cercare uno ad uno sul proprio computer o magari sulle copie cartacee di venti-trent’anni fa (per quei fortunati o previdenti che le hanno conservate), per cui compilare la tabella di un singolo progetto di ricerca può richiedere ore di lavoro. Un vero incubo!

Ma c’è una cosa che accomuna tutta la Categoria B del curriculum professionale. La richiesta ossessiva di pezze d’appoggio per qualunque cosa si sia fatta nella propria vita professionale: numeri di protocollo, delibere, decreti, provvedimenti.

Una richiesta ragionevole per le attività più importanti, come ad esempio gli insegnamenti universitari, che devono necessariamente essere autorizzati con apposite delibere. Molto meno ragionevole per altre attività normalissime per un ricercatore, come far parte del comitato organizzatore di una conferenza o di qualche commissione tecnico-scientifica, incarichi che vengono assegnati quasi sempre con una semplice email o che compaiono solo su un sito web che spesso viene disattivato al termine della conferenza.⁶

Come ha scritto benissimo un collega, “È stato davvero penoso vedere persone di valore doversi instupidire nella rincorsa del numero di protocollo, del quartile più alto, della dichiarazione del direttore o del responsabile del progetto, del link che non c’è più, e nel mentre erano costantemente infastidite da notizie che continuavano a ribaltare le modalità di compilazione di schede inutilmente minuziose: il numero progressivo, le fattispecie, le annualità. Un vilipendio di energie intellettuali, uno spreco di tempo e denaro, un alt irragionevole e su tutta la linea alle attività di ricerca, un’efficace distrazione da altri temi importanti legati al futuro della ricerca e del suo esercizio (es. PNR). Impegno per altro richiesto e pilotato con un bando uscito a ridosso della chiusura estiva imposta dall’Ente, tale da fagocitarsi una buona parte delle ferie”.

Non potrei essere più d’accordo.

(Continua…)

Alzi la mano chi se li ricorda. Giochi senza frontiere sono stati per tantissimi anni il gioco dell’estate per eccellenza, quello in cui concorrenti provenienti da ogni angolo dell’Europa si affrontavano in gare improbabili nelle quali dovevano evitare di essere travolti da una valanga mentre sciavano sulla sabbia, tirare via l’acqua di un lago con un bicchiere attaccato ad una canna da pesca o cercare di rimanere in equilibrio su una enorme palla di polistirolo. L’inventore di queste prove era un vero genio dell’assurdo. La dirigenza del CNR cerca continuamente di copiare da lui, ma non ha la stessa stoffa. ↩︎
I tecnologi del CNR sono una figura professionale anomale. In teoria dovrebbero essere coloro che gestiscono i grossi laboratori sperimentali, le infrastrutture di rete e così via. In pratica ormai, per ragioni troppo complesse da spiegare qui, una gran parte di tecnologi svolge compiti di tipo amministrativo, snaturando di fatto il ruolo. Per questo motivo, quando nel seguito parlerò dei ricercatori, mi riferirò sempre anche ai (pochi) tecnologi ancora degni di questo nome. ↩︎
Ci sono voluti due o tre anni per concludere l’iter di quel concorso, che naturalmente non ho vinto, anche se in una delle due graduatorie mi sono classificato piuttosto bene. La graduatoria era quella meno attinente al mio percorso professionale, ma queste sono le stranezze della burocrazia italiana, accoppiate alla, diciamo così, ostilità di uno dei commissari dell’altra graduatoria. ↩︎
Si può diventare direttore di un Istituto del CNR, direttore di Dipartimento e perfino Direttore Generale presentando un normalissimo curriculum vitae di 10-20 pagine, ma non ne bastano 200 per partecipare ad un concorso da dirigente di ricerca. ↩︎
La discussione di cos’è l’impact factor e perché lo definisco famigerato porterebbe troppo lontano dal nucleo principale dell’articolo. ↩︎
Più di una volta ho dovuto ricorrere al beneamato Internet Archive per cercare di reperire queste informazioni. ↩︎

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. ↩︎

Per un font Maryam perse la casa?

Sun, 16 Jul 2017 06:00:00 +0000

Sempre la solita storia. Arrivi a governare, con le buone o con le cattive, qualche disgraziato paese del mondo e improvvisamente ti ritrovi con conti in banca sempre più gonfi di denaro, ben nascosti nei peggiori paradisi fiscali.

Più il paese è povero più i suoi governanti si arricchiscono, sembra una specie di legge di natura. Ma che volete farci, bisogna pur pensare alla famiglia e al futuro, un colpo di stato è sempre in agguato, chiedere agli spiriti di Gheddafi o di Saddam Hussein che ci sono già passati. Chi vuole saperne di più di persona, invece, può dare una occhiata a questa versione interattiva e dinamica dei Panama Papers, 11.5 milioni di file che raccontano le peggiori nefandezze dei nostri giorni.

Il Pakistan è uno dei paesi più poveri del mondo, il suo PPA (PIL per abitante) lo colloca al 132° posto nel mondo, su 185 paesi (dati 2015). Nonostante ciò, Maryam Nawaz Sharif, la figlia dell’attuale primo ministro del Pakistan, Nawaz Sharif, può permettersi di comprare residenze costosissime nel centro di Londra tramite società offshore ospitate nelle Isole Vergini britanniche.¹

Maryam Nawaz Sharif naturalmente ha negato di essere la titolare delle società, sostenendo di far parte semplicemente dei loro consigli di amministrazione.

E come ha cercato di dimostrarlo? Fornendo alla commissione di inchiesta un documento che attestava la reale natura del suo coinvolgimento nelle società in questione, documento datato febbraio 2006 e scritto con Calibri, quello che è da anni il font di default di Word.

Però Calibri è stato reso disponibile al pubblico da Microsoft solo alla fine gennaio 2007, con il rilascio di Office 2007 e del derelitto Windows Vista. Praticamente un anno dopo la stesura del documento suddetto. Anche le prime beta pubbliche di Office e Vista sono state rilasciate solo a giugno del 2006. Qualche utente di Wikipedia ha pure cercato di cambiare la storia, provando a modificare la data di rilascio del font sulla pagina dedicata a Calibri.

C’è qualcosa che non quadra: o il documento è un banale falso, oppure la figlia del primo ministro pakistano è una eccellente ed insospettabile cracker, capace di scaricare di nascosto versioni ancora preliminari dei prodotti Microsoft e di usarle per i suoi documenti ufficiali.

Se le accuse di ladrocinio dovessero essere confermate, Calibri si rivelerà il font più costoso della storia, un font che vale quanto due o tre appartamenti a Londra.

È proprio vero che usare Word fa male.

Chi è interessato ad aprire una società nelle Isole Vergini può rivolgersi qui oppure qui, 1000 euro possono bastare. ↩︎

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.

Copia e incolla o drag-and-drop?

Thu, 26 Mar 2015 06:00:00 +0000

Lo spunto per questo post me l’ha offerto una collega, molto giovane e molto simpatica (anche se troppo spesso le parole collega e simpatico sono in antitesi), passata da meno di un anno al Mac.

Domanda: per inserire una immagine in un documento Word è meglio usare il copia e incolla o il drag-and-drop? I file risultanti sono uguali o no in termini di dimensioni e di velocità?

Fino a poche ore fa avrei detto si. Ma invece di chiacchierare proviamo a vedere in pratica cosa succede.

Prendiamo una foto qualunque, ad esempio trascinandola da iPhoto sul Desktop. La mia è stata fatta con l’iPhone 5c ed ha una dimensione di 3.4 MB.

Lanciamo Word 2011 e creiamo un documento vuoto sul Desktop in formato docx. Duplichiamolo immediatamente, in modo da avere due documenti identici. I due documenti appena creati dovrebbero essere grandi 21 kB ciascuno.

Apriamo ora la fotografia con Anteprima, copiamo l’immagine, incolliamola nel primo documento Word e salviamo subito il file, senza effettuare ulteriori operazioni. Selezioniamo la stessa foto sul Desktop, trasciniamola sul secondo documento Word e salviamo subito anche questo file.

Sorpresa: il primo documento, quello in cui abbiamo effettuato il copia e incolla, è grande 11.6 MB, il secondo solo 3.6 MB, poco più della dimensione della fotografia.

Sarà colpa del formato docx? Nemmeno per sogno, il risultato è praticamente identico anche se usiamo il vecchio formato doc al posto del docx.

Vediamo cosa succede con Pages (l’ultima versione disponibile, la 5.5.2). Creiamo come prima due documenti vuoti identici sul Desktop (saranno grandi 56 kB) e inseriamo nel primo la foto usando il copia e incolla e nel secondo il trascinamento. Verifichiamo la dimensione dei file risultanti: accidenti, qui è perfino peggio, 32.2 MB con il copia e incolla contro soli 3.6 MB con il drag-and-drop.

Ultima prova LibreOffice Writer, versione 4.2 (mi dispiace è un po’ vecchio, ma lo uso ancora meno di Word e Pages). I documenti vuoti sono grandi inizialmente appena 8 kB. Ma diventano rispettivamente di 11.3 MB o 3.5 MB inserendo la solita fotografia tramite copia e incolla o drag-and-drop (c’è da notare che in realtà il drag-and-drop non funziona con OpenOffice, che apre automaticamente il modulo Draw di disegno, e che bisogna inserire la foto tramite il menu Inserisci -> Immagine).

Riassumendo: inserendo tramite copia e incolla una immagine di 3.4 MB in un documento di testo si ottiene un file grande da tre volte a quasi dieci volte la dimensione dell’immagine. Il drag-and-drop invece è molto più efficiente e i documenti risultati sono poco più grandi dell’immagine inserita.

La differenza è chiaramente percepibile anche mentre si effettua l’inserimento dell’immagine. Il processo di copia e incolla è lento e pesante, quello di drag-and-drop è praticamente immediato. Anche scorrere lungo un documento contenente tante immagini incollate è molto più faticoso che farlo su un documento in cui le stesse immagini sono state inserite tramite trascinamento.

Non me ne sono mai accorto prima perché sul Mac uso praticamente sempre il drag-and-drop. Ma chi arriva da Windows ha altre abitudini e preferisce il copia e incolla.

Certo che una differenza così eclatante dovrebbe avere una ragione precisa. Ma quale?

Il ritorno dell'offerta

Thu, 05 Jun 2014 06:00:00 +0000

È passato appena un mese e Scrivener è di nuovo in offerta, questa volta su StackSocial e per ben 10 giorni.

Chi se lo fosse fosse fatto sfuggire la prima volta non perda questa occasione. A venti dollari è praticamente un furto.

Senza dimenticare che Scrivener – oltre che essere decisamente più comodo di Word per gestire documenti complessi – consente di iniziare a conoscere LaTeX in modo del tutto indolore.

Cosa si può volere di più? E pensare che non mi pagano nemmeno per fargli pubblicità… :-)