Latex e PDFLatex danno impaginazioni diverse

Ciao a tutti,

Esordisco in questo forum esponendovi un problema che non sono riuscito a risolvere, ne tantomeno a capire se di problema effettivamente si tratta.

Compilando con Latex il documento che ho scritto ottengo un file .dvi con una disposizione di testo e figure che mi aggrada. Il problema è che il risultato finale che desidero è un file .pdf con i collegamenti ipertestuali, per i quali mi affido al pacchetto hyperref. Però quando eseguo PDFLatex la disposizione di testo e figure che ne deriva è completamente diversa rispetto al file .dvi e la cosa non mi aggrada.

Faccio un esempio, ho una figura grande che occupa quasi tutta la pagina. Nel file .dvi riesco comunque ad avere 2 righe di testo sotto la figura, nel .pdf no, pur essendo la dimensione della figura identica.

Esiste qualche pacchetto o qualche comando che mi consenta di evitare questa differenza tra i due file o sono costretto a ridurre le dimensioni delle figure (soluzione che preferirei evitare)?

Grazie per l’aiuto

Benvenuto!

Esempio minimo, per favore. Per l’immagine basta dirne le dimensioni che trovi nel .log

La differenza può essere dovuta alla conversione da eps a pdf.

Ciao
Enrico

I pacchetti che ho caricato sono i seguenti

`\documentclass[12pt,a4paper,twoside,openright,final]{book}
\usepackage[english,italian]{babel} % Dizionario di inglese
\usepackage[latin1]{inputenc} % Caratteri di input. Posso usare gli accenti
\usepackage[T1]{fontenc} % Caratteri di stampa.
\usepackage{amsfonts} % Migliora la grafica dei simboli matematici
\usepackage{amsmath} % Migliora presentazione formule matematiche
\usepackage{graphicx} % Pacchetto grafica avanzato
\usepackage{ctable} % Aggiunge comandi per righe tabelle più spesse
\usepackage{indentfirst} % Impone rientro alla prima frase
\usepackage{fancyhdr} % Più opzioni per note a piè di pagina
\usepackage{setspace} % Per assegnare l'interlinea
\usepackage{float} % Posiziona un'immagine esattamente dove si vuole con [H]
\usepackage{lipsum} % Per scrivere il testo fittizio Lorem Ipsum \lipsum[1-10]
\usepackage{emptypage} % Per togliere testatina e piè di pagina a pagine vuote
\usepackage{cite} % Per la bibliografia
\usepackage{epstopdf} % Per convertire .eps in .pdf quando uso PDFLaTeX
\usepackage{subfigure} % Per affiancare due o più figure
\usepackage[font=small,labelfont=bf]{caption} % Didascalie con etichetta in grassetto
\usepackage{hyperref} % Per collegamenti ipertestuali nel .pdf (non va con draft)`

Come si può vedere mi sono affidato a epstopdf per la conversione delle immagini, che inserisco senza mettere l’estensione in modo che il programma riconosca automaticamente se deve convertirle in .pdf o lasciarle in .eps.

Le figure incriminate sono in realtà 6 immagini messe insieme dal pacchetto subfigure di seguito il codice utilizzato:

`\begin{figure}[!h]
\centering
\subfigure[Wavenumber $\theta=0^\circ$]{\includegraphics[width=6.7cm]{images/4/PiastraAl1mm_wn_beta=0}}
\subfigure[Wavenumber $\theta=0^\circ$ (detail)]{\includegraphics[width=6.7cm]{images/4/PiastraAl1mm_wn8_beta=0}}
\subfigure[Phase velocity $\theta=0^\circ$]{\includegraphics[width=6.7cm]{images/4/PiastraAl1mm_pv_beta=0}}
\subfigure[Group velocity $\theta=0^\circ$]{\includegraphics[width=6.7cm]{images/4/PiastraAl1mm_gv_beta=0}}
\subfigure[Polar plot wavenumber at 200KHz]{\label{4-img.disp_al_pol_wn}\includegraphics[width=6.7cm]{images/4/PiastraAl1mm_polar_wn_200KHz}}
\subfigure[Polar plot phase velocity at 200KHz]{\label{4-img.disp_al_pol_pv}\includegraphics[width=6.7cm]{images/4/PiastraAl1mm_polar_pv_200KHz}}
\caption{Wavenumber, phase and group velocity dispersion curves of the isotropic, 1mm thick, aluminum plate}
\label{4-img.disp_al}
\end{figure}`

Quando eseguo PDFLatex per ogni figura sul file .log ho il seguente risultato:

