venerdì 5 novembre 2010

Confrontare le differenze fra due documenti PDF (2)

Qualche giorno fa ho illustrato un semplice script bash che permette di eseguire un confronto elementare fra due documenti PDF per cercarne le differenze. Tuttavia, come ho spiegato, questo script ha numerosi difetti perché cerca essenzialmente differenze nel testo dei due documenti (se è in grado di estrarre correttamente il testo da essi). Esiste però un programma a interfaccia grafica che permette di eseguire un confronto più efficace: DiffPDF. Questo pacchetto è fornito dalle principali distribuzioni GNU/Linux; in Debian, Ubuntu & Co. bisogna installare il pacchetto diffpdf con il Gestore pacchetti Synaptic oppure da terminale con il solito comando:
sudo apt-get install diffpdf
Per le altre distribuzioni fare riferimento al proprio gestore pacchetti.

Il programma può essere avviato dal lanciatore (in Ubuntu: ApplicazioniAccessoriDiffPDF) oppure da terminale con il comando
diffpdf
È possibile passare come argomenti i percorsi dei documenti che si vogliono confrontare:
diffpdf /percorso/del/file1.pdf /percorso/del/file2.pdf



Normalmente DiffPDF mette a confronto i testi dei documenti, ma, come potete vedere dallo screenshot seguente, è possibile anche effettuare un confronto visuale fra due documenti, per poter cercare differenze fra le immagini. Per fare ciò bisogna selezionare Appearance nel menu a tendina Comparison Mode in alto a destra e rieseguire il confronto con il pulsante Compare situato più in basso, sempre sul pannello di destra. Questa modalità potrebbe fornire dei falsi positivi (come succede nell'immagine proposta) perché non viene più confrontato solo del testo, ma comunque i risultati sono in genere molto buoni.



Anche qui propongo uno Script per Nautilus che permette di avviare DiffPDF con pochi clic selezionando i file che si desidera confrontare:
#!/bin/bash

titolo="Confronta PDF"

function controlla() {
    estensione=$(echo "$1" | cut -d. --complement -f1)
    case $estensione in
        [pP][dD][fF])
            ;;
        *)
            zenity --error --title="$titolo" --text="Devi selezionare due file con estensione \".pdf\"."
            exit 1
    esac
}

if [ $# -ne 2 ]; then
    zenity --error --title="$titolo" --text="Devi selezionare due file PDF alla volta."
    exit 1
fi
pdf1="$1"
pdf2="$2"
controlla "$pdf1" && controlla "$pdf2"
if [ $? -eq 0 ]; then
    diffpdf "$pdf1" "$pdf2"
else # non dovrebbe arrivare mai qui, metto per sicurezza
    zenity --error  --title="$titolo" --text="Si è verificato un errore."
    exit 1
fi
exit 0
Per utilizzare questo script aprite un file vuoto con un editor di testo, copiate lo script nell'editor e salvatelo nella cartella ~/.gnome2/nautilus-scripts (ricordo che la tilde ~ è un'abbreviazione della cartella home dell'utente corrente) chiamandolo, per esempio, "Confronta PDF". Rendete eseguibile lo script e così potrete selezionare due file PDF da confrontare che si trovano nella stessa cartella e, facendo clic con il tasto destro, scegliete ScriptConfronta PDF (o il nome che avete dato allo script).

martedì 26 ottobre 2010

Confrontare le differenze fra due documenti PDF

Nota: qui suggerisco il programma a interfaccia grafica DiffPDF che permette di effettuare un confronto più efficace fra due documenti PDF.

Un semplice metodo per confrontare due documenti in formato PDF è sfruttare l'accoppiata pdftotext (per convertire i PDF in testo puro) + diff (per controllare le differenze). Mi ero stancato di eseguire tutti i soliti comandi allora ho scritto questo script fresco fresco:
#!/bin/bash

function converti() {
    txt=$(eval "expr \$"$1" ")
    pdf=$(eval "expr \$"$2" ")
    scelta=""
    while [ -f "$txt" ]; do
        read -p "Il file $txt esiste già, sovrascriverlo? [s/n]: " scelta
        case "$scelta" in
            s|S|y|Y)
                break 2
                ;;
            n|N)
                read -p "Specifica un file di output differente: " txt
                ;;
        esac
    done
    if ! pdftotext "$pdf" "$txt"; then
        exit 1
    fi
    eval "$1=$txt"
}

if [ $# -ne 2 ]; then
    echo "Uso: $0 PDF1 PDF2"
    exit 1
fi
pdf1=$1
pdf2=$2
txt1=$(dirname "$pdf1")/$(basename "$pdf1" .pdf).txt
txt2=$(dirname "$pdf1")/$(basename "$pdf2" .pdf).txt
converti txt1 pdf1 && converti txt2 pdf2
if [ $? -eq 0 ]; then
    diff -u "$txt1" "$txt2" | less
fi
rm -f "$txt1" "$txt2"
exit 0
Per utilizzarlo basta copiare lo script in un file con un editor di testo a piacere, salvare il file chiamandolo, per esempio, pdf-diff, renderlo eseguibile e posizionarlo nella cartella ~/bin (ricordo che la tilde ~ è un'abbreviazione della cartella home dell'utente corrente), creandola se eventualmente non esiste. Date nel terminale il comando
. ~/.profile
(per i curiosi serve a caricare il file ~/.profile che aggiunge la cartella $HOME/bin alla variabile d'ambiente $PATH), dopo di ciò dovrebbe essere sufficiente dare nel terminale il comando
pdf-diff /percorso/del/primo/file /percorso/del/secondo/file
(o il nome che avete dato allo script).

Non sarà perfetto, ha tutti i limiti che si riscontrano nel passaggio da un PDF a un file di testo puro (per esempio se cambia un'immagine non se ne accorge e la buona riuscita del confronto dipende da quanto bene pdftotext riesce a leggere i documenti) ma è abbastanza veloce e ho trovato questo sistema spesso molto utile.

Ho scritto anche il corrispondente script Nautilus (utilizza zenity):
#!/bin/bash

titolo="Confronto PDF"

function converti() {
    txt=$(eval "expr \$"$1" ")
    pdf=$(eval "expr \$"$2" ")
    while [ -f "$txt" ]; do
        if ! zenity --question --title="$titolo" --text="Il file $txt esiste già, sovrascriverlo?"; then
            txt=$(zenity --entry  --title="$titolo" --text="Specifica un file di output differente: ")
        else
            break 2
        fi
    done
    pdftotext "$pdf" "$txt"
    case $? in
        0)
            ;;
        1)
            zenity --error  --title="$titolo" --text="Si è verificato un errore nell'apertura di $pdf."
            exit 1
            ;;
        2)
            zenity --error  --title="$titolo" --text="Si è verificato un errore nell'apertura di $txt."
            exit 1
            ;;
        3)
            zenity --error  --title="$titolo" --text="Si è verificato un errore collegato ai permessi di $pdf."
            exit 1
            ;;
        *)
            zenity --error  --title="$titolo" --text="Si è verificato un errore!"
            exit 1
    esac
    eval "$1=$txt"
}

