C'è un aggiornamento. L'utente martello, che è l'autore del documento,
ha postato sul newsgroup una accurata analisi della situazione. Col suo
permesso la copio qui e, rivolgendomi in modo particolare
all'onnisciente Andrea :-), vorrei capire se è il caso di segnalare
qualcosa e al limite come procedere. In fin dei conti sembra una
regressione, ma la situazione è un po' complessa.
Segue post dell'utente martello su it-alt.comp.software.openoffice.
Forse ne sono venuto a capo.
Al sorgere del sole ho aperto il famoso documento 16 con Libo.
Sono andato nell'indice principale e col tasto destro del mouse ho
forzato l'aggiornamento dell'indice.
Poi ho salvato con nome diverso il file.
Questo è il file risultante.
https://dl.dropboxusercontent.com/u/65873735/LIBO16pagine.odt
La prima considerazione che possiamo fare è la dimensione del file:
documento originario 17445 Kb e quest'ultimo 15775 Kb.
Inoltre il file generato (almeno da me) è apribile e salvabile con Apache.
Cosa è successo?
Sulla dimensione del file non ho spiegazioni valide.
Ho provato a decomprimere i file e risultano di dimensioni molto diverse.
La differenza è sostanzialmente dovuta ai file content.xml che
decompressi sono in uno 17229 Kb e nell'altro 31428 Kb.
La dimensione delle immagini contenute è la stessa (che sono poi il
maggior peso del file compresso).
Facciamo anche questa premessa: il documento è molto grosso ma non
contiene particolari strutture o altre stranezze.
In pratica è formato da solo testo in sequenza e parecchie immagini di
cui però la maggior parte sono piccoli emoticons.
A queste si aggiungono due indici diciamo a differente priorità (c'è un
indice dell'indice in pratica).
Questo è tutto.
A cosa si devono (con alta probabilità ... perchè di certo come al
solito ci sono altre cose) le difficoltà di Apache.
Il famoso documento 16 ha un disallineamento tra il conteggio interno
memorizzato ed il numero reale di caratteri e di pagine presenti nel
documento.
Le vecchie versioni di Apache ed anche Libo sono relativamente
insensibili a questo disallineamento.
Apache 4 invece va in tilt (in termini di elaborazione e quindi di
tempo) quando il numero di pagine e di caratteri non sono quelli reali.
Aggiornando l'indice manualmente le cose tornano a posto ed il numero
delle pagine e dei caratteri computato diventa uguale a quello reale.
Naturalmente qualcuno si sta chiedendo come sia possibile che non
corrispondano i numeri di pagina reali con quelli computati.
La spiegazione sta nella generazione del documento.
Come molti di voi sanno il documento viene generato partendo da un
database tramite macro in star basic.
Durante tutta la generazione del documento si vede che il conteggio
delle pagine è disallineato con il numero di pagine reali.
Quando il documento è completo per aggiornare il numero di pagine
bisogna farlo scorrere manualmente fino all'ultima pagina ma spesso il
numero totale di pagine è conteggiato senza considerare le 70 pagine di
indice.
Forzare via software l'aggiornamento dell'indice non ha effetto mentre
facendolo manualmente il computo delle pagine si assesta al valore corretto.
Questi problemi li conoscevo da tempo (è sempre stato così durante la
generazione delle FAQ).
Questo spiegherebbe anche i tempi biblici di Apache durante la
generazione delle FAQ (un ora per libo e 5 ore abbondanti per Apache).
Come si presenta, durante la generazione del documento, un
disallineamento del numero di pagine Apache va in bambola.
Supponendo che la mia diagnosi sia corretta ...
chi lo spiega al sig. Apache?
In effetti non si direbbe un vero e proprio Bug.
Se c'è qualcosa che non va ... è un problema di generazione del
documento (che tra l'altro è sempre stata afflitta da questo problema) e
non del suo salvataggio e/o apertura.
Mettiamola così ...
Se in qualche modo la segnalazione ha un seguito ...
potrei anche tentare di costruire una macro che tramite un testo dummy
genera un enorme documento con indice e qualche immagine sempre dummy.
Sperando di riprodurre l'errore su Apache e il 'non errore' su Libo.
Dati però i tempi estenuanti per le prove... sarebbe bene che ci sia una
moderata certezza sull'interesse reale alla cosa da parte degli
sviluppatori.
Non so se mi sono spiegato.
--
Saluti
VITRIOL
-
To unsubscribe, e-mail: progetto-it-unsubscr...@openoffice.apache.org
For additional commands, e-mail: progetto-it-h...@openoffice.apache.org
