Calc, OpenOffice.org e l'annoso problema delle righe da ripetere in stampa

Da più di un anno un noiosissimo bug in Calc di OpenOffice.org mi rendeva la vita difficile nel produrre elenchi formattati: l'impossibilità di impostare le righe da ripetere su ogni foglio in stampa.
Andando alla funzione Formato -> Aree di stampa -> Modifica, nella casella Riga da ripetere sia digitando manualmente i valori che  selezionando la riga del foglio da stampare tramite l'apposito tasto posto all'estrema desta, il risultato era sempre lo stesso: cliccando sul tasto Ok si otteneva sempre il messaggio Riferimento foglio non valido.
Più di una volta ho cercato si Google senza trovare nulla, ma oggi mi sono imbattuto in un post sul forum di OpenOffice.org che mi ha risolto una volta e per sempre il problema! In soldoni, come riporta l'utente sbaturzio:

Allora: ho risolto facendo così:
* Menu -> Strumenti -> Opzioni -> OpenOffice.org Calc->Formula
* Attivo Usa nomi di funzione Inglesi
* premo Ok
Da questo momento in avanti la funzionalità Riga da ripetere lavora correttamente senza errori.
Posso anche riportare la checkbox Usa nomi di funzione Inglesi allo stato originale senza che Riga da ripetere torni a dare errori.

Posso testimoniare che la cosa ha funzionato anche sul mio OpenOffice.org 3.2.1 (OOO320m15 (Build:9492) 3.2.1.4).

Powered by ScribeFire.

Continua...

InAcceptabile comportamento di IE[5-8]

Un utente si lamentava che una delle nuove funzionalità di OPTA, viste in funzione sul mio PC, non funzionavano correttamente. Alla richiesta di visionare l'elenco dell'organico, invece di aprire la pagina con l'elenco, veniva sempre ed inesorabilmente scaricato l'elenco in formato CSV (opzione presente con un link nella pagina, assieme a quello analogo per ottenerlo come PDF).

Inizio l'indagine constatando che la segnalazione proveniva da un'utente che usa IE8 (su Windows, of course), mentre con Firefox 3.6 (su Linux, obviously) tutto andava liscio come l'olio. Provo immediatamente con Firefox e con Chrome anche su Windows, ma lo strano comportamento non si presenta e l'elenco si visualizza correttamente.
Collego subito il problema con la gestione della respond_to del controller Rails relativo alla pagina: il codice, però, è scritto correttamente e poi: perché scarica proprio il CSV e non PDF?
Cerco un po' di documentazione in giro, mentre nel controller disabilito la gestione del formato CSV e faccio una nuova prova. Magicamente IE8 si comporta di nuovo normalmente. Mi risulta naturale cercare un tool (su Windows) per visionare le request inviata da IE8 al server. Trovo l'ottimo Fiddler (che potete vedere, figura precedente, nella parte alta della schermata).
Usandolo, noto come IE8 invii, nell'intestazione Accept, una marea di formati, fra cui application/vnd.ms-excel. Sembro essere sulla buona strada: ripristino la gestione del file CSV nel controller Rails e con l'aiuto di Fiddler forgio una request in cui elimino la voce application/vnd.ms-excel. Ora anche in IE8 ottengo l'elenco in formato HTML, come ci si sarebbe aspettato che fosse fin dall'inizio.
Nel frattempo le ricerche su internet mi avevano portato a questo articolo, Unacceptable Browser HTTP Accept Headers (Yes, You Safari and Internet Explorer) che mi apre la mente: la mia applicazione in Rails serve ad IE8 sempre prima il fomato CSV, semplicemente perché IE8 non invia il MIME-type text/html nell'Accept (provare per credere)!
Ulteriore conferma la ebbi leggendo il post Ruby on Rails and IE 8 - respond_to and HTTP accept headers.
Per la soluzione ho quindi inserito il seguente codice nelle viste Rails, al momento di creare il link:
par.merge!({:format => :html}) if request.env['HTTP_USER_AGENT'] =~ /MSIE/
dove par è l'hash utilizzato per la creazione dell'URI. In questo modo, per IE8 si forza esplicitamente il formato (HTML) richiesto, postponendo .html all'URI standard generato con Rails.

