Riprodurre la veste tipografica di ClassicThesis

Mi sembra una buona proposta. Formando una task force di 4-5 persone credo che la cosa sia fattibile in tempi nemmeno troppo lunghi.

Sto scrivendo la mia tesi di dottorato usando l’ormai famigerato ClassicThesis. La resa tipografica è molto attraente ma, dei due obiettivi fondamentali che l’autore si era prefisso,

1. Provide students with an easy-to-use template for their Master’s
or PhD thesis. (Though it might also be used by other types of
authors for reports, books, etc.)
2. Provide a classic, high quality typographic style which is inspired
by Bringhurst’s “The Elements of Typographic Style”

il primo non sembra sia stato raggiunto appieno. ClassicThesis non è, secondo me, easy-to-use.

Non sono molto d’accordo. Come hai detto, il risultato tipografico di ClassicThesis è splendido. Ho addirittura comprato il bellissimo libro di Bringhurst: beh, lo stile è proprio quello! Il difetto di ClassicThesis è che il codice è un po’ “sporco”: i capitoli sono introdutti con \myChapter, le parti con \myPart, la bibliografia è introdotta con
`\manualmark
\markboth{\spacedlowsmallcaps{\bibname}}{\spacedlowsmallcaps{\bibname}}
\refstepcounter{dummy}
\addcontentsline{toc}{chapter}{\tocEntry{\bibname}}
`
… Tutto questo rende il codice non del tutto portabile. Se si cambia classe (per esempio, se si decide di passare alla classe book), è necessario fare un po’ di lavoro. Idealmente, questo non dovrebbe succedere.

ClassicThesis non è facile da usare? Non direi, non è più difficile di quanto non lo sia una classe standard (come book o article) con i pacchetti che permettono di avere quei risultati.

Se, poi, si avesse qualche necessità di personalizzare il codice e ci si imbattesse in un conflitto tra pacchetti, mi sembra che solo pochissimi (La)TeX-wizards possano cavarsela.

Questo è vero, ma è una regola generale di LaTeX, non di ClassicThesis: quando vuoi personalizzare in profondità il risultato tipografico di un documento o risolvere un subdolo conflitto tra pacchetti, l’aiuto di un guru è indispensabile. Ma questo, dicevo, non vale solo per ClassicThesis.

Insomma, sto usando il pacchetto, ma ho qualche riserva, e soprattutto paura che qualcosa andrà storto in futuro.

Vero, potrebbe succedere. Ma sono pronto a scommettre che sul forum una soluzione la trovi, grazie ad Enrico, Andrea, Lapo, …

Mi chiedo se non valga la pena cercare di riprodurre la resa tipografica di ClassicThesis senza usarlo: quanto costerebbe caricare i pacchetti giusti, in modo appropriato, e ottenere in modo pulito lo stile di ClassicThesis?

A me questa idea non piace. ClassicThesis c’è, ed è un merito dell’autore aver avuto l’idea (prendo un classico impaginanto magnificamente e riproduco quel layout in LaTeX) e averla realizzata. Insomma: ben venga tutto quello che viene per migliorare lo stile di André -personalmente, apprezzo molto il tuo entusiasmo!- ma visto che l’idea è sua, è giusto che i meriti vadano a lui, senza “scavalcarlo”. Fra l’altro, la versione 2.0 dello stile contiene diverse migliorie che sono conseguenza di quanto emerso sul forum di GuIT. Ecco, questa mi sembra la strada più corretta per migliorare (il già ottimo) ClassicThesis!

Riscrivere ex-novo il codice di ClassicThesis e renderlo più pulito? (Solo) Enrico potrebbe farlo, ma non credo che lo voglia, almeno non in questi termini.

…mi pare di ricordare un intervento in cui si diceva che ClassicThesis porta con sé alcuni problemi comuni ai pacchetti che “vogliono fare tutto”.

Io non lo chiamerei un problema. È piuttosto una caratteristica dello stile: prendersi cura di tutti gli aspetti del layout di un documento.

Ciao,
L.

La griglia di ClassicThesis, ad esempio, non sarebbe riproducibile con geometry? Bisogna per forza passare per i koma-script?

Mi ricordo che Enrico in persona ha detto che la griglia delle classi KOMA è definita dal pacchetto typearea o dal comando \areaset, e che cercare vie alternative è arduo.

