[Pluto-devel] ci sono

[Umberto Salsi]

Io stesso scrissi:

>
> Dunque, riassumiamo: si stava parlando di scrivere gli articoli in ASCII,
> quindi tutti d'accordo, salvo alcuni esagitati che pretendevano di scriverli
> in HTML, ed altri 
>

(acc... mannagg.... ho inviato anche il messaggio che stavo scrivendo -
ecco il pezzo mancante, ovvero il 99% del tutto:)

...ed altri sconsiderati che vorrebbero adottare un formato XML, XPJ,
PJX, o che so io. Poiche' e' evidente che l'ASCII ha potenzialita'
espressive ben superiori a qualsiasi formato passato, presente e futuro,
vorrei considerare anche le proposte alternative che, sebbene ampiamente
minoritarie, meritano comunque una considerazione. Ricordo infatti che
XML, DTD e compagnia sono nient'altro che testi.

A mio modesto parere, inventare un formato di scrittura strutturato
e' molto difficile, ci provano in tanti da parecchio tempo e con
risultati alterni. Inventare poi un formato in grado di soddisfare
contemporaneamente le esigenze dei tecnici informatici, dei matematici,
dei romanzieri, dei grafici, ecc. e' ancora piu' difficile, per cui
realizzare un prodotto di uso generale e' un progetto marziano.

E' vero che l'XML e compagnia fornisce uno strumento standardizzato
per descrivere la struttura di un documento, ma come al solito bisogna
mediare tra il rischio di chiudersi in vincoli troppo stretti (tipo:
titolo, autore, testo, bibliografia, e chiuso) e quello di scadere nella
anarchia dei formati (tipo l'HTML). Tra questi due estremi preferisco il
secondo, eventualmente corredato da raccomandazioni di stile adeguate.
C'e' anche il rischio noto come "sindrome da reinvenzione della ruota":
ne accennero' nel seguito.

Evitiamo di disperdere energie partendo con la codifica di un software,
quando non sono chiare le specifiche del progetto, quando non sappiamo
bene quali sono gli obiettivi da raggiungere.

Provo a focalizzare alcuni di questi obiettivi:

- Le riviste tecniche (a livello di pubblicazioni universitarie) usano
formati specifici ritagliati per le loro esigenze: un pezzo di matematica
pieno di formule ha esigenze di composizione tipografica molto diverse
da un articolo di design.  Ecco perche' stiamo cercando la nostra via per
le pubblicazioni di roba di computer come e' il PJ. Sperare di inventare
qualcosa che non ci sia gia', o che sia piu' generale dell'XML o piu'
specialistico del LaTeX mi sembra al momento fuori luogo (manca l'idea
chiave, insomma).  Vediamo cosa c'e' gia' in giro.

- Le riviste cartacee nelle edicole che parlano di informatica fanno,
tipograficamente parlando, cag^H^H^Hschifo: formattazione a colonne
strettissime, sorgenti dei programmi stampati con indentazione a casaccio
o con font improbabili dentro a box dai colori allucinanti o, peggio
ancora, testo dell'articolo su carta e sorgenti ed esempi su CD, generale
scarsa cura agli aspetti tipografici piu' fini.

- XML e compagnia: la parola di per se' significa tutto e niente. Su
cosa vogliamo puntare? 1) sulla struttura globale del documento (box
introduttivo e dell'autore, corpo del testo ed altri aspetti globali); 2)
e/o vogliamo inoltrarci anche nei dettagli degli aspetti tipografici piu'
fini (spaziature, interlinee, paragrafi, liste puntate, liste numerate,
liste di definizione, grassetti, corsivi, font proporzionali, ecc. e
combinazioni varie, ... ehi! ma questo c'e' gia', e' l'HTML!).

- SGML: non lo conosco, ma pare che sia il massimo. Bho, non mi pronuncio.
Mi pare che Giacomini usi questo, da cui poi ricava gli altri formati
della sua immmmmensa opera.

- HTML: ampiamente portabile e standardizzato, contiene un mix di aspetti
strutturali e di aspetti di formattazione che soddisfano decorosamente
la maggior parte delle esigenze. Difetti: e' difficile assicurare
che gli autori rispettino le raccomandazioni dettate dalla redazione della
rivista; la conversione verso altri formati (PS, PDF, ...?...) non e' sempre
soddisfacente.



Allora ecco la mia proposta di discussione:


1) Come vogliamo che appaiano i nostri documenti: l'aspetto attuale
va bene?  se no, come dovrebbe essere? Quali e quanti formati vogliamo
generare?  HTML, PS, PDF, ...?...


2) Poi si passa a discutere il come raggiungere questo obiettivo. E'
ovvio che bisognera' definire un formato originario, la madre di tutti i
formati, dalla quale ricavare gli altri. Questo formato deve in qualche
modo rissumere le caratteristiche comuni degli altri, altrimenti e'
inevitabile che le conversioni portino a perdita di informazioni in modo
difficilmente prevedibile (sorgenti indentati a casaccio, link misteriosi,
tabelle disarticolate, ecc.).