if [ $# -ne 2 ]; then
    zenity --error --title="$titolo" --text="Devi selezionare due file alla volta"
    exit 1
fi
pdf1=$1
pdf2=$2
txt1=$(dirname "$pdf1")/$(basename "$pdf1" .pdf).txt
txt2=$(dirname "$pdf1")/$(basename "$pdf2" .pdf).txt
converti txt1 pdf1 && converti txt2 pdf2
if [ $? -eq 0 ]; then
    diff -u "$txt1" "$txt2" | zenity --text-info  --title="$titolo" --filename=/dev/stdin
    rm -f "$txt1" "$txt2"
else # non dovrebbe arrivare mai qui, metto per sicurezza
    zenity --error  --title="$titolo" --text="Si è verificato un errore!"
    exit 1
fi
exit 0
Per utilizzare questo secondo script aprite un file vuoto con un editor di testo, copiate lo script nell'editor e salvatelo nella cartella ~/.gnome2/nautilus-scripts chiamandolo, per esempio, "Confronta PDF". Rendete quindi eseguibile lo script. Così potrete selezionare due file PDF da confrontare e, facendo clic con il tasto destro, scegliete ScriptConfronta PDF (o il nome che avete dato allo script).

Dal punto di vista tecnico, gli script presentano un aspetto un po' particolare: la funzione converti (che serve per convertire il pdf in testo ed eseguire i controlli del caso) presenta una sorta di passaggio di variabile per riferimento e non per valore. Il "trucco" sta nel passare alla funzione non il valore della variabile ma il suo nome (chi ha familiarità con altri linguaggi di programmazione potrebbe trovare ciò naturale). I dettagli possono essere visti qui: http://www.pluto.it/files/ildp/guide/abs/functions.html#DEREFERENCECL.

sabato 23 ottobre 2010

Importare in Gmail la posta inviata di un altro account

Questa volta parlerò di un problema non legato al sistema operativo GNU/Linux, però è un problema che mi ha tenuto impegnato per un po' e voglio spiegare il barbatrucco con cui l'ho risolto: importare in Gmail la posta inviata di un altro account.

In Gmail è possibile importare le email ricevute da un qualsiasi altro account di posta elettronico nel proprio account su Gmail. Se si vuole è possibile anche continuare a scaricare automaticamente la posta da altri account (al massimo 5) con la funzione chiamata Mail Fetcher. Purtroppo né l'importazione manuale della posta né Mail Fetcher importano anche le email inviate dagli altri account, come spiegato nella sezione di Risoluzione dei problemi della guida. È vero che non è possibile farlo automaticamente, ma con qualche giro sono riuscito nel mio intento. Per fare ciò ho dovuto dare un'occhiata all'organizzazione della posta su Gmail. Il barbatrucco funziona pienamente se l'account da cui si vogliono importare le email verrà aggiunto ai mittenti personalizzati.

Le mail (che normalmente sono raccolte per conversazioni, se non vi piace questa visualizzazione potete disattivarla da Impostazioni e nella scheda Generali selezionate Visualizzazione per conversazione disattivata) non sono suddivise in cartelle ma hanno delle "etichette" che vengono loro attribuite. L'uso è praticamente lo stesso, la differenza è che a una mail possono essere attribuite più etichette, è come se si trovasse in più cartelle contemporaneamente. Tutte le mail si trovano nello spazio chiamato Tutti i messaggi (il collegamento sta nella barra sulla sinistra, se non la vede premete Altre), non vengono però visualizzate le email eliminate (le quali hanno l'etichetta Cestino) e quelle segnate come spam (che hanno l'etichetta Spam). (quasi) Tutti i "gruppi" che vediamo sulla sinistra non fanno altro che raccogliere le email secondo le etichette che le sono state attribuite. Così, le email posizionate in Posta in arrivo sono semplicemente delle mail che hanno l'etichetta Posta in arrivo (per quanto possa sembrare strano, una email inviata può trovarsi in Posta in arrivo: basta che abbia la corrispondente etichetta), le eventuali email presenti in Personale, Lavoro, ecc. hanno le rispettive etichette e, come detto, una mail può anche avere più etichette contemporaneamente (e quindi comparirà in tutti i rispettivi "gruppi"). Invece le mail presenti in Posta inviata hanno come caratteristica di avere come mittente l'account in uso o uno dei mittenti personalizzati.

Vi starete chiedendo: cosa c'entra tutto questo discorso con l'importazione delle email inviate? Calma, arriviamo subito alla soluzione del problema facendo un breve riepilogo di quello che abbiamo appreso. Sappiamo che Gmail può importare dagli altri account la posta arrivata, ma non quella inviata, allora potremmo pensare di spostare nel precedente account le email inviate nella cartella di Posta in arrivo (in genere questa è una operazione possibile, naturalmente non posso spiegare i dettagli perché variano da provider a provider), ma questa operazione crea l'inconveniente che importando la posta nell'account Gmail le email inviate avranno l'etichetta Posta in arrivo e quindi si troveranno in quel gruppo (a meno che nella fase di importazione non si sia selezionata l'opzione Archivia messaggi in arrivo (Ignora Posta in arrivo)). Sappiamo però anche che per togliere una mail dalla Posta in arrivo basta rimuovere la corrispondente etichetta, niente di più semplice! Ho già specificato che il barbatrucco funziona se l'indirizzo da cui stiamo importando la posta è uno dei mittenti personalizzati, quindi le email si troveranno già automaticamente in Posta inviata, altrimenti non compariranno in questa "cartella" ma solo in Tutti i messaggi (e se questa eventualità non è un problema allora non diventa neanche necessario che l'account da cui si importa sia fra i mittenti personalizzati).