Powered by ScribeFire.

Continua...

Su Apache, ODT, PDF e unoconv

Da tempo in ufficio si utilizza una applicazione web, da me scritta, per la creazione di fax per la richiesta di visite fiscali alle ASL. Sebbene l'idea di partenza fosse quella di utilizzare direttamente Hylafax per l'invio dei fax, alla fine, per problemi puramente burocratici (firma "manuale" da apporre al documento e mancanza di una linea telefonica da utilizzare verso l'esterno), si è optato per la generazione di un file PDF da far stampare all'utente.

Tutto il servizio è basato su di una macchina virtuale GNU/Linux Mandriva 2009.1 su cui gira l'applicazione Rails per mezzo di Mongrel e Apache: ciò perché sussisteva già un'altra applicazione Rails che girava appoggiandosi al solo Mongrel. Impostando Apache in modalità revese proxy ero riuscito a far funzionare entrambe le applicazioni web come se fossero una sola.La generazione dei file avveniva in maniera alquanto macchinosa: si partiva da un modello in formato RTF, che veniva "riempito" con i dati presi da un database e convertito in PDF (tramite una antidiluviana applicazione, ted); il file risultante, a sua volta, veniva sovrapposto ad un altro contenente l'intestazione ed il piè di pagina con il necessario logo (tramite il mitico pdftk). Inoltre, per non appesantire troppo la macchina virtuale, ciascuna applicazione web girava in una singola istanza di Mongrel, invece che in cluster.
Morale della favola, vuoi per problemi di virtualizzazione (VMware), vuoi per problemi di carico su Mongrel, a volte al posto del PDF richiesto veniva mostrato un poco simpatico 504 Gateway Timeout.
Per risolvere il problema avevo pensato dunque di fare un doppio passaggio:

• utilizzare Phusion Passenger al posto di Mongrel per le applicazione web;
• sostituire i macchinosi script per la creazione del PDF con documatic (vedi pure su github per una versione più aggiornata) e unoconv.

Phusion Passenger
il passaggio a Phusion Passenger è stato alquanto semplice: è bastato installare la gem passenger (ora alla versione 2.2.11) e seguire le istruzioni per la corretta installazione dell'applicazione web.
Passaggio a Documatic ed unoconvL'utilizzo di Documatic è stato un po' più problematico per la fase di installazione dell'applicazione. Come prima, installiamo la gem documatic e assicuriamoci che sulla macchina server sia installato OpenOffice (attenzione, potrebbe essere necessario installare anche un desktop manager!). Predisponiamo anche unoconv ad essere eseguito ponendolo nella cartella /usr/bin od equivalente, purché sia nel path di root.
A questo punto il problema è che unoconv si rifiuta di funzionare, sebbene usandolo stand alone tutto sia a posto! Per risolverlo, è necessario un passaggio che ho scovato sul blog Blog of a LAMP Developer based near Guildford, Surrey, scorrendo il post Converting a Doc to PDF, txt or HTML using PHP and Linux, scritto per l'utilizzo di unoconv con PHP, si scopre che bisogna creare una home anche per l'utente apache:
[root@localhost home]# mkdir /home/apache
[root@localhost home]#chown apache:apache /home/apache
[root@localhost home]#usermod -d /home/apache apache
[root@localhost home]#chmd 755 /home/apache
In questo modo il funzionamento è assicurato.
Quello che non sono riuscito a fare, è predisporre un istanza di unoconv come listener e lanciare dalla applicazione web la connessione a quest'ultimo, in quanto dopo un po' di tempo (variabile di volta in volta) il listener sembrava fermarsi da solo, con unoconv che ti avvisava di andare in funzione in modalità stand-alone.

Powered by ScribeFire.

Continua...

urpmi: downgrade di pacchetti.

A seguito di un aggiornamento di KDE che non mi aveva del tutto soddisfatto (per la cronaca, da 4.3.2 a 4.4.2, non ancora ufficialmente supportata in Mandriva) , mi sono trovato nella condizione di di dover fare un downgrade alla precedente versione. Ovviamente non è bastato eliminare le fonti da cui avevo tratto l'aggiornamento, in quanto il successivo

# urpmi task-kde4

mi rispondeva dicendo che avevo già installato un pacchetto più aggiornato di quello presente nel repository :-(.

Neanche le maniere dure sono bastate:

# urpme task-kde4
# urpmi task-kde4

ha sì reinstallato il buon vecchio KDE 4.3.2, ma non tutte le dipendenze sono state risolte correttamente. Cosicché parecchi pacchetti erano rimasti ancora "troppo" aggiornati!
Per reinstallarli (ad uno ad uno!) mentre durate l'uso ne scovavo qualcuno, diventava impossibile eliminarli tramite urpme poiché ogni volta si rischiava di dover cancellare tutto KDE con successiva reistallazione; pura follia.
Dopo un attimo di spavento, ho ravanato un po' fra Google e Mandrivaitalia.org
, alla ricerca di un metodo per effettuare un downgrade correo di ciascun singolo pacchetto. Alla fine la soluzione trovata e testata è:

# rpm -e --nodeps <nomepacchetto>
# urpmi <nomepacchetto>

per ciascun pacchetto da di cui effettuare il downgrade.

Continua...

Ruby Best Practices di Gregory Brown

Dal creatore e principale manutentore di Prawn, ecco un interessante libro sulle "best practices" in Ruby, derivanti dal suo lavoro con questo linguaggio.
La versione versione open source dell'intero libro è disponibile all'interno del post Full Book Now Available For Free! sul suo blog.
L'indirizzo da cui prelevare il libro è http://sandal.github.com/rbp-book/pdfs/rbp_1-0.pdf, ma penso davvero che possa essere interessante visitare il blog di Gregory.

Buona lettura!

Powered by ScribeFire.

Continua...

CUPS 1.4.1 ed un baco malefico risolto

Con CUPS 1.4.1 ho avuto modo di imbattermi in un malefico bug con le stampanti condivise con SaMBa.
Il baco consiste nella richiesta continua delle credenziali per l'accesso alla stampante, anche se si è configurato correttamente l'accesso ad un dominio Windows da GNU/Linux.
Questo baco, molto sottile consiste nel fatto che CUPS 1.4.1 imposta (e reimposta dopo ogni stampa), nel file /etc/cups/printers.conf  l'attributo

AuthInfoRequired username,password

La soluzione al problema consiste nel commentare nel file tal riga e nel rendere tale file non modificabile: a tal fine non basta usare

[me@mybox]# chmod a-x /etc/cups/printers.conf

, in quanto CUPS riesce a reimpostare anche tali permessi, ma usare il meno noto (almeno a me)

[me@mybox]# chattr -i /etc/cups/printers.conf

Ecco di seguito tutto quello che c'è da fare:

[me@mybox]$ su
Password:
[me@mybox]# chattr -i /etc/cups/printers.conf
[me@mybox]# /etc/init.d/cups stop
[me@mybox]# vim -i /etc/cups/printers.conf
editare il file, ad es.
<defaultprinter theprinter="">
#AuthInfoRequired username,password
...
# eliminare la password e l'username quando il baco di CUPS 1.4.1 sparira'
DeviceURI smb://me:mypwd@MYDOMAIN/windoze/theprinter
...
</defaultprinter>
e poi
[me@mybox]# chattr +i /etc/cups/printers.conf
[me@mybox]# /etc/init.d/cups start

Powered by ScribeFire.

Continua...

Ottenere la documentazione di classi e metodi di Ruby da command line

Poiché uso spesso la documentazione on-line di Ruby e Rails, invece di quella da riga di comando, scrivo questo post come promemoria personale.
Per ottenere la documentazione di Ruby (e quindi anche di Rails e di altre Gem installate in locale) prodotta da rdoc bisogna, stranamente, utilizzare il comando ri, così:

[me@mypc]$ri String

In questo modo otterremo la documentazione prodotta tramite rdoc per la classe String.
Ricordo, inoltre, che il parametro del comando è case-sensitive, per cui c'è differenza fra

[me@mypc]$ri String

e

[me@mypc]$ri string

(in particolare, in Ruby con la maiuscola si fa riferimento ad una classe e con la minuscola ad un metodo, e così assume anche ri/rdoc.

Powered by ScribeFire.

Continua...