Marchetto, non so che cosa vuoi dire quando dici che la struttura degli alberi è spiegata sula guida GuIT solo per MiKTeX, ma nel §4.4 io ci leggo tutto quello che serve per sapere che cosa è l’albero personale; in particolare c’è scritto di consultare il documento tds.pdf con il comando texdoc tds che spiega la struttura degli alberi assunta dal sistema TeX, e, in particolare, seguita da TeXLive; per MiKTeX, forse c’è detto qualcosa di più, ma solo perché la ditribuzione MiKTeX non usa completamante la TeX Directory Syste (TDS per gli amici) descritta nel documento tds.pdf.
Ciò premesso nella pagina 49, più precisamante nel seto coapoverso del §4.4 si legge:
Ciò premesso, ogni utente farebbe bene a costruirsi un suo albero personale, conforme alla TDS, dove conservare le sue macro, i font che egli si crea, i pacchetti che si scrive; insomma tutto quanto gli sia strettamente personale e sia funzionale al funzionamento dei programmi del sistema TEX. Questo albero personale parte dalla cartella texmf che si trova nella sua $HOME; questo nome simbolico $HOME ha un significato diverso in ogni sistema operativo e deve essere diverso dalla ‘radice’ sulla quale sono innestati gli alberi installati dal programma di installazione. Normalmente questo nome simbolico rappresenta:
• ~/ nei sistemi Linux;
• ~/Library/ nei sistemi Mac OS X;
• C:\Documents and Settings\⟨utente⟩\Documenti\ con l’installazione di MiKTEX sulle macchine Windows XP; sulle versioni Windowds Vista, Seven, Eight, vale C:\Users\⟨utente⟩\Documenti\;
dove ⟨utente⟩ è il nome con il quale il particolare utente si è registrato sulla macchina.
A me pare che ci sia scritto tutto quel che occorre; che cosa ti è oscuro?
Aggiungo che sono d’accordissimo con te a proposito del fatto che non sarebbe stato difficile documentare meglio il pacchetto pst-blur. Permettimi un commento personale: le istruzioni per i compilatori di pacchetti da caricare su CTAN sono chiarissime sul fatto che i pacchetti debbano essere documentati adeguatamente. sono richiesti almeno tre file per ogni pacchetto (che a sua volta può contenere diversi file generati elaborando il pacchetto .dtx. Precisamente sono necessari almeno il file .dtx (Documented TeX file, che può essere auto-estraente oppure richiede un file con lo stesso nome e l’estensione .ins per estrarne i contenuti) un file manifest.txt e un file di testo README, senza estensione na deve essere solo testo. Il file .dtx è quello che contiene la documentazione e i file da estrarre; gli altri due debbono contenere le informazioni legali e le istruzioni per l’installazione. Compilando il file .dtx con pdfLaTeX si ottiene la documentazione; se il file è auto-estraente, si estraggono anche i fil di classe, di estensione, di definizione, di descrizione dei font, di definizione delle lingue, e compagnia bella.
Ecco, la mia considerazione è questa: non hai idea di quanti pacchetti preziosi, non hanno documentazione alcuna, oppure ne hanno una ridotta a poche righe, assolutamente inutili; non hai idea di quanti pacchetti contengono solo documentazione in ostrogoto alto-medievale, lingua che evidentemente tutti conoscono come la lingua madre; capisco che se scrivi un pacchetto per comporre in mongolo (non è un nome scritto a caso) la documentazione sia in mongolo; è verosimile che chi vuol scirvere in mongolo conosca il mongolo anche se non è la sua lingua madre. Ma mi domando perché pacchetti di uso generale sono documentati solo intedesco, solo in litauano, solo in…; per gli altri è come si i pacchetti non fossero documentati. Confesso: ho scritto anch’io dei pacchetti con la documentazione in italiano , ma ho inserit anche la documentazione in inglese, spiegando come e perché avevo scritto una seconda documentazione in italiano. Forse non avrei dovuto farlo affatto, ma finora nessuno se ne è lamentato. TOPtesi è un tale pacchetto; viene usato anche all’estero; evidentemente la documentazione in inglese è sufficiente anche epr una persona che non conosce l’italiano.
Ma, tornando a psf-blur, visto che la documentazione c’è, che cosa sarebbe costato all’autore di fare un po’ di copia/incolla per mostrare anche il codice sorgente dei suoi esempi? Va bene per uno che è abituato a leggere i codici sorgente, non è difficile andare a trovare come ha fatto a produrre i suoi esempi; ma sarebbe certo stato difficile per l’autore risparmiare a tutti la fatica di cercare il file sorgente; un principiante non lo saprebbe certo fare, non saprebbe nemmeno che cosa c’è dietro le quinte.