[Gfoss] OT: Mappe in PDF

Local Chapters GFOSS.it
1

Indipendentemente dal programma usato (kpdf in questo caso) ,
di solito, questi tipi di problemi sono dovuti all'algoritmo impiegato.

E in realta' avvengono anche su windows, ma in tal caso solo quando
nel pdf sono stati piazzati dei raster A0.

Con i dati vettoriali non dovrebbe succedere.
per cui, a naso, direi che kpdf funzioni come un rasterizzatore.

Ovvero prende il contenuto del file e lo rasterizza, ovvero lo
trasforma in una immagine bitmap.
Nel fare questo poiche' la pagina ha dimensione A0 finisce per
consumare tutta la memoria disponibile.

Se cosi' fosse vorrebbe dire che kpdf dopo aver aperto l'immagine in
A0 tenterebbe di "ridurla" a dimensioni schermo.
Cosa altrettanto onerosa.

Una riprova potresti averla controllando con comandi tipo "top" se la
memoria del processo aumenta fino al massimo.

Su windows con i vettoriali non succede perche' il client che usi
mantiene tutto a livello vettoriale fino alla effettiva
visualizzazione nella finestra.
momento in cui il dato e' gia' stato ridotto a dimensioni schermo.

--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~

2

Ciao Walter,
in effetti avevo provato anche con xpdf ottenendo risultati migliori: la mappa viene visualizzata dopo circa 6-7 minuti.

Grazie Andrea: ho provato con top. Ecco l’output:

top - 09:14:55 up 40 min, 1 user, load average: 1.56, 1.02, 0.55
Tasks: 104 total, 3 running, 101 sleeping, 0 stopped, 0 zombie
Cpu(s): 97.3%us, 2.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 224516k total, 220972k used, 3544k free, 4212k buffers
Swap: 658624k total, 30724k used, 627900k free, 73012k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3561 sit 15 0 44732 20m 15m S 90.2 9.2 1:05.18 kpdf
3227 sit 16 0 197m 64m 15m R 8.0 29.5 2:10.01 firefox-bin
3067 root 15 0 64028 21m 2612 S 1.3 9.8 0:49.42 Xorg
3517 sit 15 0 32876 14m 11m R 0.3 6.5 0:00.60 konsole
1 root 15 0 2104 632 552 S 0.0 0.3 0:00.96 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00

la CPU è quasi al massimo (arriva anche a punte del 99,8 %), la memoria sembra di no…

ciao
flavio

–
io uso Debian GNU/Linux
user #413018 counter.li.org

<<usiamo formati aperti!>>
http://it.wikipedia.org/wiki/Formato_aperto

3

Confermo per esperienza personale che kpdf rasterizza il contenuto e fa molta fatica a leggere pdf di grandi dimensioni. Il problema non si pone invece usando evince (gtk, lo standard per Gnome) oppure (scusate se lo cito) Acroread.

Con i dati vettoriali non dovrebbe succedere.
per cui, a naso, direi che kpdf funzioni come un rasterizzatore.

4

On 09:24 Tue 02 Sep , Patti Giuseppe wrote:

Confermo per esperienza personale che kpdf rasterizza il contenuto e fa
molta fatica a leggere pdf di grandi dimensioni. Il problema non si pone
invece usando evince (gtk, lo standard per Gnome) oppure (scusate se lo
cito) Acroread.

Si potrebbe provare con ePDFView; è molto leggero, non so
però come si comporti con questo tipo di file.

5

Ho fatto un piccolo test con 2 mappe. La prima è un pdf di 40 Mb, la
seconda di 10. Entrambe composte da vettori e raster. La cosa strana
(almeo per me) è che i risultati sono contraddittori:
kpdf 13 sec. per la mappa da 40 Mb e 10 per quella da 10 Mb
pdfview 35 sec. per la mappa da 40 Mb e 6 per quella da 10 Mb
evince 37 sec. per la mappa da 40 Mb e 7 per quella da 10 Mb

Sembrerebbe dunque che il "migliore" dipenda dalle condizioni?

Iacopo

Ps Kubuntu su un ADM a 64 bit con scheda video ATI Radeon X1550