3) Infine la realizzazione pratica della "cosa" (programma? filtro?
editor grafico? validatore? bho!).




Ed ecco anche la mia proposta di realizzazione rispetto ai punti precedenti:


1) L'aspetto attuale dei documenti (mi riferisco naturalmente a quelli
con contenuti tecnici intricati da sorgenti, figure, tabelle, ecc.) mi
pare buono e, anzi, infinitamente superiore per qualita' tipografica a
qualsiasi rivista cartacea.


2) Il "linguaggio espressivo" di questi articoli e' l'HTML. E' piuttosto
semplice e ha possibilita' espressive (in senso tipografico) di buon
livello, comunque senzaltro sufficienti per le nostre necessita'. Se
sia bene scrivere direttamente in HTML, oppure non sia meglio partire
da un formato piu' astratto, credo vada ancora discusso. Io voto per
un HTML opportunamente emendato e con le raccomandazioni della redazione
riguardo allo stile da seguire, una specie di HTML PJ compliant.
Questo HTML PJ compliant ha due obiettivi principali: curare la
resa formale della rivista; consentire l'estrazione delle informazioni
chiave per una facile reimpaginazione in PS o altro.


3) Secondo me non possiamo sperare, ragionevolmente, di pervenire a una
unica soluzione per la redazione, adatta a tutti i tipi di articolo e
a tutti i tipi di autore. Ci sara' chi scrive direttamente in HTML, chi
si avvale di editor specifici, chi usera' un programma scritto all'uopo
per redigere gli articoli del PJ e che poi sputa fuori automaticamente
l'HTML come lo vogliamo noi, chi passera' attraverso l'XML o chiassa'
quante altre soluzioni. L'importante e' che tutto converga verso un unico
formato.

Una volta generato l'HTML PJ-compliant, un apposito parser validera'
automaticamente l'aderenza o meno di questo HTML rispetto alle
linee guida fissate.  Il parser potra' essere passivo (dice cosa
non va e perche') o attivo (oltre al parsing, esegue anche eventuali
correzioni di conformita', nei limiti in cui puo' farlo). L'autore ha
cosi' modo di sapere subito se il suo articolo e' HTML-PJ compliant,
e contemporaneamente puo' subito assicurarsi del suo aspetto finale
da browser (quando i tipografi mi sistemano a casaccio spaziature,
punteggiature, allineamenti mi pregiudicano anche la comprensibilita',
e questo e' fondamentale nei testi informatici - chiunque abbia provato
a imparare robe di programmazione su testi pieni di errori di questo
tipo sa a cosa mi riferisco, altro motivo per cui i testi in lingua
originale sono sempre meglio di quelli tradotti).

Una volta che l'articolo ha superato il test di HTML-PJ conformita',
alla redazione non rimane alcun lavoro da fare se non controllare i
contenuti, che poi sono il vero obiettivo di tutto 'sto can can.



Conclusione

Ma... il numero di gennaio e' chiuso o no?
Coloro che replicheranno a questo messaggio quotando l'intero contenuto
e' squalificato.


Ciao,

// Umberto Salsi
//
// http://digilander.iol.it/salsi <-- GnuPG key available here!
// Key fingerprint = B957 FB00 10F5 A770 4A26  2D80 BE2C F6CD 77E9 29AE