Per non dover rimuovere manualmente le etichette a ciascun messaggio inviato consiglio di suddividere l'operazione di importazione in due punti:
1) importare normalmente nell'account Gmail tutta la posta arrivata al precedente account;
2) dopo aver concluso questa operazione, spostare (nel vecchio account) le email inviate nella cartella ed eseguire nuovamente lo scaricamento in Gmail (tranquilli, le email già importate non saranno scaricate nuovamente) selezionando l'opzione Archivia messaggi in arrivo (Ignora Posta in arrivo). In questo modo, come spiegato già abbastanza bene dal nome dell'opzione, le nuove email che saranno scaricate (nella speranza che ci siano solo le email inviate e non compaia qualche nuova mail :-D ) verranno archiviate, cioè non sarà aggiunta l'etichetta Posta in arrivo.

Nel vecchio account da cui avete importato le email potete ora fare quello che vi pare: riportare le email inviate nella cartella di posta inviata, cancellarle, ecc. Ovviamente è possibile selezionare l'opzione Archivia messaggi in arrivo (Ignora Posta in arrivo) già nell'importazione di tutte le mail ricevute, in questo caso non si rende neanche necessaria una doppia importazione, si possono importare tutte insieme email ricevute e inviate (naturalmente dopo aver spostato queste ultime nella cartella di posta ricevuta). Se si utilizza Mail Fetcher, dopo aver effettuato l'importazione dei messaggi inviati potreste voler togliere l'opzione Archivia messaggi in arrivo: ricordatevi di farlo, altrimenti le nuove mail ricevute sul vecchio account non passeranno da Posta in arrivo!

Questo è il barbatrucco che ho escogitato io, non escludo che esista qualche metodo più semplice, in questo caso sarei felice di conoscerlo! :-)

venerdì 22 ottobre 2010

Opzioni utili per comporre documenti LaTeX in GNU Emacs + AUCTeX

GNU Emacs, come ho già avuto modo di dire, è un potente editor di testo che permette di fare di tutto e di più. Esistono numerose funzioni che permettono di facilitare la scrittura di codici in numerosi linguaggi di programmazioni, compreso, ovviamente LaTeX (anche se in questo caso il nome "linguaggio di programmazione" non è del tutto adeguato). Uno dei tanti motivi per cui Emacs è molto apprezzato è la sua possibilità di personalizzazione ed espansione: esistono centinaia di estensioni che aumentano notevolmente le potenzialità di questo editor di testo oltre le funzioni fornite nativamente. Esiste (ovviamente) una estensione anche per LaTeX: AUCTeX (ma è utile anche per ConTeXt, docTeX, Texinfo e TeX puro: molte delle impostazioni che vedremo varranno per tutti questi linguaggi, anche se mi riferirò generalmente solo a LaTeX).

Non è mia intenzione spiegare qui come si installa Emacs né tanto meno AUCTeX (anche perché questi pacchetti sono forniti dalla maggior parte delle distribuzioni GNU/Linux, l'installazione è quindi molto semplice se si conosce il funzionamento del proprio gestore pacchetti), ma piuttosto illustrare quali sono le opzioni di AUCTeX (e qualcuna propria di Emacs) che ho trovato personalmente utili. Darò per scontato che si abbia un minimo di familiarità con Emacs, con la notazione delle scorciatoie e dei comandi e anche con AUCTeX (qualche volta però ricorderò come eseguire alcune operazioni). Prima di iniziare ricordo che si può consultare il manuale (in inglese) di AUCTeX all'indirizzo http://www.gnu.org/software/auctex/manual/auctex.html oppure direttamente dentro Emacs con C-h i d m AUCTeX RET. Per la modifica di buona parte delle opzioni seguenti AUCTeX dovrà essere già caricato. Non sono un grande esperto di Emacs, potrei dire a volte delle sciocchezze, spero che mi perdoniate e sono graditi consigli (a ogni modo vi posso assicurare che seguendo questa guida non vi scoppierà il pc :-D).

In AUCTeX è possibile eseguire varie operazioni come compilazione, esecuzione di bibtex, esecuzione di makeindex, cancellazione dei file temporanei, ecc... usando C-c C-c (seguito dal comando che si desidera usare). La cancellazione dei file temporanei viene eseguita usando l'elenco delle estensioni dei file salvato nella variabile LaTeX-clean-intermediate-suffixes. Per modificare questa variabile (come tutte le variabili di Emacs, naturalmente sostituendo il nome dove opportuno) si può usare il comando (ricordo che i comandi possono essere inseriti con M-x, dove M è il cosiddetto tasto Meta e può essere ottenuto con l'ALT, oppure, se non è presente tale tasto, con ESC (rilasciare ESC dopo averlo premuto)):
customize-variable RET LaTeX-clean-intermediate-suffixes RET
Per aggiungere nuove estensioni selezionare INS e inserire di fianco a Regexp: l'espressione regolare (per maggiori informazioni sulle espressioni regolari in Emacs si può consultare il manuale di Elisp in Emacs oppure vedere qui) corrispondente all'estensione che si vuole aggiungere. Per esempio io ho aggiunto le estensioni .tex~ (i file di backup creati da Emacs) e .run.xml (file usati per creare la bibliografia con il pacchetto biblatex) con le seguenti espressioni regolari:
\.tex~
\.run\.xml
Per rendere definitiva la modifica selezionare Save for future sessions (bisognerà fare lo stesso ogni volta che si usa customize-variable).

