[Pluto-devel] ci sono

[Marina Sturino]

Umberto Salsi wrote:

> Io stesso scrissi:

[come vedi, non quoto proprio tutto :-) ]
> 
> - 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!).

Quello a cui voglio puntare io, non e' la reinvenzione della ruota, ma ad
un sistema che consenta di non perdere tempo sulla parte di impaginazione,
ad esempio ogni volta controllando, file per file, che dopo il box 
dell'autore ci siano due <br>, che prima dell'<hr> ce ne sia uno, oppure
di essermi ricordato di fare il copia e incolla per le ancore, ecc...

Probabilmente a te sembrera' piu' semplice ricevere un testo ASCII e poi
inserirvi i tag a mano, ma cosi' si perde soltanto del tempo che potrebbe
essere dedicato alla scrittura degli articoli, alla rilettura dei medesimi, 
ecc...

L'uniformita' in questi casi, e' importante e usando XML e XSL, il lavoro
di formattazione "visuale" dell'articolo si farebbe un'unica volta, per 
tutti i numeri a venire, fino a quando non si decide di cambiare impostazione,
per un qualsiasi motivo.

Scindere la parte di presentazione dalla parte dei contenuti e' fondamentale, 
almeno secondo me.

XML darebbe solo la struttura del documento: autore, articolo, titolo, ecc...
eventuali impostazioni tipografiche, interlinea, spaziatura, ecc. sarebbero 
definite dei vari stylesheet da utilizzare.
Sul web, per avere una reale accessibilita' da parte di tutti, non c'e' 
possibilita' alcuna di agire sugli aspetti tipografici piu' fini, CSS1 e CSS2
permettono di variare semplicemente tutti gli elementi tipografici della 
pagina web, peccato pero' che il supporto da parte dei browser di questi 
standard w3c (CSS1 e' diventato raccomandazione nel lontano 1996) e' alquanto
limitato e vario... 
se invece si pensa di realizzare una versone stampabile del journal, poter 
variare determinati aspetti tipografici puo' facilitare la lettura. Non ho 
ancora iniziato a studiare XSL:Fo, ma ancora poter disporre dei contenuti 
in un formato come XML, consente di ottenere il pdf usando un solo stylesheet
scritto ad hoc.

Quindi, a mio giudizio, la possibilita' di poter formattare (in HTML e in PDF,
ad esempio) 50 articoli usando solo due stylesheet mi sembra un notevole
vantaggio, anche dal punto di vista di eventuali modifiche da effettuare.

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

Nemmeno io so come fa Giacomini a produrre i suoi documenti, ne che possibilita' 
da' SGML
Provero' a documentarmi in questo fine settimana, pero' SGML mi sempra piu' 
orientato all'editoria o alla gestione di grandissime quantita' di dati, oltre
che molto piu' complesso.

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

Difetto dimenticato: richiede di agire sempre sul singolo documento...

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

Questo secondo me dovrebbe essere l'ultimo problema da prendere in 
considerazione, il principale vantaggio di slegare la parte della presentazione
dai contenuti e' proprio questa.

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

XPJ (il DTD personalizzato da usare per validare l'XML) dovrebbe essere il 
nostro formato originario, che poi e' un semplice file di testo.
Il problema principale e' stabilire quali tag sono importanti per la parte 
descrittiva del documento (autore, data di pubblicazione, tipo di documento,
ecc...) e quali per l'articolo vero e proprio (sezioni, paragrafi, tabelle,
listati, codice in linea...)

L'eventuale tag <listato>, riceverebbe poi a livello di xsl l'adeguata 
formattazione, in base a come si decide di formattarlo.
Se mi concedete, domani posto tutto cio' che costituisce un articolo: capitoli,
paragrafi, figure, tabelle, note a fondo pagina, 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.
> 

Un problema pratico, legato all'usabilita', c'e'.
Lo si puo' notare nell'articolo di Mano sul concorso del miglior programma
in C offuscato. Se lo guardate con Konqueror, un browser piuttosto usato 
dagli utenti Linux, a causa di una riga di codice lunghissima preformattata, 
tutto l'articolo va letto facendo uso della barra di scorrimento orizzontale.

Con altri browser questo problema c'e' solo per la riga incriminata, cio' non 
toglie pero' che il problema di ripresentera' qualora l'utente volesse stampare
il documento.

Problema che si verifica anche con la terza puntata di Nicola del corso su GTK+

E come comportarsi, sempre con i listati nella versione pdf o ps da stampare?
Mentre sul web non ci sono limiti di larghezza (a parte la scomodita' di dover
usare la barra di scorrimento orizzontale per leggere tutto, a meno di non usare
lynx, in tal caso la riga incriminata va a capo alla fine dell'80esimo carattere,
come nei vecchi terminali - ma dubito che lynx sia il browser piu' usato dai 
lettori del PJ), le versioni cartacee "soffrono" del limite dato dal normale 
foglio A4.

Pertanto diventa indispensabile trovare una sorta di "workaround" per scrivere i 
listati, mantenendo l'indentazione (per i motivi di comprensione di cui accennavi
nella parte che ho tagliato in cui parli di libri e riviste mal strutturate) e
nello stesso tempo per riportare interamente le righe che uscirebbero dalla pagina.

> 
> 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.
[taglio il resto di questa parte...]

Ma richiede continui controlli manuali per uniformare il tutto, anche nel caso 
di creare un HTML PJ compliant, a meno di non creare un parser che controlli
accuratamente quanti <br> sono stati dati tra il box dell'autore e l'inizio
dell'articolo, quanti &nbsp; sono stati dati per creare il rientro di prima riga,
ecc... cosa che non so nemmeno se sia fattibile, ma non credo proprio...
da quanto ne so io, il parser controllerebbe la presenza o meno di elementi 
non permessi, (annidamenti considerati illegali, tag estranei, ecc...)

Purtroppo non ne so abbastanza per intervenire dettagliatamente sulla parte di 
programmazione pura.

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

Questo non lo so, a me manca da rileggere solo il tuo articolo su Apache, poi ci 
sara' da controllare, lavoro da certosino, l'uniformita' dell'html di tutti gli 
articoli. Personalmente, se controllo il testo, non riesco a controllare
contemporaneamente la formattazione... perdo il senso di quello che sto leggendo.


Ciao!
Marina

> 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
> 
> 
> _______________________________________________
> pluto-devel mailing list
> pluto-devel@lists.pluto.linux.it
> http://lists.pluto.linux.it/mailman/listinfo/pluto-devel



-- 
-------------------------------------------------------------
L'unico modo per accelerare windows 9.x/2K e' a 9,8 m/s^2 ;-)
Utente Linux registrato: #218195 (http://counter.li.org)