[Discussioni] Fw: [humana] Raccomandate via Office (TM) Tratto da Zeus News di Anno VII- numero 668 - 27 Luglio 2005 di Michele Bottari

[Giacomo Cosenza]

On Jul 28, 2005, at 1:46 PM, Calogero Kalos Bonasia wrote:

> Alle 13:38, giovedì 28 luglio 2005, Giacomo Cosenza ha scritto:
>
>> grazie Calogero. comunque appena ho un poco di tempo ci provo  
>> anche io.
>> mimmo
>>
> ok
> il mio sistema di test e':
> fireforx 1.4
> suse linux 9.2 pro
> openoffice plio 1.4
> pdf generato con openoffice con la funzione specifica. Ho anche  
> provato a fare
> il pdf mediante la stampante pdf di kdeprint, ma niente.
ok. sono riuscito a trovare il tempo per provare (ma solo sulla  
macchina di casa):
imac G5 Mac OS X Tiger 10.4.2
firefox 1.0.4 (inglese) e safari 2.0 - come quasi in tutti i siti  
firefox e meglio supportato di safari
NeoOffice/J 1.1 patch 0
non ho generato il pdf, perche' via browser lo genera direttamente il  
servizio

ho provato solo con .doc di tre tipi:
- semplice (OK)
- medio (OK)
- complesso (genera un errore generico server side non meglio  
identificato)

Il documento complesso non e' stato prodotto con NeoOffice, ma e' un  
documento prodotto con MS Office dalla Jboss Corporation con  
immagini, header, footer, tabelle e formattato su due colonne.

Non ho invece provato con txt, xls, rtf, tiff o jpeg. A quanto mi  
risulta il formato pdf non e' supportato, ma solo generato server  
side. forse e' questo il motivo per cui a te non funziona.

Quindi il servizio funziona con NeoOffice/J (e' basato su openoffice  
1.4). Sarebbero da provare anche gli altri formati, ma adesso non ho  
tempo.

Domani, appena mi libero, provero' con il mio portatile gnu/linux.

L'ipotesi di discriminazione sul censo, quindi, sembra cadere.  
Essendo supportato anche il formato rtf credo cada anche l'ipotesi  
sulle limitazioni dei formati. Questo pero' solo per l'opzione di uso  
di ROL  via browser.

Del tutto differente e' la questione sull'opzione di uso di ROL via  
rich client, che, evidentemente, e' piu' ricca e veloce. Qui funziona  
solo ed esclusivamente Microsoft Office (per altro si deve anche  
installare il framework di .net).

Forse una richiesta che si potrebbe fare a Poste, per imparzialita'  
verso i fornitori di tecnologie client-side, e' di realizzare una  
corrispondente applicazione su OpenOffice, in modo che gli utenti che  
volessero usare il rich-client lo possano fare sia con MS Office che  
con OpenOffice.

Non credo possano addurre scuse di "unicita'" dell'applicativo,  
perche' OpenOffice, per questo tipo di applicazione e' programmabile  
tanto quanto.

Un'ulteriore alternativa sarebbe che fornissero le specifiche di  
colloquio client/server e noi potremmo realizzare l'applicazione rich- 
client per openoffice. In questo caso sarebbe desiderabile farla  
nettamente migliore di quella di MS-Office, sia dal punto di vista  
ergonomico che funzionale. Certo che sarebbe desiderabile che Poste  
tirasse fuori un budget per questa cosa. Puo' anche darsi che  
Microsoft lo abbia realizzato gratuitamente con lo scopo di generare  
ricavi da licenze d'uso di MS Office degli utenti. In questo caso e'  
piu' difficile chiedere un budget a Poste per lo sviluppo dello  
stesso applicativo su OpenOffice.

Rimane tutta l'ambiguita' del messaggio promozionale del servizio  
ROL, completamente orientato a Microsoft. L'opzione browser based di  
ROL nella comunicazione pubblicitaria del servizio e' pressocche'  
inesistente nel sito di poste ed e' del tutto assente nelle  
comunicazioni sui quotidiani. insomma l'utente e' incentivato all'uso  
di MS Office. Per altro, se andate a vedervi le comunicazioni di  
microsoft sugli accordi con Poste (basta cercare "microsoft poste" in  
google) se ne leggono delle belle.

Per ora e' tutto
Mimmo