Forum Ubuntu-it

Ciao a tutti
ho un documento (esempio.odt che allego) che contiene un campo di testo condizionale che cambia in base al testo contenuto dalla variabile nel precedente campo di digitazione.
La cosa funziona se la modifica del campo digitazione è fatta a mano. Invece la funzione di LibreOffice non funziona se la stringa-condizione viene modificata da uno script che decomprime->modifica->ricomprime l'odt: a quel punto è come se per LO la stringa non corrispondesse mai.
Per provare, salvate un copia del file nella cartella /tmp poi eseguite il seguente blocco di comandi (io ho provato con python 2.7 e 3.2)

Codice: Seleziona tutto

from zipfile import ZipFile, ZIP_DEFLATED
document = '/tmp/esempio.odt'
s2b, p2b = 'STRINGA'.encode(), 'PATTERN'.encode()
with ZipFile(document,'a', ZIP_DEFLATED) as z:
	xmlString = z.read('content.xml')
	xmlString = xmlString.replace(s2b, p2b)
	z.writestr('content.xml', xmlString)

a me il problema sembra legato alla fase di compressione: infatti se ometto il parametro ZIP_DEFLATED lasciando il livello default di compressione (cioè ZIP_STORED, cioè 0) il documento odt ricreato è funzionante (ma è più pesante).

Sbaglio qualcosa o è un bug? (nel modulo zipfile o in zlib ?)

grazie per le risposte

Ciao rai,
premetto che non sono esperto di python (forse ricordi

) e neanche di libreoffice, ma qualche informazione provo a dartela.

Tempo fa avevo letto qualcosa a riguardo del formato di compressione utilizzato da LO, e da quello che mi ricordo l'articolo si riferiva al fatto che non tutti i contenuti all'interno del documento sono compressi . Uno in particolare, quello contenente il magic-number non dovrebbe esserlo. Inoltre (sempre se mi ricordo bene) il posizionamento di questo file doveva essere obbligatoriamente in testa, il che mi sembra pure logico.
Inoltre avevo letto da qualche altra parte che non tutti gli zip sono compatibili tra loro, a livello di struttura dati/algoritmi di compressione, e questo mi fa pensare che il documento ODT potrebbe non essere gestito correttamente dalle librerie.
Purtroppo le fonti non me le ricordo, ma non dovrebbe esser difficile trovare informazioni a riguardo, almeno per eseguire delle prove più mirate.

Quello che posso riscontrare ora utilizzando il tuo script è una doppia definizione del file all'interno dell'archivio... non so se te ne sei accorto (o sono io ubriaco che vedo doppio):

Codice: Seleziona tutto

  Length      Date    Time    Name
---------  ---------- -----   ----
       39  2014-06-06 11:15   mimetype
     1048  2014-06-06 11:15   meta.xml
     9878  2014-06-06 11:15   settings.xml
     5932  2014-06-06 11:15   content.xml
     3001  2014-06-06 11:15   Thumbnails/thumbnail.png
      899  2014-06-06 11:15   manifest.rdf
        0  2014-06-06 11:15   Configurations2/popupmenu/
        0  2014-06-06 11:15   Configurations2/images/Bitmaps/
        0  2014-06-06 11:15   Configurations2/toolpanel/
        0  2014-06-06 11:15   Configurations2/statusbar/
        0  2014-06-06 11:15   Configurations2/progressbar/
        0  2014-06-06 11:15   Configurations2/toolbar/
        0  2014-06-06 11:15   Configurations2/menubar/
        0  2014-06-06 11:15   Configurations2/floater/
        0  2014-06-06 11:15   Configurations2/accelerator/current.xml
    11766  2014-06-06 11:15   styles.xml
     1086  2014-06-06 11:15   META-INF/manifest.xml
     5932  2014-06-09 21:46   content.xml
---------                     -------
    39581                     18 files

Ciao
Max

Ciao max grazie dell'intervento. Ci mancherebbe che non mi ricordassi

No non vedi doppio (e meglio di me non te lo può dire nessuno

)

Penso che il file sovrannumerario sia `normale' dato che uso zipfile in modo `a' cioè append.
Probabilmente LO riconosce dai metadati quale content.xml usare (il più recente) e poi sovrascrive l'altro al primo salvataggio

Non credo che c'entrino il mimetype né le specifiche ODT: zipfile offre un unico livello di compressione che è inferiore a quello nativo di LO, ma questo non impedisce che i documenti script-editati vengano aperti normalmente.

Comunque, ho aperto una issue sul Python bug-tracker dove ho fatto una figura di m. e mi hanno risposto: not-our-bug
In pratica si tratta di una caratteristica di *Office, non configurabile AFAICT, per cui se i campi non vengono modificati manualmente, per aggiornarli bisogna farlo esplicitamente (premendo F9 per la cronaca).

Quindi niente bug dal lato Python.
Eventualmente bisognerebbe aprire una feature-request su bugzilla ma, siccome l'editing di ODT da script è piuttosto di nicchia, temo che resterebbe lettera morta come quest'altra

Almeno per ora, bisogna ricordarsi di premere F9 all'apertura del documento: niente di trascendentale

Forum Ubuntu-it

Python: modifica di un documento odt

Python: modifica di un documento odt

Re: Python: modifica di un documento odt

Re: Python: modifica di un documento odt