Da ultimo, faccio notare che il modo migliore per usare ClassicThesis, è quello di studiarsi i sorgenti della documentazione, copiarli e incollarli nel proprio documento. Il che, sempre a mio parere, non è proprio facile.

È vero: la scarsa documentazione è una nota dolente dello stile, come riconosce lo stesso autore.

Forse la cosa migliore è sentire che cosa ne pensa André: http://wase.urz.uni-magdeburg.de/fchu/2miede/index.php?page=contact

Da fan entusiasta di ClassicThesis, ti faccio i miei complimenti per la tua iniziativa di migliorare questo affascinante stile.

Ciao,
L.

Io sto valutando proprio oggi se utilizzarlo o no, ma sono piuttosto spaventato dal dover perdere parecchio tempo a risolvere eventuali problemi di compatibilità. Lo stile è indubbiamente molto interessante, ma non vorrei trovarmi a dover rimettere mano a tutto perchè ad un certo punto s’arriva a qualche problema veramente tosto.

Penso che procederò con book, conscio del fatto che i vari cambiamenti non dovrebbero richiedere troppo tempo (Lorenzo ha detto un paio d’ore per il suo libro).

Approvo in toto l’idea presentata da Daniele, ma non sono abbastanza esperto per contribuire attivamente al progetto. Mi spiace.

La griglia di ClassicThesis, ad esempio, non sarebbe riproducibile con geometry? Bisogna per forza passare per i koma-script?

Mi ricordo che Enrico in persona ha detto che la griglia delle classi KOMA è definita dal pacchetto typearea o dal comando \areaset, e che cercare vie alternative è arduo.

Con geometry si potrebbe senza dubbio. Non lo si può usare con koma-script, su cui è basato il resto del pacchetto.

Un progetto del genere proposto sarebbe molti simile a quello di memoir: Peter Wilson ha riscritto all’interno della classe moltissime cose già presenti in altri pacchetti, proprio per limitare le incompatibilità. Ha la sua versione di tocloft, di titlesec, di setspace, di enumitem eccetera. Tuttavia memoir si propone di essere una classe “universale”, mentre le ambizioni di ClassicThesis sono più limitate. Per questo ritengo sbagliato inserire obbligatoriamente decine di pacchetti di cui magari l’utente non ha affatto bisogno.

Proprio oggi in una risposta ho fatto notare che il pacchetto guit richiama automaticamente hyperref. Penso che scriverò a Emanuele proponendogli di evitarlo e definire un’opzione per caricarlo: un utente che carichi prima guit e poi hyperref con le sue opzioni si troverebbe a malpartito. È vero che c’è l’avvertimento nella documentazione, ma a qualcuno potrebbe seccare di dover usare per forza hyperref anche se non gli serve (a me, per esempio :D).

Questo tipo di incompatibilità, innocuo nel caso di guit, capita molto spesso con ClassicThesis, come si è visto nei numerosi messaggi sull’argomento.

Conclusione? Rifare la classe (come classe vera) sembra proprio un lavoraccio.

Ciao
Enrico

Io sto valutando proprio oggi se utilizzarlo o no, ma sono piuttosto spaventato dal dover perdere parecchio tempo a risolvere eventuali problemi di compatibilità. Lo stile è indubbiamente molto interessante, ma non vorrei trovarmi a dover rimettere mano a tutto perchè ad un certo punto s’arriva a qualche problema veramente tosto.

Ti consiglio di dare un’occhiata alla tesi che ha scritto A. Miede con il suo stile. Tieni presente che, per arrivare a quel risultato, non c’è alcun “problema tosto” da affrontare… anzi! Basta usare il template di ClassicThesis.

http://wase.urz.uni-magdeburg.de/fchu/2miede/index.php?page=classicthesis

Penso che procederò con book, conscio del fatto che i vari cambiamenti non dovrebbero richiedere troppo tempo (Lorenzo ha detto un paio d’ore per il suo libro).

Tranquillo, il “porting” è questione di poco. La maggior parte del tempo è dovuta ai piccoli, inevitabili aggiustamenti che si fanno in revisione finale: è un problema, questo, che si presenterebbe anche all’interno della stessa classe cambiando i margini, per esempio.

A dirla tutta, stavo pensando proprio di contattare l’autore di ClassicThesis con una email di feedback.

Ottima idea, facci sapere!

