[Pluto-devel] ci sono

[Marco Marongiu]

Ciao a tutti, e ciao Umberto!

Non avendo trovato il tempo in ufficio mi sono dovuto portare il 
Pluto-lavoro a casa. E, come da copione, non ho scaricato una parte dei 
messaggi che mi servivano[1]. Accontentatevi delle risposte a quelli che 
ho scaricato, che nessuno è perfetto :-)

> A mio modesto parere, inventare un formato di scrittura strutturato
> e' molto difficile,


...e io sono perfettamente d'accordo con te. Infatti ripensando ad un 
progetto da pubblicare ed, eventualmente, commercializzare, mi sono 
venute in mente due cose. Una l'ho già scritta non troppe ore fa, ed è 
che i tag dovremo formularli in inglese e non in italiano. L'altra, che 
mi è sovvenuta in background mentre pensavo a tutt'altra cosa, è che per 
una parte del formato dovremmo rifarci al lavoro fatto da altri in 
maniera molto più decente di quanto potremmo fare noi: mi riferisco al 
"Dublin Core".

Fra le cose che dovrebbero entrare a far parte di XPJ ci sono anche i 
cosiddetti metadati, le informazioni sulla stessa informazione contenuta 
sull'articolo. Partire dal DC ci può aiutare in due direzioni:

* vedere da subito quali sono i possibili metadati e quali possono 
essere pertinenti a un articolo del PJ;
* gli articoli del PJ conterrebbero da subito tutte le informazioni che 
consentirebbero una catalogazione automatica efficiente da parte di 
motori di ricerca e la pubblicazione dei contenuti delPJ anche sotto 
forma di canale RSS -e non è poco.

Conosco in maniera molto superficiale il "Dublin Core", ma quel poco che 
so è abbastanza per dargli un'occhiata: certi problemi che ci stiamo 
ponendo noi se lo sono già poste altre persone che rispetto a noi hanno 
un vantaggio enorme: si occupano specificamente di certi problemi.

In quanto al testo ASCII, alla fine del gioco deve essere impaginato: in 
HTML, in PDF, in RSS, in quello che vogliamo... e farlo a manina non è 
sostenibile. Se scriviamo in XML la pubblicazione nelle forme più 
disparate è quasi gratis (XSLT o XPathScript che si voglia usare se ne 
viene fuori abbastanza agevolmente).

> realizzare un prodotto di uso generale e' un progetto marziano.

Partiamo da un fatto: vogliamo un formato di descrizione di articoli
tecnici che trattano di informatica, punto. Non mi aspetto che la American
Mathematical Society butti via il suo AMSTeX per buttarsi su XPJ. Però
credo di potermi aspettare che da XPJ possa nascere qualcosa di uso
commerciale. Se non per altro, i miei articoli per Login li scriverò in
XPJ e proverò a scrivere un convertitore XPJ->RTF, così non sarò costretto
a usare un certo programma su un certo sistema operativo per scrivere i
miei articoli :-)

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

Paura anche mia. E infatti sto martellando perché si eviti di inserire
troppi... fronzoli e ci si limiti a descrivere la struttura dell'articolo.
Sono d'accordo: sia l'anarchia che la reinvenzione della ruota sono un
danno, e devono essere evitati come la peste!

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

Uhmmmmmmm...
Gli obbiettivi mi sembrano abbastanza chiari invece (vedi sopra): stiamo
cercando di capire come raggiungerli.

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

Giuro che non voglio snobbare dicendo: cosa c'è in giro? Giuro che non ho
idea di cosa esista attualmente, e soprattutto se esista. Se c'è qualcosa
già bell'e fatto non ho nessuna opposizione a far morire sul nascere XPJ!

> - Le riviste cartacee nelle edicole che parlano di informatica fanno,
> tipograficamente parlando, cag^H^H^Hschifo:

a me fanno più schifo i contenuti...

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

Ehm... e quindi?

> - 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);

SI!

> 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!).
> 

NO! NO! NO! Non sono cose che entrano a livello di XPJ, ma -eventualmente-
di trasformazione del documento!

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

SGML è il massimo... e non ne abbiamo bisogno. Per quello che ci serve
XML è più che sufficiente.

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

Appunto. Alla larga!

> 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, ...?...

Sicuramente HTML. Se ne tiriamo fuori anche LaTeX direi che PS e PDF sono
_decisamente_ a portata!

> 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.).

Ehm... XPJ?

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

Mh...

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

Ok, vediamo...

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

Lo stavamo facendo. Continuiamo.

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

Temo HTML... temo l'uso "creativo" dei più "esperti" come quello dei "nerd".
E per queste cose la gabbia di una sintassi rigida e con nessun hook
tipografico sia la cosa migliore.

[...]

No, non ho bisogno di quotare tutto il resto del messaggio per dire che
tutti i passaggi che hai descritto li vedo come un sovraccarico pesantissimo
per la redazione. Vedo molto meglio una validazione via web dell'articolo:
sottometti l'articolo usando un form, se passa ok; se non passa lo aggiusti
e non tanti saluti. Che nessuno regala tempo a nessuno. O no?

> Ma... il numero di gennaio e' chiuso o no?

Ma... booooohhh!!! :-D

Ciao!
Marco

______________
[1] Per giunta, sto usando il portatilino aziendale che ha un winmodem e 
quindi mi tocca usare un ben noto sistema operativo non libero di cui 
non faccio il nome...