Emacs si preoccupa anche di indentare correttamente il codice, compresi i vari ambienti. Si può in particolare impostare l'editor in modo che quando viene premuto il tasto di Invio (o, nella notazione di Emacs, RET) il cursore si porti, nel rigo successivo, nella giusta posizione richiesta da una corretta indentazione. Per fare ciò bisogna modificare la variabile TeX-newline-function con il comando:
customize-variable RET TeX-newline-function RET
Selezionare Value Menu e scegliere newline-and-indent. È possibile anche modificare il comportamento di Emacs nell'indentazione all'interno di determinati ambienti modificando la variabile LaTeX-indent-environment-list, sempre con il comando:
customize-variable RET LaTeX-indent-environment-list RET
Io, per esempio, ho aggiunto l'ambiente lstlisting per fare in modo che Emacs non aggiungesse automaticamente il rientro per il testo inserito in questo ambiente. Per fare ciò ho selezionato INS, scritto lstlisting di fianco a Environment: e dopo aver messo la spunta a Function: ho scritto nel relativo spazio current-indentation (proprio come risulta di default per l'ambiente verbatim).

Emacs permette anche l'evidenziazione della sintassi di LaTeX, ma in alcuni (rari) casi può andare in difficoltà. Per esempio ho avuto problemi con il già citato ambiente lstlisting in quanto AUCTeX 11.86 non conosce bene il suo funzionamento (per esempio l'inserimento del simbolo del dollaro $ rovina tutta l'evidenziazione del documento). Per fortuna è possibile spiegargli che lo deve trattare allo stesso modo dell'ambiente verbatim (in pratica tutto ciò che si trova all'interno di questo ambiente non viene interpretato da Emacs per quanto riguarda l'evidenziazione della sintassi) modificando la variabile LaTeX-verbatim-environments:
customize-variable RET LaTeX-verbatim-environments RET
aggiungete lstlisting (penso che ormai avrete capito come funziona questo tipo di interfaccia di modifica delle variabili) e il gioco è fatto.

In maniera predefinita Emacs compila i documenti in formato DVI. Se invece si vuole impostare in maniera predefinita il formato PDF bisogna modificare il valore della variabile TeX-PDF-mode:
customize-variable RET TeX-PDF-mode RET
Selezionare Toggle fino ad arrivare a on (non-nil).

Se si è installata una distribuzione di LaTeX in un percorso non riconosciuto immediatamente da Emacs e AUCTeX bisognerà modificare alcune variabili. Per esempio, io ho installato TeX Live 2010 seguendo questa guida di Enrico Gregorio e tutti i file di LaTeX si trovano in sottocartelle di /usr/local/texlive/2010/ (in cui Emacs e AUCTeX normalmente non cercano). Fra le variabili che potrebbero dover essere cambiate ci sono TeX-macro-global (contiene, ricorsivamente, le cartelle in cui AUCTeX cercherà i file di stile) e exec-path (contiene i percorsi in cui Emacs cerca i programmi da eseguire). La modifica di queste variabili è simile a quanto visto finora. Per la prima variabile ho aggiunto il percorso /usr/local/texlive/2010/texmf-dist/tex/, mentre per exec-path ho aggiunto /usr/local/texlive/2010/bin/i386-linux/ (su architetture diverse dal 32 bit questo percorso sarà sicuramente diverso. Controllate per bene la posizione in cui avete installato la distribuzione).

Per modificare il programma con cui viene aperto il documento di output (sia esso in formato DVI, PDF, HTML, ecc) tramite C-c C-c View RET bisogna modificare la variabile TeX-view-program-selection. Come al solito per personalizzare la variabile si può usare
customize-variable RET TeX-view-program-selection RET
Le impostazioni viste finora vengono salvate automaticamente da Emacs nel file di inizializzazione ~/.emacs (ricordo che la tilde ~ è un'abbreviazione del percorso della propria cartella home, mentre i file che hanno il nome che inizia con un punto sono nascosti). Tutte queste impostazioni possono essere anche memorizzate modificando manualmente il file .emacs (per poter fare ciò autonomamente bisogna però conoscere il linguaggio Emacs Lisp). Vediamo ora qualche altra utile opzione che imposteremo modificando direttamente il file .emacs (queste comunque possono sempre essere impostate anche utilizzando l'interfaccia di customize-variable).