`Package epstopdf Info: Source file:
(epstopdf) date: 2010-05-04 16:00:24
(epstopdf) size: 66020 bytes
(epstopdf) Output file:
(epstopdf) date: 2010-05-04 16:22:08
(epstopdf) size: 141987 bytes
(epstopdf) Command:
(epstopdf) \includegraphics on input line 321.
Package epstopdf Info: Output file is already uptodate.

File: images/4/PiastraAl1mm_wn_beta=0-eps-converted-to.pdf Graphic file (type p
df)
`

Invece quando eseguo Latex nel file .log non compaiono dimensioni delle figure.

Penso anch’io che si tratti di un problema di conversione, però come posso fare a confrontare le dimensioni del .eps con quelle del .pdf?

Grazie

Ma a che ti serve il passaggio per il dvi?

Ciao
Enrico

Impiega molto meno a compilare, quindi uso quello durante la stesura e alla fine uso PDFLatex per la versione definitiva

Molto meno? Certo, se usi epstopdf con l’opzione -shell-escape attiva, ci sono parecchi processi da lanciare. Ma una volta che hai tutti gli eps convertiti, non vedo perché mai ci debba essere differenza di tempi.

Ciao
Enrico

5 secondi con Latex
20 secondi con PDFLatex.

E togliendo la chiamata al pacchetto epstopdf?
Converti tutte le immagini anche in pdf e conservale in entrambi i formati.

🙂
LuCa

Aggiungo a quanto ti hanno già detto che è normale che il DVI prodotto con LaTeX possa essere diverso dal PDF prodotto con pdfLaTeX.

Per esempio, microtype produce risultati migliori con pdfLaTeX: può capitare che lo stesso capoverso abbia una lunghezza diversa, su DVI e PDF.

Il consiglio è sempre lo stesso. Di regola, il DVI va bene solo per le bozze, mentre per il documento finito va usato pdfLaTeX.

Ciao,
L.

Non so se c’entri qualcosa, ma subfigure è obsoleto: cerca “subfig” nell’Arte (quassù).

Ciao,
L.

Ciao,
di solito si usa il comando \includeonly per rielaborare un solo capitolo del documento ed abbreviare i tempi di compilazione ottenendo riferimenti incrociati ecc.

Ma ci sono altre possibilità per gli esigenti: precompilare il preambolo.
Si tratta di precaricare le chiamate alla classe ed ai pacchetti allo stesso modo in cui pdftex elabora un sorgente LaTeX utilizzando il sorgente LaTeX precompilato.

Le istruzioni si trovano qui: http://magic.aladdin.cs.cmu.edu/2007/11/02/precompiled-preamble-for-latex/

Non ho il tempo per sperimentare l’effettiva convenienza di un simile procedimento e quindi ve lo segnalo solamente.

Ma più che accorciare i tempi di compilazione, un enorme risparmio di tempo in fase di revisione del documento la si ottiene con la navigazione incrociata tra sorgente e pdf, fenomenale feature offerta, per esempio, dal giovane editor TeXWorks tramite SyncTeX, ma limitata ai sorgenti non strutturati in file distinti. L’editor infatti non gestisce ancora i progetti ma solo un file alla volta e spero in questo di essere smentito qui sul forum o che presto gli sviluppatori di TeXWorks lo estendano in questo senso.

Altro filone dell’argomento riguarda l’evoluzione dei processori multicore. Pensiamo ad esempio ad un pdfTeX futuro (luaTeX) che sfrutti l’elaborazione parallela. Avresti il sorgente in un istante.

Si che la composizione tipografica è qualcosa di sequenziale ma chissà se non si trovi il modo di una multicompilazione per stadi fino ad arrivare al documento finale.

Bye.

5 secondi con Latex
20 secondi con PDFLatex.

Se vuoi vedere se hai fatto qualche errore nello scrivere una formula già 5 secondi sembrano un eternità. Sono un tipo esigente 😀

DVI è morto.
Usa solo pd(la)tex; per le figure bitmap usa png se in RGB,
altrimenti tiff se in CMYK inscatolati in pdf (tiff2pdf).
Per il resto converti tutto in pdf.

5 secondi con Latex
20 secondi con PDFLatex.

Se vuoi vedere se hai fatto qualche errore nello scrivere una formula già 5 secondi sembrano un eternità. Sono un tipo esigente 😀

DVI è morto.
Usa solo pd(la)tex; per le figure bitmap usa png se in RGB,
altrimenti tiff se in CMYK inscatolati in pdf (tiff2pdf).
Per il resto converti tutto in pdf.

