Potest Istallazione Guida Documentazione Forum
Poster per il V convegno annuale dell'AIUCD (Associazione per l'Informatica Umanistica e la Cultura Digitale), 7 settembre 2016
Il campo della scrittura al computer è oggi diviso tra due sistemi principali: i programmi di videoscrittura, di cui i principali sono Word e LibreOffice, e i programmi di composizione tipografica, di cui il principale è LaTeX. Il secondo è lo standard nel campo della matematica, della fisica, dell’ingegneria, e in genere laddove la scrittura della matematica occupa un posto importante; i primi sono di gran lunga più usati in tutti gli altri campi. Spesso i due sistemi vengono contrapposti attribuendo al primo il principio wysiwyg («what you see is what you get»), al secondo invece un criterio di «marcatura semantica». Ciò è evidentemente vero, ma la situazione è più complessa. Vediamo anzitutto i punti di forza. I programmi di videoscrittura consentono di: fruire di un ambiente integrato (dai primi appunti al testo finale stampato si rimane sempre all’interno del medesimo programma); usare un editor ottimizzato per la scrittura di testi in linguaggio naturale; infine, ovviamente, visualizzare il risultato finale mentre si compone il testo. Un programma di composizione tipografica consente di: separare la struttura logica del testo dalla sua presentazione grafica; ottenere un risultato finale stampato molto curato; in particolare avere un’eccellente presentazione delle formule matematiche; salvare i propri testi in un formato leggibile e modificabile con qualsiasi editor.
Purtroppo, ogni merito di ciascuno dei due sistemi si capovolge nel difetto contrario nel sistema che non lo possiede. L’uso di LaTeX è laborioso e difficilmente proponibile a chi non sia disposto a considerare la scrittura di un testo analoga alla composizione di un codice informatico. Dall’altra parte, un programma di videoscrittura consente con molta difficoltà di ottenere un risultato tipograficamente buono, usa per i documenti un formato molto complesso e non modificabile con programmi diversi, e il suo funzionamento wysiwyg rende la scrittura di testi strutturati ripetitiva e distraente: la situazione non è sostanzialmente cambiata da quando un celebre articolo definì i programmi di videoscrittura «stupid and inefficient» (Cottrell 1999). A questa inefficienza bisogna sommare un limite oggi più evidente: ad un testo scritto con un programma di videoscrittura non possono essere associati dall’interno del programma stesso metadati arbitrari. Anche quelli previsti sono del resto così invisibili all’utente normale da essere sistematicamente ignorati. Il meno che si possa dire è che non esiste un sistema di scrittura veramente soddisfacente nel campo umanistico (o comunque laddove non si fa largo uso della matematica e LaTeX non è lo standard: una precisazione questa che facciamo una volta per tutte). È possibile una soluzione diversa?
Per come li abbiamo presentati, i punti di forza dei due sistemi non sono in contraddizione tra di loro. In effetti vi sono almeno due sistemi alternativi che intendono sommare la maggior parte dei vantaggi di entrambi i sistemi: Lyx (creato nel 1995) e TeXmacs (creato nel 1998), entrambi ancora in attivo sviluppo. Sebbene con strategie diverse, entrambi sono basati su LaTeX: Lyx lo usa come back end, TeXmacs ne imita il sistema di composizione. Entrambi tuttavia eliminano quello che pare il principale ostacolo all’uso di LaTeX, cioè la sintassi estremamente invasiva: TeXmacs seguendo integralmente il principio wysiwyg (senza tuttavia rinunciare ad informare della struttura logica soggiacente), Lyx scegliendo una presentazione definita wysiwym, cioè «what you see is what you mean»: in pratica ogni elemento viene mostrato sullo schermo con una formattazione che assomiglia a quella che sarà usata al momento della stampa, mostrandone dunque visivamente il ruolo strutturale.
Il creatore di TeXmacs scriveva nel 2001: «Actually, we conjecture that, within five years, most mathematicians, physicists, computer scientists, etc. will use wysiwyg editors to write their documents» (van der Hoeven 2001): passati ben quindici anni, la previsione del declino di LaTeX si è mostrata completamente sbagliata, malgrado l’eccellente qualità dei due sistemi alternativi. Qui interessa però notare che essi non hanno significativamente ridotto neppure l’uso dei programmi di videoscrittura, cosa che in teoria era possibile e che Lyx intendeva esplicitamente fare. In effetti essi, essendo basati (realmente o idealmente) su LaTeX, ne ereditano alcuni problemi fondamentali: la necessità di pensare alla scrittura come alla creazione di «codice» (i manuali di Lyx superano le 300 pagine, quello di TeXmacs le 250 pagine), la difficoltà nel definire nuovi formati e nell’isolarli come entità a sé stanti. Lyx, usando LaTeX come motore di composizione, porta con sé inoltre anche la fragilità di quest’ultimo: è noto come LaTeX permette sì di ottenere «qualsiasi cosa» usando gli innumerevoli pacchetti predefiniti, ma purché si abbia la pazienza di entrare negli intricati problemi di incompatibilità tra i diversi pacchetti. Perfino usare un font diverso da quelli standard è in LaTeX un problema di incerta soluzione. Benché criticabile nella metodologia, un recente studio (Knauff e Nejasmic 2014) ha attirato l’attenzione su queste e simili «inefficienze» proprie di LaTeX. Sia Lyx sia TeXmacs, inoltre, condividono con LaTeX l’orientamento prevalente alla stampa su carta. Questo problema appare oggi particolarmente significativo anche per i programmi di videoscrittura: la maggior parte dei testi oggi non viene prodotto per essere stampato su carta, o perlomeno non esclusivamente, ma piuttosto per altri formati elettronici e soprattutto per la rete. Dividere il testo e la sua struttura logica dal formato non appare dunque più una pignoleria teorica, ma una necessità pratica.
Se il limitato insuccesso di questi due sistemi può sembrare decretare il fallimento di un’adozione generalizzata del principio della marcatura semantica, altri due fatti nuovi avvenuti alla metà degli anni 90 hanno posto le basi per nuovi sviluppi. Nel 1996 viene inventato il linguaggio CSS (Cascading Style Sheet) e nel 1998 l’HTML viene ridefinito come linguaggio di marcatura esclusivamente semantico; nel 1995 l’invenzione dello «wiki», che seguendo il principio «do the simplest thing that could possibly work» usa non l’HTML, ma piuttosto un «linguaggio leggero di marcatura», in cui la struttura logica del documento viene indicata non da etichette inframmezzate al testo, ma piuttosto da segni convenzionali (costituiti da uno o pochissimi caratteri, sempre scelti nel dominio ASCII). Benché apparentemente contraddittorie, queste due innovazioni hanno significato due cose: che il mezzo di pubblicazione oggi principale (cioè la rete) ha adottato implicitamente il principio della marcatura semantica; che decine di migliaia di utenti lo usano correntemente senza alcun problema (smentendo dunque l’idea che un sistema wysiwyg sia di per sé più facile da usare). Bisogna anzi dire che i linguaggi leggeri di marcatura hanno rivitalizzato lo spirito dell’HTML, all’origine pensato come un facilissimo linguaggio alla portata di tutti, ma poi sempre più allontanatosi da questo principio (le attuali specifiche occupano uno spazio più di 700 volte maggiore di quelle originarie di Tim Berners-Lee).
Il passo successivo evidentemente doveva essere applicare in questo modo il principio della marcatura semantica alla scrittura orientata alla stampa. A partire dagli stessi anni in effetti sono stati ideati linguaggi di marcatura leggeri con questo scopo: tra gli altri txt2tags, AsciiDoc, reStructuredText. Il caso di Markdown, ideato nel 2004, è un po’ diverso: questo linguaggio viene ideato come una maniera semplificata di scrivere le parti più comuni dell’HTML (gli elementi Markdown sono mappati direttamente su marcatori HTML e nelle specifiche è compreso il fatto che esso può essere alternato liberamente con l’HTML stesso nei casi più complessi: per esempio per le tabelle); poi a causa dei suoi meriti di semplicità è stato progressivamente esteso (peraltro senza il consenso del primo ideatore). Il punto di arrivo può essere considerato Pandoc: un traduttore «universale», che usa come linguaggio principale Markdown e ne permette la traduzione in molti altri linguaggi, tra cui LaTeX e HTML; inoltre Pandoc arricchisce Markdown fino a renderlo un linguaggio di marcatura sufficiente a tutti gli usi comuni di scrittura (incorporando anche un raffinato strumento di gestione delle bibliografie, analogo a BibTeX).
È dunque comprensibile che recentemente la combinazione Pandoc + LaTeX sia stata proposta come il nuovo sistema di scrittura accademico. In questo modo infatti vengono conservati tutti i meriti di LaTeX aggiungendo tuttavia il vantaggio di una scrittura molto più semplice, dovuta appunto al carattere «leggero» della marcatura. Scrivere *corsivo* è indubbiamente più facile e meno distraente che scrivere \emph{corsivo}. Inoltre, Pandoc supera il limite di una scrittura prevalentemente orientata alla stampa su carta, avendo tra i suoi formati di uscita, per esempio, HTML, ePub e DocBook. Ciononostante, neppure queste proposte sembrano aver avuto il successo sperato: per esempio l’ambizioso progetto ScholarlyMarkdown, lanciato con lo slogan «Let’s keep the dream of academic writing using Markdown alive» (Lin 2015), sembra essere stato abbandonato dopo pochi mesi.
Le cause di questo insuccesso paiono almeno di due ordini. Anzitutto, come nel caso di Lyx e di TeXmacs, vengono ereditati diversi dei problemi di LaTeX. È vero che con un linguaggio leggero di marcatura la composizione di un testo non viene più percepita come la scrittura di codice (anche se tecnicamente continua ad esserlo, ovviamente). Ma questo non è, come abbiamo visto, l’unico problema di LaTeX: rimangono la complessità del sistema e le difficoltà legate alle definizioni dei formati. Inoltre, proporre semplicemente Pandoc + LaTeX come sistema di scrittura omette di riconoscere quelli che abbiamo citato come i due primi vantaggi di un sistema di videoscrittura: il fatto che in esso si usufruisca di un ambiente integrato, al cui interno vi è un editor ottimizzato per il linguaggio naturale. In altre parole: «usate il vostro editor preferito per scrivere il testo Markdown» e «dopo aver scritto il testo, date il seguente comando da terminale» sono le istruzioni che condannano all’insuccesso un sistema di scrittura: esse infatti escludono dai possibili nuovi utenti tutti coloro che usano un programma di videoscrittura e che (lecitamente) non hanno un editor preferito e non sanno che cos’è un terminale. In ogni caso, quasi tutti gli editor di testo sono progettati avendo in mente le esigenze della scrittura di codice, e non di linguaggio naturale.
Che i tentativi finora proposti per superare l’antinomia tra programmi di videoscrittura e programmi di composizione tipografica non siano riusciti non è dunque un caso o un destino. Ciò deriva invece dall’aver sottovalutato elementari aspetti di usabilità. Potest (Salmeri 2016) rappresenta il tentativo di trarre le giuste lezioni dai tentativi passati e di giungere ad una soluzione che sia in grado di rispondere, meglio di qualsiasi altro sistema attualmente esistente, alle esigenze della scrittura di testi strutturati (articoli, tesi, libri) in materie umanistiche. Il punto di partenza è costituito dall’uso di Pandoc come motore di conversione e di Markdown come linguaggio leggero di marcatura. I motivi sopra esposti mantengono infatti la loro validità. Malgrado i suoi difetti (ne diremo qualcosa dopo) Markdown è un linguaggio buono e di uso molto semplice; Pandoc è finora insuperato non solo nella sua capacità di convertire tra formati differenti (e dunque di superare i tradizionali limiti di sistemi orientati alla stampa su carta), ma anche nella sua estensibilità in direzione di nuovi formati. Come evitare però i problemi sopra notati?
I problemi legati a LaTeX si possono superare in un solo modo: abbandonando LaTeX come motore di composizione per la stampa su carta. Per un certo periodo è stata valutata la possibilità di usare come motore di composizione ConTeXt, un sistema analogo a LaTeX, anch’esso basato su TeX ma di concezione molto più moderna, che evita una buona parte dei problemi prima notati. Alla fine la scelta è però caduta su una via completamente diversa: HTML+CSS come formato principale di uscita, cioè due linguaggi bene definiti e di concezione moderna. Fino a poco tempo fa questa scelta per la stampa su carta sarebbe stata impossibile o temeraria. Da quando però con la versione 3 del linguaggio CSS e soprattutto con lo sviluppo del motore di composizione Prince (già PrinceXML) si ha la possibilità di una conversione di eccellente livello di un sorgente HTML in un file PDF impaginato, la scelta appare logica. Il fatto che Prince incorpori al suo interno alcuni algoritmi fondamentali di LaTeX fa sì che il risultato possa essere considerato praticamente indistinguibile dal punto di vista della qualità tipografica. Scegliere CSS come linguaggio di descrizione della pagina significa inoltre avere la strada spianata verso una facile definizione di nuovi formati. Il fatto che il file HTML+CSS sia generato da Pandoc permette inoltre una flessibilità senza limiti: Pandoc permette infatti la scrittura di back end in Lua, nei quali può essere incorporata qualsiasi logica (è per esempio banale riordinare in qualsiasi modo i metadati di un testo, o far in modo che a partire da essi ne vengano calcolati altri). Finora sono stati elaborati principalmente due formati per la composizione di tesi di laurea del corso di laurea in Filosofia di Tor Vergata, ma è facile definirne altri, o anche realizzare un sistema con il quale pure l’utente finale possa definire facilmente un proprio formato personalizzato. I file di supporto di Prince sono stati inoltre modificati in maniera da permettere, contemporaneamente a qualsiasi altra lingua, la corretta spezzatura in fin di riga del greco classico e, insieme con l’italiano, anche del latino: una facilitazione che per quanto ci risulta non è finora prevista in nessun altro sistema.
Per creare invece un ambiente di lavoro è necessario considerare un editor come parte integrante del sistema di scrittura. Dopo averne preso in esame molti, si è trovata la soluzione ideale in Textadept, un editor «minimalista» basato su Scintilla, disponibile per tutti i maggiori sistemi operativi. Il minimalismo di Textadept ha risolto fin dall’inizio due problemi degli attuali programmi di videoscrittura: la lentezza e lo sviluppo di interfacce sempre più complesse e sovraccariche (che sottraggono spazio spesso prezioso nello schermo): Potest si presenta così con un editor dall’interfaccia semplicissima ed estremamente veloce. Ma soprattutto il fatto che Textadept sia scritto quasi interamente in Lua significa che in esso non c’è limite alla personalizzazione: intere parti possono essere in maniera relativamente facile modificate, tolte, aggiunte o sostituite. È così che un editor destinato principalmente alla scrittura di codice si è potuto trasformare in un editor ottimizzato per la scrittura di testi in linguaggio naturale. Sarebbe troppo lungo descrivere tutte le modifiche che sono state fatte, ma i più importanti esempi saranno sufficienti. Alcune modifiche o aggiunte sono state fatte per rendere l’uso dell’editor più facile per l’utente: per esempio un modo veloce per modificare le preferenze di scrittura, dialoghi più chiari per evitare che venga chiusa accidentalmente una scheda non registrata, un sistema semplificato di «viste» che permette di lavorare contemporaneamente su due parti dello stesso documento o di confrontare automaticamente due versioni dello stesso.
Altre funzioni invece sono state aggiunte per facilitare l’inserimento di caratteri utili soprattutto per l’uso umanistico: per esempio un sistema estremamente efficiente per scrivere in greco, cirillico o IPA, oppure combinazioni di tasti che inseriscono lo «spazio non separabile» e il «trattino opzionale», oppure una raffinata funzione che inserisce le virgolette tipograficamente corrette secondo il livello e la lingua prescelta (distinguendo tra tredici diverse consuetudini nazionali). Altre funzioni ancora sono destinate esplicitamente alla manipolazione di testi Markdown: per esempio il comando per inserire i metadati, o per trasformare le note da «interne» ad «esterne» e viceversa (una funzione questa che rende la scrittura ed elaborazione delle note più semplice e flessibile che in un programma di videoscrittura). In quest’ultima categoria bisogna porre anche i comandi di importazione e soprattutto esportazione: il primo permette di trasformare in formato Markdown un testo LaTeX o Word; il secondo di trasformarlo in uno dei formati previsti: PDF per la stampa (via Prince), oppure HTML per la pubblicazione in rete, docx per i casi in cui esso è richiesto, oppure in futuro altri ancora (DocBook, TEI ecc.). In questo modo l’utente si troverà sempre all’interno del medesimo ambiente di lavoro, senza dover sapere nulla del fatto che dietro le quinte il sistema Potest è costituito dalla collaborazione di tre programmi principali (una versione molto modificata di Textadept, Pandoc, Prince) e altri secondari.
Il sistema Potest ha inoltre affrontato un problema che in prospettiva si pone riguardo all’uso di Markdown: il fatto che esso è un linguaggio di marcatura mal definito. Esso manca di una grammatica formale e numerosi casi limite restano di significato ambiguo. Inoltre, una stessa marcatura semantica può spesso essere indicata in più modi, il che aumenta senza motivo la complessità del linguaggio. Nel settembre del 2014, sotto la guida dell’autore di Pandoc, è iniziato un tentativo di definizione rigorosa, dapprima chiamato Standard Markdown, poi (a causa della contrarietà dell’originario creatore di Markdown) rinominato Commonmark. Il prezzo da pagare è stato però una prolissità che stride con la dichiarata semplicità del linguaggio: all’inizio del sito dedicato a tale tentativo una pagina promette «Learn Markdown in 60 seconds» (MacFarlane et al. 2014), ma all’interno le specifiche complete occupano un centinaio di pagine a stampa. La strada seguita da Potest è diversa: nel manuale d’uso viene indicata di ciascun costrutto solo una forma non ambigua; quando sono possibili diversi costrutti sinonimi, ne viene indicato solo uno (salvo precisi motivi contrari, come nel caso delle note a piè di pagina); infine, diversi costrutti che sarebbero di uso rarissimo (e che di fatto non si trovano mai in testi reali) sono stati esclusi. In questo modo il problema delle scritture ambigue è stato risolto facendo ricorso al concetto di «indeterminato», che del resto non è nuovo per esempio nei linguaggi di programmazione. In questo modo la definizione di Markdown è diventata sufficientemente rigorosa senza aumentare la complessità, anzi diminuendola.
Passando in rassegna gli elementi di forza, elencati all’inizio, dei sistemi di videoscrittura e di composizione tipografica, Potest li riassume in effetti tutti, con due sole eccezioni. La prima, temporanea, è relativa alle formule matematiche: non usando come motore di composizione LaTeX, Potest non può usufruire del sistema di scrittura matematica lì integrato; ma in una prossima versione sarà incluso il sistema AsciiMath, che è sufficiente per gli usi non troppo complessi della matematica (per esempio in statistica). La seconda eccezione è il fatto che esso non è un sistema wysiwyg. Per essere più esatti, si potrebbe dire che esso è wysiwyg solo nei limiti in cui ciò è utile per la scrittura di testi strutturati. Anzitutto, usando un linguaggio di marcatura leggero, con Potest si scrive senza inframmezzare il testo con una sintassi invasiva; in secondo luogo, il linguaggio scelto, Markdown, si distingue dai consimili perché concepito in vista della maggiore leggibilità possibile: «the idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions» (Gruber 2002); in terzo luogo, l’editor di Potest usa un’evidenziazione sintattica (modificata rispetto a quella standard di Textadept) che distingue immediatamente i costrutti riconosciuti. Che il testo venga invece mostrato sullo schermo esattamente come sarà stampato in generale non solo non è utile (non aiuta in nessun modo la scrittura), ma è distraente e spesso scomodo: distraente perché attira l’attenzione sugli aspetti estetici deviandola dal contenuto, scomodo perché impedisce di scegliere caratteri, dimensioni e colori che sono più appropriati per la lettura sullo schermo.
È in grado dunque il sistema Potest di rispondere alle necessità per le quali è stato pensato? La risposta è finora positiva. Per la scrittura di testi strutturati in materie umanistiche, Potest è fin da oggi un sistema di scrittura migliore di quelli esistenti. Intendiamo per «migliore» il fatto che offre risultati di qualità tipograficamente eccellente (migliore rispetto ai programmi di videoscrittura) e in tempi molto più rapidi. Ma anche ammesso che sia usato solo per generare alla fine un file .docx (per i casi in cui viene esplicitamente richiesto questo formato), l’editor di Potest è più veloce, comodo e ricco di un programma di videoscrittura, sia per le caratteristiche di Textadept, sia per le funzioni aggiuntive di cui è stato dotato. Nel tempo più rapido consideriamo anche il periodo di apprendimento: con l’editor di Potest si può cominciare a scrivere immediatamente (tutti i principali comandi di modifica sono stati intenzionalmente resi identici a quelli dei programmi di videoscrittura) e apprendere la marcatura Markdown non richiede più di qualche minuto. La guida completa di Potest occupa solo una quarantina di pagine, che includono però molti consigli di scrittura generici. All'inizio un paragrafo «Potest in un minuto», sufficiente per scrivere la maggior parte dei testi, è costituito da appena una pagina. Notiamo infine che il sistema Potest è anche multipiattaforma: i programmi su cui si basa sono disponibili per Linux, OSX e Windows e tutto il codice aggiunto tiene conto delle rispettive differenze. Il piccolo investimento di apprendimento è quindi ben ripagato anche per questo motivo.
Oltre a soddisfare meglio le esigenze del singolo, Potest risponde molto meglio anche a quelle della comunità scientifica. I testi composti in questo modo possono infatti non solo essere immediatamente trasformati in qualsiasi formato strutturato di uscita (dunque per basi di dati, depositi istituzionali e così via), ma sono anche pronti per accettare tutti i metadati necessari per un’archiviazione e condivisione efficiente. Il dialetto Pandoc di Markdown permette infatti di includere dati in formato YAML, e in Potest essi sono automaticamente inseribili nel documento e anzi necessari per il suo completamento: qualsiasi utente non avrà dunque nessuna difficoltà ad inserire quelli necessari, perché fin dall’inizio è abituato ad usarli per le informazioni essenziali (autore, titolo, ecc.) del documento che sta scrivendo.
Miglioramenti del sistema Potest sono attualmente allo studio e saranno realizzati nelle prossime versioni. Alcuni riguardano l’editor: un sistema di cronologia del salvataggio che impedisca la perdita accidentale di documenti sovrascritti, la possibilità di inserire facilmente caratteri in altri alfabeti oltre a quelli già previsti (devanagari, arabo, ebraico). Altre estensioni sono invece previste per il linguaggio Markdown: un meccanismo di transclusione, la possibilità di codificare facilmente grafici, l’uso del linguaggio AsciiMath (prima citato) per inserire formule matematiche, l’inserimento di audio e video per i formati di uscita in cui ciò ha senso. Infine, oltre all’arricchimento dei formati di uscita, come prima accennato, è quasi ultimata la definizione di un formato di uscita per realizzare diapositive per presentazioni, in modo che il sistema Potest possa anche completamente sostituire (e da molti punti di vista migliorare) programmi come PowerPoint o Impress. Citiamo inoltre un’estensione che è stata già realizzata a scopo dimostrativo: la possibilità di crittografare i documenti proteggendoli con una parola d’ordine. Si tratta evidentemente di una funzione marginale per coloro che sono pensati come i primi destinatari di Potest, ma che talvolta viene giudicata necessaria per l’uso aziendale. Ora, la natura modulare del sistema e le scelte di architettura prima notate hanno permesso una soluzione facilissima e, grazie all’uso di software libero, all’avanguardia nella protezione dei dati (è stato usato il sistema AES, utilizzato come standard dal governo degli Stati Uniti).
Osserviamo che ogni nuova funzione è pensata accuratamente in modo da non confliggere con l’estrema facilità d’uso del sistema e introdotta solo dopo sufficiente sperimentazione. È questo il motivo per il quale ancora non è presente la gestione automatica dei riferimenti bibliografici: essa è già fornita di per sé da Pandoc, ma si è scelto di non inserirla finché non si sarà valutato quale sia la forma di uso più facile e con un risultato più adatto all’uso umanistico, anche a costo di doverla riprogrammare da zero. Allo stesso modo non è ancora stato previsto un modo preferenziale per la pubblicazione in rete: Markdown è un linguaggio nato esattamente con questo scopo e attualmente è usato da diversi sistemi di gestione dei contenuti (content management systems): la strada migliore potrebbe quindi essere l’integrazione con uno di essi anziché la trasformazione in HTML.
Contro l’adozione di Potest possono essere avanzate alcune obiezioni di principio. Ad alcune abbiamo già implicitamente risposto, altre meritano invece qualche parola in più. Una prima semplice obiezione è che tutti imparano ad usare un programma di videoscrittura, e nessuno fa l’investimento di imparare un nuovo sistema se non vi è costretto. In una certa misura questo è vero, ma nel caso in questione bisogna tenere presente che la conoscenza media di un programma di videoscrittura è molto limitata e «average users of such systems sometimes employ rather abominable means for the formatting of their texts» (Kastrup 2002). In ogni caso questa limitata conoscenza non va perduta in Potest, perché le operazioni di base (inserimento del testo, semplice gestione dei file, ricerca e sostituzione ecc.) sono identiche o simili a quelle di un programma di scrittura. Quando ci si accinge a scrivere un testo più impegnativo (tipicamente, per molti studenti, si tratta della tesi di laurea) in ogni caso bisogna dunque imparare nuove cose. Tutte queste nuove cose sono più semplici in Potest. Non è dunque piccola l’attrattiva di un sistema che consente di impiegare solo qualche secondo e un unico comando per impaginare perfettamente la propria tesi, senza dover consultare linee guida di nessun tipo.
Una seconda obiezione è di tipo strategico: in ogni caso, si può sostenere, conviene che anche nel campo umanistico venga appreso l’uso di LaTeX, sia perché esso è già uno standard, sia perché in questo modo si ha l’opportunità di familiarizzare con una forma di codice (quello, appunto, usato da LaTeX). A ciò bisogna rispondere che imparare l’uso di LaTeX è sì una buona soluzione e un investimento valido, perlomeno dal punto di vista della sfida intellettuale. Dall’altra parte non si può però dimenticare che LaTeX è un sistema per molti motivi irrimediabilmente difettoso (il fatto che dopo 25 anni di lavoro la versione 3 non sia stata ancora rilasciata non è un caso): chi lavora nel campo umanistico non ha molto interesse ad imparare un sistema solo perché esso è lo standard in altri campi (che non sono i suoi) e perché esso consente di comporre in maniera eccellente la matematica (che non usa). Infine, il problema della divisione tra cultura scientifica e umanistica è serio, ma può essere affrontato in molti altri modi che non sono l’apprendimento di LaTeX. Per esempio, si potrebbe ritenere che studiare un vero moderno linguaggio di programmazione sia un investimento ancora migliore, che non sovraccarica l’attività di scrittura con difficoltà ad essa estranee.
Si potrebbe infine obiettare che l’uso di un programma di videoscrittura costituisce un’economia mentale perché con esso si possono creare anche documenti graficamente elaborati (riviste illustrate, volantini e simili), che Potest invece (come LaTeX, peraltro) non permette. Questo è indubbiamente vero, salvo che un programma di videoscrittura, come non è lo strumento migliore per testi strutturati, così non lo è neppure per questi. A tale scopo esistono invece i programmi di editoria digitale (desktop publishing), in cui ovviamente una presentazione realmente wysiwyg è indispensabile: per esempio l’eccellente Scribus, un programma libero disponibile per tutte le piattaforme, o il servizio in linea LucidPress. Si può quindi ritenere che Potest, disincentivando l’uso dei programmi di videoscrittura, incoraggia a ricorrere anche per gli usi residui agli strumenti più adatti.
Dal punto di vista tecnico, Potest è costituito attualmente da circa 4000 righe di codice che personalizzano i programmi prima citati e costruiscono un’unica «esperienza dell’utente». Questo codice è rilasciato sotto la licenza MIT, una delle licenze più permissive: sostanzialmente, permette a chiunque di riusare e modificare il codice solo riconoscendone la paternità originaria. La scelta di questa licenza è stata dovuta sostanzialmente a ragioni ideali, che non è il caso di esporre qui perché coincidono con quelle del vasto movimento del software libero. A tali ragioni ideali si aggiunge anche una certa affinità tra software libero e accesso aperto nelle pubblicazioni scientifiche. Come è giusto che i risultati della ricerca siano in linea generale disponibili gratuitamente a tutti, così sembra opportuno che uno strumento per metterli in bella forma e aiutarne la condivisione pubblica sia libero e gratuito. Anche i programmi su cui è basato Potest sono stati scelti avendo in mente questo principio: Textadept è rilasciato anch’esso con una licenza MIT, Pandoc e altri programmi minori con una licenza GPL. L’unica eccezione è costituita da Prince, che non è software libero ed è rilasciato con una licenza proprietaria. Questa eccezione è attenuata da due motivi: il primo è che Prince è disponibile con una licenza gratuita per uso personale e non commerciale (per esempio, uno studente può usarlo per comporre la sua tesi) e una licenza molto economica per uso accademico (per produrre per esempio le pubblicazioni edite dall’Università); il secondo è che, seppure il programma è proprietario, sono liberi i linguaggi su cui è basato, cioè HTML e CSS. La diffusione di questi ultimi rende inoltre verosimile che in futuro esisteranno diversi programmi in grado di produrre risultati esteticamente paragonabili. Il fatto che solo Prince abbia una licenza proprietaria permette tuttavia l’uso illimitato di Potest dovunque non sia coinvolta la generazione di un PDF (o dove la sua produzione sia affidata a back end diversi da Prince).
Come è noto, la scelta di una licenza libera non esclude un programma da un uso commerciale, né da parte di chi lo ha creato, né da parte di qualsiasi utente: non è qui il caso di entrare in precisazioni e problemi che sono ben noti nel mondo del software libero. Osserviamo solo che la natura stessa di Potest richiederà o almeno incoraggerà attività collaterali che possono costituire occasione di lavoro e di investimento: per esempio minicorsi di formazione, elaborazione di nuovi formati di uscita, codifica sponsorizzata di funzioni aggiuntive, collaborazione ad infrastrutture per l’open access. In questo modo Potest potrà portare anche il suo piccolo contributo ad un modello in cui la condivisione libera non è in contraddizione con l’iniziativa economica.
Il sistema Potest promette una soluzione diversa e migliore al problema della scrittura di testi umanistici strutturati. I primi esperimenti che sono stati fatti sembrano confermarlo. Coloro che finora lo hanno provato, provenendo tutti da una lunga abitudine con i programmi di videoscrittura, lo hanno definito più facile da usare, più veloce, più adatto. Diversi hanno notato che la composizione di testi diventa più «piacevole» e che in essa si è meno distratti. Probabilmente il suo primo e principale campo di diffusione è costituito dagli studenti universitari: sono loro che con le tesine e le tesi di laurea devono sicuramente affrontare i problemi della scrittura di un testo ampio, e sono loro che più facilmente possono usare Potest una volta che i formati di impaginazione per le tesi siano stati definiti. In effetti Potest è nato nell’ambito delle attività del corso di laurea in Filosofia dell’Università di Roma Tor Vergata e in esso si sta conducendo la prima sperimentazione. La speranza è che, se l’esperimento andrà a buon fine, l’Ateneo possa proporlo a tutti gli studenti per i quali LaTeX non è lo standard e che questo possa essere l’inizio, se non di un cambiamento generalizzato delle abitudini di scrittura, almeno dell’apertura di una possibilità diversa e meglio collegata con le attuali opportunità ed esigenze della produzione e condivisione di cultura.
L’ampiezza del codice finora scritto certamente è considerevole, ma è pur sempre molto inferiore a quella necessaria per un qualsiasi completo programma di videoscrittura. Ciò dimostra almeno due cose. La prima è l’attualità della cosiddetta «filosofia di Unix» e il valore della libertà del software: Potest mette a frutto diversi programmi preesistenti, quasi tutti liberi, ognuno dei quali fa bene un’unica cosa; sono poi le esigenze di usabilità che hanno motivato la creazione di un’interfaccia unica che nasconde la complessità soggiacente. La seconda è il valore di un approccio umanistico all’informatica, non solo dal punto di vista dell’uso, ma anche della creazione. Il codice è relativamente poco, ma esso è il punto di arrivo di una ricerca durata almeno cinque anni, mossa essenzialmente da un’attenta riflessione sul carattere umano degli strumenti tecnici e sulle esigenze della scrittura accademica.
Un ringraziamento a Lorenzo Perilli che ha fatto utili osservazioni su una versione provvisoria di questo testo, a Maria Grazia Pievatolo e Claudio Franchini che con le loro obiezioni mi hanno spinto ad aggiungere alcune precisazioni. Questo testo ovviamente non avrebbe potuto essere scritto senza Potest e coloro che hanno aiutato nel suo sviluppo: Emanuela Tangari, che ha dato innumerevoli consigli sull’interfaccia utente; Martine Gilsoul, Francesco Aronadio, Virgilio Costa e gli studenti del corso di laurea in Filosofia che per primi hanno aiutato con commenti e segnalazioni di errori.
Quest'opera è distribuita con Licenza Creative Commons Attribuzione · Non commerciale · Non opere derivate 4.0 Internazionale
· Copyright 2016 Filosofia TorVergata · Gestore del sito Giovanni Salmeri potest@mondodomani.org