Il manuale di AUCTeX suggerisce di aggiungere a .emacs le seguenti linee:
(setq TeX-auto-save t)
(setq TeX-parse-self t)
in modo che ottenere supporto per i pacchetti LaTeX che vengono usati nei propri documenti (l'opzione TeX-parse-self fa effettuare a Emacs il parsing del documento e le informazioni verranno raccolte in una sottocartella della directory del documento modificato chiamata auto/. Se non si desidera affollamento nelle proprie cartelle si potrebbe non voler attivare queste due opzioni).

Se si usa frequentemente suddividere i propri documenti LaTeX in più parti da includere nel file principale con i comandi \input o \include può essere utile aggiungere al file .emacs l'opzione
(setq-default TeX-master nil)
In questo modo, all'apertura dei documenti LaTeX Emacs chiederà qual è il file principale associato (su cui dovrà, per esempio, eseguire i comandi di compilazione).

Si può far in modo che all'apertura di un documento LaTeX Emacs esegua il controllo ortografico al volo aggiungendo a .emacs l'opzione
(add-hook 'TeX-mode-hook 'flyspell-mode)
Inoltre, se si usa spesso LaTeX per comporre documenti matematici potrebbe essere utile aggiungere l'opzione
(add-hook 'TeX-mode-hook 'LaTeX-math-mode)
che permette il rapido inserimento di numerosi simboli matematici (vedi manuale). Infine, per fare in modo che il cursore vada a capo dopo l'inserimento di un numero prefissato di caratteri per rigo (ovviamene Emacs è intelligente, non spezza una parola in due, va a capo in modo che il rigo risulti lungo al massimo il numero prefissato di caratteri) si può aggiungere l'opzione
(add-hook 'TeX-mode-hook 'turn-on-auto-fill)
Il numero di caratteri per rigo dopo il quale Emacs dovrà andare a capo è salvato nella variabile fill-column. Lascio per esercizio scoprire come si modifica tale variabile (ok, lascio un indizio: si può usare sempre il solito comando :-D).

Per effettuare un controllo della sintassi al volo si può inserire questo codice nel file di inizializzazione:
(require 'flymake)
(defun flymake-get-tex-args (file-name)
  (list "chktex" (list "-q" "-v0" file-name)))
(add-hook 'LaTeX-mode-hook 'flymake-mode) 
I dettagli di questa istruzioni e sue alternative sono illustrati nel post Emacs: effettuare il controllo della sintassi di documenti LaTeX.

sabato 9 ottobre 2010

Ipe: An error occurred during the Pdflatex run. There was an error reading the Pdflatex output [Risolto]

Se avete installato la distribuzione TeX Live 2010 e usate il programma di grafica Ipe per creare disegni, andando a compilare un'immagine potreste ricevere la seguente finestra di errore:
An error occurred during the Pdflatex run

There was an error reading the Pdflatex output



La soluzione a questo problema si trova(va) qui: http://http.typke.com/cgi-bin/bugzilla3/show_bug.cgi?id=350 e consiste nell'aggiungere al preambolo dell'immagine il comando \pdfobjcompresslevel0. Ricordo che il preambolo di un'immagine Ipe può essere modificato da EditDocument properties (oppure con la scorciatoia da tastiera CTRL + Shift + P), scrivendo nel campo Latex preamble.

Git4LaTeX: una guida introduttiva a Git per progetti LaTeX


Nota: la guida è stata aggiornata dopo la prima pubblicazione.

Chi scrive documenti con LaTeX potrebbe a un certo punto avere il bisogno di controllare lo sviluppo dei vari documenti, in modo da controllare i cambiamenti effettuati tra un salvataggio e l'altro per poter, eventualmente, anche individuare quando sono stati introdotti degli errori e poter in pochi passi ripristinare una versione precedente. In vostro soccorso arriva allora Git, programma di controllo versione. L'uso tipico di Git è quello di tenere traccia dello sviluppo di un software, ma svolge ugualmente bene il suo lavoro con i documenti LaTeX.

Proprio per spiegare come utilizzare insieme Git e LaTeX, il GuIt (Gruppo utenti Italiani di TeX) ha pubblicato una guida tematica, con licenza CC-BY-NC-SA 2.5 Italy, sull'uso di Git per gestire lo sviluppo di un documento scritto in LaTeX. La guida non si prefigge grandi scopi, non diventerete degli esperti di Git leggendola, ma è sicuramente d'aiuto per riuscire a usare insieme questi due utili strumenti.

Trovate il codice sorgente della guida su GitHub all'indirizzo https://github.com/GuITeX/guidagit e potete scaricare il documento PDF all'indirizzo http://www.guitex.org/home/images/doc/GuideGuIT/guidagit.pdf. Se avete Git sul vostro sistema potete potete clonare il repository con il comando
git clone https://github.com/GuITeX/guidagit.git
Infine il codice sorgente può essere scaricato anche in un archivio compresso all'indirizzo https://github.com/GuITeX/guidagit/archive/master.tar.gz.

Qualsiasi critica (costruttiva), segnalazione di imprecisione o richiesta di chiarimento è ben gradita!

Happy TeXing :-)

lunedì 20 settembre 2010

Compilare gnuplot 4.4 con il supporto per il terminale Lua/TikZ

Da qualche tempo è uscita la versione 4.4 gnuplot. Gli utenti di Debian Sid/Squeeze possono installarla normalmente con il gestore pacchetti, gli utenti di Ubuntu Lucid Lynx possono scaricare i pacchetti deb dagli archivi di Debian: http://packages.debian.org/sid/gnuplot. Questa versione di gnuplot introduce inoltre il supporto nativo al terminale Lua/TikZ, utile per l'inserimento di grafici in documenti LaTeX (ricordo che comunque è presente anche il terminale epslatex per fare ciò). Il pacchetto presente in Debian Sid, però, al momento non supporta questo terminale quindi la compilazione del programma a partire dal sorgente è una delle strade possibili per poterlo utilizzare.

Ovviamente per compilare il programma la prima cosa da fare è procurarsi il codice sorgente. Questo può essere trovato qui. Come secondo passo bisogna installare le dipendenze per la compilazione. Un elenco delle librerie da installare può essere trovata qui (nelle altre distribuzioni i nomi potrebbero differire leggermente): http://packages.debian.org/source/sid/gnuplot. Nei sistemi che utilizzano APT (come Debian e Ubuntu) e in cui il sorgente di gnuplot è presente nei repository è possibile installare tutte queste dipendenze con il comando
sudo apt-get build-dep gnuplot
Per poter utilizzare il terminale Lua/TikZ è però necessario installare inoltre l'interprete Lua e le librerie necessarie per la compilazione. In Debian e Ubuntu è sufficiente installare il pacchetto liblua5.1-0-dev. Prima di continuare bisogna creare un link simbolico:
sudo ln -s /usr/lib/pkgconfig/lua5.1.pc /usr/lib/pkgconfig/lua.pc
Senza questa operazione non verrebbe individuata la presenza di Lua in fase di compilazione di gnuplot.

A questo punto bisogna scompattare l'archivio compresso appena scaricato e spostarsi con il terminale nella cartella in cui ora si trova il sorgente. Per compilare il programma, con il supporto al terminale Lua/TikZ bisogna dare i comandi
./configure --with-lua
make
sudo make install

Dopo l'esecuzione dello script configure controllate che lo script Lua sia presente fra quelli che verranno compilati. Al posto del comando sudo make install potete usare
sudo checkinstall
dopo aver installato il pacchetto checkinstall, che creerà un pacchetto deb per una più semplice rimozione e installazione del programma.

Creare un metapacchetto deb con equivs

Seguite queste istruzioni a vostro rischio e pericolo, non assicuro che non possano creare qualche dipendenza rotta.

In APT (il sistema che gestisce i pacchetti di Debian, Ubuntu e compagnia) i metapacchetti (o dummy packages, pacchetti silenziosi) sono dei pacchetti che non forniscono un vero e proprio software ma che permettono di installare come dipendenze altri programmi. È, per esempio, un metapacchetto ubuntu-desktop: in sé non installa nessun programma, ma fa installare come dipendenze tutti i programmi presenti di default nella versione desktop di Ubuntu.

È possibile creare (in Debian e Ubuntu) dei metapacchetti con il programma equivs. Si installa normalmente da repository. Come al solito si può scegliere la via grafica installando con Synaptic il pacchetto equivs, oppure da terminale con il comando
sudo apt-get install equivs
equivs, che funziona da terminale, fornisce due comandi: equivs-control ed equivs-build. Il primo genera il file di configurazione del metapacchetto che si vorrà creare:
equivs-control nomepacchetto
creerà un file chiamato nomepacchetto (ovviamente sostituirete a nomepacchetto il nome del metapacchetto che vi interessa creare). Il file deve essere modificato con un qualsiasi editor di testo affinché contenga le impostazioni desiderate. Le opzioni che devono essere necessariamente presenti sono Package, Description e Depends. Ricordarsi di rimuovere il cancelletto (decommentare) davanti a tutte le opzioni modificate.

Con
equivs-build nomepacchetto
(nomepacchetto deve essere il nome del file creato con il comando precedente) si costruisce nella stesa cartella il pacchetto deb sulla base delle informazioni contenute nel file appena impostato che potrà essere installato facendoci doppio clic sopra oppure ancora da terminale con il comando
sudo dpkg -i nomepacchetto.deb
(il nome però non sarà semplicemente nomepacchetto.deb ma conterrà il numero della versione e l'architettura impostate, usate l'autocompletamento con il tasto TAB per sapere qual è il nome, oppure semplicemente controllatelo aprendo la cartella).

Un dei possibili usi dei metapacchetti è quello di poter installare con un solo doppio clic numerosi programmi (inserendoli come dipendenze del metapacchetto creato), oppure far credere al sistema APT che sia installato un determinato programma quando lo si è installato in maniera diversa (per esempio attraverso la compilazione del codice sorgente).

In questi giorni ho installato la distribuzione TeX Live 2010 dal sito e voglio che APT veda tutti i pacchetti relativi a TeX Live siano installati (perché la distribuzione è installata all'esterno del gestore pacchetti APT, ma lui non è a conoscenza di ciò ovviamente), in modo da poter installare altri programmi dipendenti da questi pacchetti. Per fare ciò ho creato il file texlive con il seguente contenuto:
Section: tex
Package: texlive-dummy
Version: 2011
Homepage: http://tug.org/texlive/
Standards-Version: 3.9.2
Provides: asymptote, asymptote-doc, biblatex, biblatex-dw, cm-super, context, dblatex, dvipdfmx, dvipng, feynmf, fragmaster, guile-1.8, jadetex, lacheck, latex2html, latex-beamer, latex-cjk-all, latexmk, latex-xcolor, lcdf-typetools, libsigsegv0, lilypond, lilypond-data, lilypond-doc, lmodern, luatex, passivetex, pgf, preview-latex-style, prosper, ps2eps, psutils, t1utils, tex4ht, tex4ht-common, tex-common, texlive, texlive-base, texlive-base-bin, texlive-base-bin-doc, texlive-bibtex-extra, texlive-binaries, texlive-common, texlive-doc-base, texlive-doc-bg, texlive-doc-cs+sk, texlive-doc-de, texlive-doc-en, texlive-doc-es, texlive-doc-fi, texlive-doc-fr, texlive-doc-it, texlive-doc-ja, texlive-doc-ko, texlive-doc-mn, texlive-doc-nl, texlive-doc-pl, texlive-doc-pt, texlive-doc-ru, texlive-doc-si, texlive-doc-th, texlive-doc-tr, texlive-doc-uk, texlive-doc-vi, texlive-doc-zh, texlive-extra-utils, texlive-fonts-extra, texlive-fonts-extra-doc, texlive-fonts-recommended, texlive-fonts-recommended-doc, texlive-font-utils, texlive-formats-extra, texlive-games, texlive-generic-extra, texlive-generic-recommended, texlive-humanities, texlive-humanities-doc, texlive-lang-african, texlive-lang-arabic, texlive-lang-armenian, texlive-lang-croatian, texlive-lang-cyrillic, texlive-lang-czechslovak, texlive-lang-danish, texlive-lang-dutch, texlive-lang-finnish, texlive-lang-french, texlive-lang-german, texlive-lang-greek, texlive-lang-hebrew, texlive-lang-hungarian, texlive-lang-indic, texlive-lang-italian, texlive-lang-latin, texlive-lang-latvian, texlive-lang-lithuanian, texlive-lang-mongolian, texlive-lang-norwegian, texlive-lang-other, texlive-lang-polish, texlive-lang-portuguese, texlive-lang-spanish, texlive-lang-swedish, texlive-lang-tibetan, texlive-lang-ukenglish, texlive-lang-vietnamese, texlive-latex3, texlive-latex-base, texlive-latex-base-doc, texlive-latex-extra, texlive-latex-extra-doc, texlive-latex-recommended, texlive-latex-recommended-doc, texlive-luatex, texlive-math-extra, texlive-metapost, texlive-metapost-doc, texlive-music, texlive-omega, texlive-pictures, texlive-pictures-doc, texlive-plain-extra, texlive-pstricks, texlive-pstricks-doc, texlive-publishers, texlive-publishers-doc, texlive-science, texlive-science-doc, texlive-xetex, tipa, xmltex
Architecture: all
Description: texlive dummy package
Quelli elencati in Provides sono i pacchetti della distribuzione TeX Live che ho trovato o che comunque avevo bisogno di far finta che fossero installati, ne esistono molti altri non presenti in questo elenco. Con il comando
equivs-build texlive
ho generato il pacchetto deb che ho potuto installare con un doppio clic.

Come suggerito nella documentazione (in particolare nel manuale di equivs-build), se riscontrate qualche caso in cui il sistema delle dipendenze dei pacchetti dovrebbe essere migliorato, non usate equivs ma piuttosto segnalate agli sviluppatori il problema.

Qui trovate altre informazioni sulla gestione dei metapacchetti: http://guide.debianizzati.org/index.php/Gestione_dei_metapacchetti.

martedì 27 luglio 2010

Touchpad non funzionante in Ubuntu Lucid Lynx [Risolto]

Nella versione 10.04 di Ubuntu (nome in codice Lucid Lynx, ma ho ricevuto segnalazioni di questo problema anche nelle versioni successive) può capitare che dopo l'avvio della sessione il mouse smetta di funzionare. Il problema è stato segnalato su Launchpad, intanto esistono un paio di risoluzioni.

La prima è un semplice workaround per aggirare momentaneamente il problema quando si presenta: entrare in una console con i tasti ALT + CTRL + F1 e poi, senza fare altro, tornare nella shell grafica con la combinazione ALT + CTRL + F7.

Un'altra soluzione che dovrebbe invece essere definitiva (ma che personalmente non ho testato, però più di qualcuno conferma essere funzionante) è dare questo comando nel terminale:
gconftool --type bool --set /desktop/gnome/peripherals/touchpad/touchpad_enabled true
Ho trovato questa seconda soluzione qui: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/549727/comments/103

domenica 18 luglio 2010

Come si installa un .tar.gz?


Una domanda abbastanza frequente sul forum della comunità italiana di Ubuntu è su come installare un .tar.gz (o anche un .tar.bz2 e compagnia bella). La risposta è semplice:
la domanda non ha senso.

Un .tar.gz (o un .tar.bz2) è un insieme di file archiviati con tar e compresso con gzip (o bzip2 nel caso dei .tar.bz, negli altri formati cambierà il tipo di compressione), ma dentro può esserci qualsiasi cosa (binari precompilati, sorgenti da compilare a mano, programma in python che non va compilato, temi per il desktop, chi più ne ha più ne metta) ed è per questo motivo che non ha senso chiedere come si installi. In generale non si può dire niente su cosa si debba fare con un archivio senza sapere cosa ci sia dentro. È come chiedere «come si apre un file?» senza dire di che file si tratti.

Esempio famoso: Mozilla distribuisce sul suo sito Firefox e Thunderbird (e altri programmi) per sistemi GNU/Linux in archivi .tar.bz2 che contengono dentro i programmi già compilati e pronti per l'uso (una cosa che molta gente sembra non capire, nonostante gli venga detto, è che non c'è bisogno di compilare proprio niente in questo caso). Qui non c'è nulla da installare, per avviare i due programmi basterà scompattare l'archivio (e per favore, se non siete in grado (come me) di farlo da terminale, scompattate attraverso interfaccia grafica, non capisco perché la gente si ammazzi a scompattare da linea di comando quando bastano due clic) e fare doppio clic sul file firefox o thunderbird, a seconda del programma.

Allora la domanda sorgente spontanea: come faccio a capire cosa me ne devo fare di questo archivio? Anche qui la risposta è semplice: aprirlo. Nella stragrande maggioranza dei casi è presente un file chimato README che contiene le istruzioni (purtroppo praticamente sempre in inglese) sul da farsi (estrarre l'archivio e compilare, oppure estrarre e fare doppio clic su un file o altro).

Nel caso in cui l'archivio contenga il sorgente di un programma da compilare è spesso presente anche un altro file chiamato INSTALL che spiega più dettagliatamente come si compila il programma, anche se spesso sono sufficienti i "comandi magici":
./configure
make
# make install

È bene comunque controllare sempre le istruzioni per la compilazione e non partire in quarta con questi comandi, ci sono tantissimi programmi che non devono essere compilati in questo modo.

Concludendo, se avete scaricato un .tar.gz/.bz2/.lzma/ecc. e volete chiedere aiuto su un forum & Co. è sensato porre la domanda «Ho scaricato il programma xyz [magari fornendo anche link al sito da cui si è scaricato l'archivio], come faccio a utilizzarlo?» ma non «Ho scaricato un .tar.gz [senza fornire alcuna indicazione su quale programma si tratti...], come si installa?» perché, come mi sembra di aver già detto,
la domanda non ha senso.

martedì 18 maggio 2010

Aprire file system di Wubi da Live CD

Se avete fatto la sciagurata scelta di installare Ubuntu tramite Wubi e avete incontrato dei problemi che impediscono l'avvio del sistema, potete ancora accedere alla "partizione" di Wubi (anche se il nome "partizione" non è del tutto corretto) usando un Live CD (va bene di qualsiasi distribuzione). Dopo aver avviato il sistema da cd bisogna aprire un terminale, montare la partizione di Windows in cui è installato Wubi (la posizione, in Windows, del file system di Ubuntu dovrebbe essere il file C:\ubuntu\disk\root.disk, o simile). La partizione di Windows può essere anche normalmente montata per via grafica, se possibile (per esempio con GNOME è sufficiente fare clic, in Nautilus, sul nome della partizione desiderata). A questo punto, dare nel terminale i seguenti comandi:
sudo mkdir /vdisk
sudo mount -o loop /media/WINDOWS/ubuntu/disks/root.disk /vdisk

Il primo serve per creare nel sistema live la cartella /vdisk (è comunque possibile dare un percorso e nome arbitrario alla cartella), il secondo per montare il file system di Wubi e usare come punto di montaggio la cartella appena creata. Il penultimo argomento del comando mount è il percorso del file system di Wubi, da adattare al proprio caso: in genere le partizioni si montano nella cartella /media (e così fa in modo predefinito Nautilus, ma è possibile montare in un punto diverso, come infatti faremo) e poi ho scritto WINDOWS che sta a indicare il nome dell'etichetta della partizione (molto probabilmente non sarà questa l'etichetta della partizione, controllate per bene qual è il nome). Per vedere l'elenco delle partizioni montate e relativo punto di montaggio si può dare semplicemente il comando
mount
senza altri argomenti. Il resto del percorso (ubuntu/disk/root.disk) dovrebbe essere corretto (come detto prima, questo è il percorso in cui si dovrebbe trovare il file in Windows). L'autocompletamento nel terminale potrebbe aiutarvi a inserire il percorso corretto.

A questo punto è possibile aprire normalmente il file system di Wubi come una normale partizione montata. Attenti a non fare ulteriori danni all'installazione di Ubuntu, la state già facendo soffrire abbastanza usando Wubi ^^

Avvertenza: se nell'installazione di Wubi si è scelto il file system ext4, per potervi accedere ci sarà bisogno di un Live CD che riconosca questo recente file system. Per esempio, usando Ubuntu ci sarà bisogno del cd della versione 9.04 o successiva.

Questa guida è stata ripresa da https://wiki.ubuntu.com/WubiGuide.

lunedì 5 aprile 2010

Autocompletamento in Emacs (2)

Nota: questo post spiega come installare la nuova versione (1.2) dell'estensione auto-complete per Emacs. Le istruzioni per installare la vecchia versione (1.0) si trovano nel post Autocompletamento in Emacs.

In passato avevo spiegato come installare la versione 1.0 dell'estensione auto-complete per l'editor di testo GNU Emacs. Nel frattempo lo sviluppo dell'estensione è andato avanti e ora il programma fornisce delle nuove funzioni che si possono leggere qui. Ora vediamo come installare questa nuova versione (queste istruzioni sono riprese da qui, in lingua inglese).

Per prima cosa è ovviamente necessario scaricare l'estensione. L'ultima versione stabile può essere ottenuta all'indirizzo http://cx4a.org/software/auto-complete/#Latest_Stable (è possibile anche installare una versione di sviluppo da git, ma non spiegherò come farlo in questo post). Nel momento in cui scrivo l'ultima versione stabile è la 1.2 e l'archivio da scaricare si trova all'indirizzo http://cx4a.org/pub/auto-complete/auto-complete-1.2.tar.bz2 (è indifferente scaricare l'archivio .zip o .tar.bz2). Scompattiamo l'archivio e ci spostiamo nel terminale con il comando cd nella cartella appena scompattata. Se per esempio abbiamo scompattato l'archivio in ~/Scrivania (ricordo che la tilde ~ è un'abbreviazione del percorso della home dell'utente corrente) ci dovremo spostare nella cartella ~/Scrivania/auto-complete-1.2 (nelle versioni successive alla 1.2 la cartella cambierà presumibilmente il nome) con il comando
cd ~/Scrivania/auto-complete-1.2
Per installare il l'estensione è sufficiente dare il comando
emacs -batch -l etc/install.el
Alla richiesta
Install to:
dobbiamo inserire il percorso della cartella in cui installare l'estensione. In genere queste estensioni vengono installate in ~/.emacs.d, quindi in questo caso dobbiamo solo scrivere
~/.emacs.d
A questo punto, se l'installazione è andata a buon fine leggeremo il messaggio
Successfully installed!

Add the following code to your .emacs:

(add-to-list 'load-path "~/.emacs.d")
(require 'auto-complete-config)
(add-to-list 'ac-dictionary-directories "~/.emacs.d/ac-dict")
(ac-config-default)

Per poter utilizzare questa estensione dobbiamo infine fare ciò che ci viene detto: aggiungere le stringhe sopraelencate al file ~/.emacs. Per fare ciò apriamo il file suddetto (ricordo che i file e le cartelle che hanno il nome che inizia con il punto sono nascosti) con il nostro editor di testo preferito (per esempio Emacs :D) e aggiungiamo alla fine le stringhe
(add-to-list 'load-path "~/.emacs.d")
(require 'auto-complete-config)
(add-to-list 'ac-dictionary-directories "~/.emacs.d/ac-dict")
(ac-config-default)

La prima serve per aggiungere la cartella ~/.emacs.d alla variabile load-path, che contiene l'elenco delle cartelle in cui vengono cercati i file da caricare. Se la variabile contiene già questa cartella non sarà necessario aggiungerla nuovamente (in Emacs si può vedere il contenuto della variabile load-path con C-h v load-path RET). Se si era installata la vecchia versione di auto-complete è conveniente rimuovere le stringhe precedentemente inserite prima di aggiungere le nuove (anche se alcune coincidono).

Ora esiste anche un sito (in inglese) dedicato a questa estensione, con una ricca documentazione che spiega per esempio come creare nuovi dizionari per determinate major mode di Emacs.

venerdì 12 febbraio 2010

[Risolto] Gnuplot va in crash usando wxt come terminale

Usando `wxt' come terminale in Gnuplot, famoso programma per disegnare grafici di funzioni matematiche, crasha irrimediabilmente poco dopo che viene rappresentato il grafico (non so se questo problema si presenti solo su Ubuntu o anche su altri sistemi). Il problema si risolve facilmente cambiando terminale, per esempio usando `x11'. Se però preferite usare il più ricco wxt, su Launchpad è stato segnalato (già da un bel po' di tempo) questo workaround: andate in SistemaPreferenzeTecnologie assistive e deselezionate l'opzione "Abilitare le tecnologie assistive". Ovviamente questo può essere fatto solo se non si ha bisogno di questo tipo di supporto.

lunedì 4 gennaio 2010

Installare una versione funzionante di Maxima in Ubuntu

Nota: il problema è ormai risolto dalla versione 10.04 di Ubuntu (Lucid Lynx) in poi. Comunque il repository di Launchpad segnalato permette di avere, in genere entro pochi giorni, l'ultima versione di Maxima e wxMaxima.


Nelle ultime versioni di Ubuntu è disponibile nei repository ufficiali una versione non funzionante del programma di calcolo simbolico e numerico Maxima. Infatti, provando a usare Maxima vi potrebbe capitare ben presto di leggere questi messaggi di errore:
(%i1) atan(x);
Universal error handler called recursively (:ERROR NIL
CONDITIONS::CLCS-UNIVERSAL-ERROR-HANDLER
""
"Couldn't protect")
Universal error handler called recursively (:ERROR NIL
CONDITIONS::CLCS-UNIVERSAL-ERROR-HANDLER
"" "Couldn't protect")
Maxima encountered a Lisp error:

Error in CONDITIONS::CLCS-UNIVERSAL-ERROR-HANDLER [or a callee]: Caught fatal error [memory may be damaged]

Automatically continuing.
To reenable the Lisp debugger set *debugger-hook* to nil.
(%i2) atan(x);
Segmentation fault

Il problema, segnalato su Launchpad nel bug 303587, può essere risolto aggiungendo il repository di blahota. Per fare ciò è sufficiente dare nel terminale il comando
sudo add-apt-repository ppa:blahota/wxmaxima
e il repository sarà anche automaticamente autenticato senza bisogno di ulteriori interazioni.

Questo non è un bug di Maxima ma solo del pacchetto precompilato presente nei repository di Ubuntu, quindi non segnalatelo sul sito di Maxima. Potreste anche provare a compilare da voi Maxima. Se avete un account su Launchpad, non aprite altre segnalazioni ma piuttosto commentate (se ne avete bisogno) il bug segnalato prima e aggiungetevi nell'elenco delle persone affette dal problema.

Nelle ultime versioni di wxMaxima viene usato `wxt' come terminale predefinito per gnuplot, che però va in crash. Un workaround per risolvere il problema può essere trovato qui.

Aggiornamento del 15/02/2010: il bug 303587 sembra che sia stato risolto (riguarda il pacchetto gcl), vedremo se in Lucid sarà presente una versione di Maxima funzionante.