Il DVI non è proprio morto non credi? in fondo pstricks passa da questo formato no…

Invece, cosa ne pensi Luigi di un pdftex per processori multicore?
Bye
Roberto

Il DVI non è proprio morto non credi? in fondo pstricks passa da questo formato no…

Non hai (ho) bisogno di pstricks da quando c’è metafun (metapost in pdf)

Invece, cosa ne pensi Luigi di un pdftex per processori multicore?
Bye
Roberto

TeX è linguaggio interpretato, inerentemente sequenziale ma molto efficiente.
Ora come ora non vedo particolari spazi per il parallelismo , ma ho in progetto di investigare luatex con OpenMP, spec. il garbage collector,
Ovviamente avere più core è teoricamente utile in situazioni tipo
“Devo spezzare un vbox in 2 parti, ed ho quattro tentativi: con un core
mi costa 4 se va male, 1 se va bene; con 4 core mi costa
sempre 1” — posto che non ho tempo/voglia di scremare le 4 possibilità in modo analitico, ie con una analisi preventiva.

Ma qui stiamo parlando di un parallelismo portato a livello utente
che richiede cura nella gestione della memoria che in TeX è globale.

Forse il breaking di pagina può avvantaggiarsi dai multicore,
e forse la gestione dei fonts, ma non credo in modo spettacolare.

Cmq. è perlomeno pensabile con luatex.

Il DVI non è proprio morto non credi? in fondo pstricks passa da questo formato no…

Non hai (ho) bisogno di pstricks da quando c’è metafun (metapost in pdf)

Invece, cosa ne pensi Luigi di un pdftex per processori multicore?
Bye
Roberto

TeX è linguaggio interpretato, inerentemente sequenziale ma molto efficiente.
Ora come ora non vedo particolari spazi per il parallelismo , ma ho in progetto di investigare luatex con OpenMP, spec. il garbage collector,
Ovviamente avere più core è teoricamente utile in situazioni tipo
“Devo spezzare un vbox in 2 parti, ed ho quattro tentativi: con un core
mi costa 4 se va male, 1 se va bene; con 4 core mi costa
sempre 1” — posto che non ho tempo/voglia di scremare le 4 possibilità in modo analitico, ie con una analisi preventiva.

Ma qui stiamo parlando di un parallelismo portato a livello utente
che richiede cura nella gestione della memoria che in TeX è globale.

Forse il breaking di pagina può avvantaggiarsi dai multicore,
e forse la gestione dei fonts, ma non credo in modo spettacolare.

Cmq. è perlomeno pensabile con luatex.

Pensavo ad una cosa di questo tipo:
eseguire la composizione a strati, ovvero suddividere in tanti processi paralleli la composizione grezza delle pagine per poi in un momento finale assemblare i componenti risultato nel documento finale.
Il processo finale dovrebbe risolvere in modo sequenziale tutti i nodi lasciati aperti perché dipendenti dagli oggetti tipografici esterni al nodo considerato.

So che Intel sta progettando processori a 48 core ( http://www.intel.com/pressroom/archive/releases/2009/20091202comp_sm.htm ). L’elaborazione parallela è complessa e difficile ma con tutta quella potenza di calcolo, necessaria.

Ovviamente non sono un esperto di programmazione concorrente ma capisco che un programma tipografico a composizione parallela comporta la totale riscrittura del motore.

In altre parole, un nuovo TeX parallelo se ingegneristicamente corretto e pertinente al lavoro tipografico, è un idea incredibile.

Grazie.

Pensavo ad una cosa di questo tipo:
eseguire la composizione a strati, ovvero suddividere in tanti processi paralleli la composizione grezza delle pagine per poi in un momento finale assemblare i componenti risultato nel documento finale.
Il processo finale dovrebbe risolvere in modo sequenziale tutti i nodi lasciati aperti perché dipendenti dagli oggetti tipografici esterni al nodo considerato.

Non puoi comporre parallelamente pagine diverse, perché sai dove comincia una quando sai dove finisce la precedente. Potresti dividere tra i processori la composizione dei capoversi, che sono effettivamente indipendenti l’uno dall’altro, ma c’è il problema dei gruppi: i valori impostati in un gruppo valgono fino a quando il gruppo finisce.

Potrebbero essere suddivisi tra i processori i vari livelli di TeX: uno gestisce l’input, uno l’espansione, un terzo l’esecuzione dei comandi e un quarto la composizione finale (del dvi o del pdf). Ma comunque ciascun livello richiede informazioni dal livello superiore e non credo si ottenga tutto questo risparmio.

Ciao
Enrico