Ciao,
L.

Purtroppo i risultati non sono al momento tra i migliori, come testimonia il problema riscontrato recentemente:
http://www.guit.sssup.it/phpbb/viewtopic.php?t=3453

Inizialmente ho anche dovuto lottare con le incopatibilità dei pacchetti precendetemente inseriti e già caricati dallo stile stesso, ed anche quello è stato abbastanza noioso. Stesso vale per il dover adottare comandi non standard per capitoli o parti, o per il dover usare altre trucchetti o accortezze.

Appoggio incondizionatamente la richiesta di daniele: un pacchetto che renda la grafica di classicthesis agendo in maniera chiara solo sul layout, ed utilizzando pacchetti standard.

Come posso fare per utilizzare la combinazione di font usati in classic thesis?

É corretto chiamare:
\usepackage{palatino}
\usepackage{euler}

per testo e formule? E per il bera mono come posso fare?

Inoltre, un piccolo appunto: non mi è molto chiaro lo scopo di asmfonts. Serve a migliorare la famiglia di font computer modern math? In ogni caso, ho l’impressione che vada levato… giusto?

Purtroppo i risultati non sono al momento tra i migliori, come testimonia il problema riscontrato recentemente:
http://www.guit.sssup.it/phpbb/viewtopic.php?t=3453

Inizialmente ho anche dovuto lottare con le incopatibilità dei pacchetti precendetemente inseriti e già caricati dallo stile stesso, ed anche quello è stato abbastanza noioso. Stesso vale per il dover adottare comandi non standard per capitoli o parti, o per il dover usare altre trucchetti o accortezze.

Appoggio incondizionatamente la richiesta di daniele: un pacchetto che renda la grafica di classicthesis agendo in maniera chiara solo sul layout, ed utilizzando pacchetti standard.

Mi scuso se intervengo sempre quando si parla di ClassicThesis ma…

Mi pare di aver capito che i problemi che hai avuto fossero colpa della tua distribuzione, e non di ClassicThesis, che (come riportato sulla doc.) è pensato per funzionare con una distribuzione completa di MikTeX o TeXlive (sono distribuzioni eccellenti, multipiattaforma e gratuite… che vuoi di più?).

Riguardo alla richiesta paradossale di “avere ClassicThesis… senza usare ClassicThesis”, ho già detto come la penso: non ha senso.

1. Per ragioni “etiche”: l’idea è di Miede, giusto che a lui vada la “gloria”.

2. Per ragioni “economiche”: lo stile ClassicThesis è stato usato con successo ed è diffuso in tutto il mondo e, anche se è giovane, è relativamente ben collaudato. L’autore l’ha aggionato spessissimo, raccogliendo il feedback di molti utenti (noi del GuIT compresi). Tutto questo patrimonio di conoscenze verrebbe gettato al vento, ricominciando da zero.

Vedi, le mie difficoltà di utente di ClassicThesis erano più che altro “psicologiche” e nascevano dalla (mia) ignoranza delle classi KOMA (che sono eccellenti, ma non documentate nelle guide più diffuse). Anche per questo nella guida che ho scritto c’è un paragrafo dedicato alle classi KOMA, in cui c’è l’essenziale per non trovarsi a disagio.

http://www.lorenzopantieri.net/ClassicThesis_files/ClassicThesis.pdf

In conclusione, se hai dei problemi, chiedi tranquillamente: a me (che forse qualcosa so dirti), qui sul forum (Enrico sa sicuramente dirti tutto), all’autore, che è persona assai disponibile.

Vadrai che una soluzione la troviamo…

non mi è molto chiaro lo scopo di asmfonts. Serve a migliorare la famiglia di font computer modern math? In ogni caso, ho l’impressione che vada levato… giusto?

Il pacchetto amsfonts, fra l’altro, rende disponibile il carattere “neretto da lavagna” \mathbb. Non va tolto.

Ciao,
L.

Mi pare di aver capito che i problemi che hai avuto fossero colpa della tua distribuzione, e non di ClassicThesis, che (come riportato sulla doc.) è pensato per funzionare con una distribuzione completa di MikTeX o TeXlive (sono distribuzioni eccellenti, multipiattaforma e gratuite… che vuoi di più?).

Non metto in dubbio il fatto che l’errore sia dovuto alla mia distribuzione, soprattutto alla luce del fatto che quel codice viene compilato da altri. Semplicemente tetex è al momento l’unica distribuzione di LaTeX presente nei repository di Frugalware, ed a dire il vero, neppure sapevo che il suo sviluppo fosse stato interrotto.

Non ne ho fatto comunque un attacco a classicthesis.. o almeno, non intenderlo in questa maniera.

Riguardo alla richiesta paradossale di “avere ClassicThesis… senza usare ClassicThesis”, ho già detto come la penso: non ha senso.

1. Per ragioni “etiche”: l’idea è di Miede, giusto che a lui vada la “gloria”.

2. Per ragioni “economiche”: lo stile ClassicThesis è stato usato con successo ed è diffuso in tutto il mondo e, anche se è giovane, è relativamente ben collaudato. L’autore l’ha aggionato spessissimo, raccogliendo il feedback di molti utenti (noi del GuIT compresi). Tutto questo patrimonio di conoscenze verrebbe gettato al vento, ricominciando da zero.

A parer mio nessuno a fatto una richiesta di questo tipo, ed anche se fosse non la vedrei paradossale. La mia richiesta, e credo anche quella di Daniele, è “di avere un ClassicThesis più pulito”. Io non sono assolutamente esperto, ma andando a vedere le classi adoperate dallo stile si vedono cose del tipo:

\newcommand{\On}{\ensuremath{O(n)}\xspace}

che sinceramente non vedo come c’entri con classic thesis stesso. Alla stessa maniera non capisco perchè chiami:

\RequirePackage{listings}

Ed a voler esser proprio pignolo, a parer mio non è neppure opportuno chiamare:

\RequirePackage{subfig}

Sempre dal codice:

% yet another dirty work-around to get the spaced low small caps into the toc ;-(

Quindi, a parer mio, classicthesis fa qualcosa di troppo e talvolta non nella maniera migliore. La richiesta non è quindi: facciamo un pacchetto a marchio GuIT e facciamo guerra a classicthesis, ma prendiamo quel che c’è di buono in classicthesis, organizziamolo bene, e chiamiamolo classicthesis-lite. In questa maniera non compromettiamo l’idea di Miede, ma la sviluppiamo e la ampliamo. T’assicuro che son bel lontano dal voler rubare la gloria a Miede:

1. non ne avrei le capacità, perciò il mio nome non verrebbe mai “glorificato” al suo posto.
2. che ci sia il suo, il tuo, o quello di un terzo, per quanto riguarda i vantaggi che ne posso trarre, cambia davvero poco.

Vedi, le mie difficoltà di utente di ClassicThesis erano più che altro “psicologiche” e nascevano dalla (mia) ignoranza delle classi KOMA (che sono eccellenti, ma non documentate nelle guide più diffuse). Anche per questo nella guida che ho scritto c’è un paragrafo dedicato alle classi KOMA, in cui c’è l’essenziale per non trovarsi a disagio.

http://www.lorenzopantieri.net/ClassicThesis_files/ClassicThesis.pdf

In conclusione, se hai dei problemi, chiedi tranquillamente: a me (che forse qualcosa so dirti), qui sul forum (Enrico sa sicuramente dirti tutto), all’autore, che è persona assai disponibile.

Vadrai che una soluzione la troviamo…

Non condivido assolutmente il discorso dell’ignoranza. Latex è potente perchè anche gli ignoranti in tipografia possono ottenere risultati eccellenti. Beh.. questo serve a poco se invece di essere un tipografo devi essere ingegnere informatico + grande esperto di LaTeX + profondo conoscitore di ogni singolo pacchetto. Salvaguardiamo l’ignoranza!!!
Poi il discorso che fai cozza in qualche maniera con quanto hai detto tu prima: perchè le classi KOMA? Non sono esse stesse un dispendio economico? E quanti le utilizzano? Se è vero quel che ricordo, ovvero che hanno documentazione solo in tedesco, beh.. non credo molte persone..

Ti ringrazio infinitamente per la guida e per il tuo aiuto (se leggi il mio primo intervento vedi che già conoscevo la tua guida.. anzi, è stata proprio quella a spingermi a provare 😉 ), ma a parer mio non è questione di risolvere un problemino qua e uno là. Il problema è che (finchè qualche guru non mi smentisce) ho l’impressionedi esser costretto a diverse modifiche per problemi non insormontabili, e questo rende l’utilizzo del pacchetto in qualche modo irritante. Se si arriverà a poterlo aggiungere o togliere a piacere, senza passare da Koma a book, da mychapter a chapter, senza aggiungere o togliere 5-6 pacchetti, ecc ecc, allora diventerà un piacere usarlo.

[La richiesta] è quindi: prendiamo quel che c’è di buono in classicthesis, organizziamolo bene, e chiamiamolo classicthesis-lite.

Per i motivi che ho elencato, sono contrario, naturalmente.

Latex è potente perchè anche gli ignoranti in tipografia possono ottenere risultati eccellenti. Beh.. questo serve a poco se invece di essere un tipografo devi essere ingegnere informatico + grande esperto di LaTeX + profondo conoscitore di ogni singolo pacchetto. Salvaguardiamo l’ignoranza!!!

Credo che le difficoltà che un utente incontra usando le classi KOMA e ClassicThesis non siano di più di quelle di chi usa le classi “standard” ed altri pacchetti o stili.

Perchè le classi KOMA? Non sono esse stesse un dispendio economico? E quanti le utilizzano? Se è vero quel che ricordo, ovvero che hanno documentazione solo in tedesco, beh.. non credo molte persone..

Le classi KOMA sono buone come le altre. La documentazione è anche in inglese:
http://tug.ctan.org/cgi-bin/getFile.py?fn=/macros/latex/contrib/koma-script/scrguien.pdf

Quanto al “dispendio economico”, in un certo senso è così. Tuttavia, il problema si ripropone pari pari in molti ambiti: non è uno spreco che esistano più sistemi operativi per computer? O che esistano più marche di automobili?

Ma siamo OT.

ho l’impressionedi esser costretto a diverse modifiche… Se si arriverà a poter aggiungere o togliere [il pacchetto] a piacere…

Sono d’accordo su una parte del tuo ragionamento: l’ideale sarebbe poterlo togliere e aggiungere senza colpo ferire.

Tuttavia, è difficile pensare di togliere o aggiungere un pacchetto “significativo” senza dover fare qualche intervento manuale. Per esempio, se, dopo aver ultimato un lavoro, carichi un pacchetto che rifefinisce i margini, succede che cambia tutta l’impaginazione e ti tocca rifare daccapo la “regolazione fine” (estenuante, ma ineludibile, se vuoi raggiungere un’elevata qualità) che precede la pubblicazione.

La portabilità è un “concetto asintotico” e LaTeX è un sistema semi-automatico (non completamente automatico) di composizione tipografica.

Nella guida a LaTeX che sto scrivendo (con ClassicThesis, chiaro :wink:) questo è un punto su cui insisto molto…

Buon ClassicThesis,
Lorenzo

Per i motivi che ho elencato, sono contrario, naturalmente.

Sinceramente non lo vedo molto naturale. Non voglio scendere in polemica, ma vorrei precisare la mia posizione: ti prego di non considerare il mio intervento come un attacco a te, a Miede o a clasicthesis.

Se non è fatto con l’intenzione di rubare l’idea a Miede, il primo motivo che hai elencato non sussiste. Per quanto mi riguarda, potrebbe esserci il suo nome ed il suo solo anche nel nuovo pacchetto. Anzi, potrebbe esserci anche solo il suo pacchetto classicthesis, sempre con il suo nome ed il suo solo, e l’opzione “slim” che fa quello che interessa a me.

Non vedo come questa potrebbe essere intesa come “appropriazione indebita di gloria”.

Quanto al “dispendio economico”, in un certo senso è così. Tuttavia, il problema si ripropone pari pari in molti ambiti: non è uno spreco che esistano più sistemi operativi per computer? O che esistano più marche di automobili?

Ma siamo OT.

E qui hai ragione, ma allo stesso tempo non si può giudicare negativamente un branch per motivi di “dispendio economico”, quando il progetto stesso fa scelte che sono “dispendio economico”.

Sono d’accordo su una parte del tuo ragionamento: l’ideale sarebbe poterlo togliere e aggiungere senza colpo ferire.

Tuttavia, è difficile pensare di togliere o aggiungere un pacchetto “significativo” senza dover fare qualche intervento manuale. Per esempio, se, dopo aver ultimato un lavoro, carichi un pacchetto che rifefinisce i margini, succede che cambia tutta l’impaginazione e ti tocca rifare daccapo la “regolazione fine” (estenuante, ma ineludibile, se vuoi raggiungere un’elevata qualità) che precede la pubblicazione.

Beh.. concorderai con me che quanto riportato nel mio precedente intervento non aiuta gran che tutto questo. Se uno s’era già definito per conto suo il comando \On, ora lo deve togliere. Toglie classicthesis, lo deve ridefinire. E questo non ha nulla a che fare con il layout. Stessa cosa per il pacchetto listings.
Quel che non capisco è perchè questi comandi sono lì. Questa non è esattamente la versione 0.2 alpha del pacchetto…

Beh.. concorderai con me che quanto riportato nel mio precedente intervento non aiuta gran che tutto questo. Se uno s’era già definito per conto suo il comando \On, ora lo deve togliere. Toglie classicthesis, lo deve ridefinire. E questo non ha nulla a che fare con il layout. Stessa cosa per il pacchetto listings.
Quel che non capisco è perchè questi comandi sono lì. Questa non è esattamente la versione 0.2 alpha del pacchetto…

Ho già scritto che classicthesis soffre di una certa elefantiasi e carica pacchetti che non dovrebbe, per esempio listings, hyperref e backref. Il primo serve solo a pochi; basterebbe definire l’apposita opzione che definisca nel modo desiderato i parametri per comporre il codice LaTeX. Gli altri due devono essere richiamati a richiesta dell’autore: non sempre le funzionalità di hyperref sono necessarie e spesso danno problemini che risultano incomprensibili a chi non ne ha bisogno.

Di sicuro, e su questo proprio non ho dubbi, nessun pacchetto o classe che si occupi della forma tipografica si deve permettere di definire comandi come \On o \Ologn che sono semplici abbreviazioni per la composizione di particolari strutture. Ancora, definire \ie e \eg per le comuni abbreviazioni inglesi è qualcosa che non va fatto in un pacchetto o classe del genere. Immagino che siano rimasugli dell’origine del pacchetto, ovviamente nato per comporre la tesi di Miede. Perché infliggerli agli utenti che non hanno le sue esigenze?

Per finire: il modo con cui è scritto è terribile. Dovrebbe essere una classe; quel caricare prima classicthesis-ldpkg è un’assurdità. Se li si guarda con attenzione si scoprono duplicazioni di caricamenti di pacchetti, comandi definiti qua e là senza un ordine preciso: per esempio, hyperref è caricato da ldpkg, mentre sappiamo bene che hyperref va caricato quasi sempre per ultimo.

Il risultato è encomiabile, ma ora si dovrebbe raffinare il codice e farlo diventare una classe.

Ciao
Enrico

Ho già scritto che classicthesis soffre di una certa elefantiasi e carica pacchetti che non dovrebbe, per esempio listings, hyperref e backref. Il primo serve solo a pochi; basterebbe definire l’apposita opzione che definisca nel modo desiderato i parametri per comporre il codice LaTeX. Gli altri due devono essere richiamati a richiesta dell’autore: non sempre le funzionalità di hyperref sono necessarie e spesso danno problemini che risultano incomprensibili a chi non ne ha bisogno.

Di sicuro, e su questo proprio non ho dubbi, nessun pacchetto o classe che si occupi della forma tipografica si deve permettere di definire comandi come \On o \Ologn che sono semplici abbreviazioni per la composizione di particolari strutture. Ancora, definire \ie e \eg per le comuni abbreviazioni inglesi è qualcosa che non va fatto in un pacchetto o classe del genere. Immagino che siano rimasugli dell’origine del pacchetto, ovviamente nato per comporre la tesi di Miede. Perché infliggerli agli utenti che non hanno le sue esigenze?

Per finire: il modo con cui è scritto è terribile. Dovrebbe essere una classe; quel caricare prima classicthesis-ldpkg è un’assurdità. Se li si guarda con attenzione si scoprono duplicazioni di caricamenti di pacchetti, comandi definiti qua e là senza un ordine preciso: per esempio, hyperref è caricato da ldpkg, mentre sappiamo bene che hyperref va caricato quasi sempre per ultimo.

Il risultato è encomiabile, ma ora si dovrebbe raffinare il codice e farlo diventare una classe.

D’accordo su tutto, certo. Giro immediatamente le Tue osservazioni ad André.

Ciao,
L.