Immagini larghe in classicthesis

nerdhero” post=100703Buongiorno a tutti, sto usando classicthesis impostata a twoside per la tesi di laurea.

Vorrei includere un’immagine molto larga e bassa da mettere all’inizio della pagina, larga come textwidth+marginparsep+marginparwidth, e posizionarla in automatico di modo che resti allineata sempre al lato della rilegatura, sia che la pagina sia pari, sia che sia dispari.

Esiste un modo per farlo?

Al momento ho usato solo il codice
`
\begin{figure}[t]
\includegraphics[width=1.3\textwidth]{material_editor.png}
\caption{}
\label{fig:editor}
\end{figure}
`
che chiaramente non produce il risultato sperato, primo perché non so come esprimere la somma delle tre dimensioni, secondo perché in una pagina pari si allarga dalla parte sbagliata.

[attachment=1294]Screenshot2015-03-2522.47.33copia.jpg[/attachment]

Grazie in anticipo
Marco

Il problema è il seguente: la dimensione della gabbia del testo viene identificata da [tt]\textwidth[/tt] perciò dire che la tua immagine ha larghezza [tt]width=1.3\textwidth[/tt] è sbagliato se vuoi che l’immagine sia contenuta nella gabbia del testo. Per un risultato migliore potresti provare:`\includegraphics[width=.95\textwidth,keepaspectratio]{material_editor.png}`L’opzione [tt]keepaspectratio[/tt] permette di avere in automatico la dimensione altezza della figura in modo tale che l’immagine non risulti distorta.

Ciao
Claudio

Ciao
Claudio

La somma delle tre lunghezze si esprime così:`\dimexpr \textwidth+\marginparsep+\marginaprwidth`da mettere al posto di 1.3\textwidth.

L’altro punto non è difficilissimo da risolvere con i normali mezzi di LaTeX, ma dipende anche dal fatto che usi classicthesis che non accetta volentieri nessuna variazione/modifica. Con altre classi, in paritcoalre memoir è possibile e facile distinguere la parità della pagina ed eseguire le operazioni necessarie. Io qui ti indico una modalità che fa riferimento al numero di pagina corrente, che per gli oggetti flottanti dovrebbe essere il numero corretto. Il codice che io userei è il seguente (nota che lo sto scrivendo di getto e può darsi che non funzioni e richieda qualche altro artificio)`\begin{figure}[t]
\edef\DS{\ifodd\value{page}l\else r\fi}
\makebox[textwidth][\DS]{\includegraphics[width=\dimexpr\textwidth+\marginparsep+\marginaprwidth]{material_editor}
\caption{…}\label{…}
\end{figure}`

Controlla i nomi \marginaprsep e \marginaprwidth perché li ho scritti a memoria e alla mia età i neuroni ehm, ehm

Attento! hai fatto tre modifiche, delle quali una sola era un refuso, del quale mi scuso; le altre due modifiche, l’aggiunta di \relax, e l’aggiunta dell’estensione alal figura sono inutili, anche se non danno nessun fastidio.

La prima: \relax è necessario se dopo la fine dell’espressione compare qualcosa (anche dopo le sostituzioni delle macro) che potrebbe modificarne l’esecuzione; è chiro che aggiungere \relax non è un errore; nel caso specifico non serve.

La seconda: \includegraphics non richiede l’esplicitazione dell’estensione, è capace di trovare da solo il file con l’estensione giusta; l’estensione diventa necessario solo se nella stessa cartella esistono file con lo stesso nome ed estensioni diverse.

Piuttosto ti consiglirei di sostituire nel nome dle file l’underscore, la lineetta ribassata, con un trattino non ribassato; come sai l’underscore in LaTeX ha un significato specifico e fino a qualche anno fa produceva errori terribili nei nomi dei file.

Scusate se mi intrometto, ma un tarlo mi rode a proposito del codice seguente.

nerdhero” post=100722Grazie Claudio, ha funzionato! Ho corretto un paio di typo, riporto il codice per completezza.

`
\begin{figure}[t]
\edef\DS{\ifodd\value{page}l\else r\fi}
\makebox[\textwidth][\DS]{\includegraphics[width=\dimexpr\textwidth+\marginparsep+\marginparwidth\relax]{material_editor.png}}
\caption{Editor dei materiali di UE4.}\label{fig:material_editor}
\end{figure}
`
[…]

Innanzitutto, è vero, come già ti ha detto OldClaudio, che “\relax” alla fine della specifica “\dimexpr” è superfluo: ci pensa già l’implementazione di “\makebox” a inserirlo. Dico questo per tranquillizzarti, perché anche a me “viene il nervoso” a pensare che una “\dimexpr” possa restare non chiusa da un “\relax” precauzionale. 🙂

Detto questo, avrei un paio di osservazioni da fare, per chiedervi di aiutarmi a recuperare il passo con quello che è successo nel mondo LaTeX negli ultimi anni.

In primo luogo, si può osservare che, anziché tramite l’uso diretto delle estensioni e-TeX, si può anche calcolare la dimensione della larghezza dell’immagine per mezzo del pacchetto calc. Domanda: a me risulta che calc tuttora non faccia uso della sintassi estesa di e-TeX quando questa è disponibile (diventando così un semplice front-end della stessa); è vero ciò?

In secondo luogo, temo che il trucco`\edef\DS{\ifodd\value{page}l\else r\fi}`con quel che segue non possa funzionare in generale, perché la scelta del posizionamento del contenuto di “\makebox” (debordare a sinistra oppure a destra) viene fatta in base al valore del numero di pagina corrente al momento in cui l’ambiente “figure” viene incontrato, che potrebbe non essere affatto la pagina su cui la figura finirà. In effetti, il problema mi sembra non essere suscettibile di soluzioni semplici, anzi, mi sembra impossibile trovare una soluzione che funzioni in piena generalità senza coinvolgere l’output routine. Mi sembra strano, però, che finora nessuno abbia scritto dei pacchetti per risolvere problemi di questo tipo: è assai probabile, invece, che sia io a non conoscerli. Qualcuno me li potrebbe suggerire?

Ciao.

—
Gustavo

letteracdp” post=100736Scusate se mi intrometto, ma un tarlo mi rode a proposito del codice seguente.

Grazie Claudio, ha funzionato! Ho corretto un paio di typo, riporto il codice per completezza.

`
\begin{figure}[t]
\edef\DS{\ifodd\value{page}l\else r\fi}
\makebox[\textwidth][\DS]{\includegraphics[width=\dimexpr\textwidth+\marginparsep+\marginparwidth\relax]{material_editor.png}}
\caption{Editor dei materiali di UE4.}\label{fig:material_editor}
\end{figure}
`
[…]

Innanzitutto, è vero, come già ti ha detto OldClaudio, che “\relax” alla fine della specifica “\dimexpr” è superfluo: ci pensa già l’implementazione di “\makebox” a inserirlo. Dico questo per tranquillizzarti, perché anche a me “viene il nervoso” a pensare che una “\dimexpr” possa restare non chiusa da un “\relax” precauzionale. 🙂

Detto questo, avrei un paio di osservazioni da fare, per chiedervi di aiutarmi a recuperare il passo con quello che è successo nel mondo LaTeX negli ultimi anni.

In primo luogo, si può osservare che, anziché tramite l’uso diretto delle estensioni e-TeX, si può anche calcolare la dimensione della larghezza dell’immagine per mezzo del pacchetto calc. Domanda: a me risulta che calc tuttora non faccia uso della sintassi estesa di e-TeX quando questa è disponibile (diventando così un semplice front-end della stessa); è vero ciò?

In secondo luogo, temo che il trucco`\edef\DS{\ifodd\value{page}l\else r\fi}`con quel che segue non possa funzionare in generale, perché la scelta del posizionamento del contenuto di “\makebox” (debordare a sinistra oppure a destra) viene fatta in base al valore del numero di pagina corrente al momento in cui l’ambiente “figure” viene incontrato, che potrebbe non essere affatto la pagina su cui la figura finirà. In effetti, il problema mi sembra non essere suscettibile di soluzioni semplici, anzi, mi sembra impossibile trovare una soluzione che funzioni in piena generalità senza coinvolgere l’output routine. Mi sembra strano, però, che finora nessuno abbia scritto dei pacchetti per risolvere problemi di questo tipo: è assai probabile, invece, che sia io a non conoscerli. Qualcuno me li potrebbe suggerire?

Ciao.

—
Gustavo

Gustavo, avevo letto che se le operazioni estese di eTeX sono abilitate (lo vedi dall’inizio del file .log) clac funziona da frontend rispetto alla sintassi di eTeX; ho però riguardato sia la documentazione di calc, sia il suo codice e constato che calc lavora nel solito modo cambiando tutto ciò che non ha dimensioni riceva le dimensioni opportune, e nel risultato queste dimensioni siano tole se il risultato NON deve essere una dimensione. Di per sé calc funziona bene, ma le operazioni di eTeX sono più veloci e in particolare lo scalamento avviene riducendo il pericolo di overflow. Io preferisco usare la sintassi diretta di eTeX almeo per calcoli semplici e di fatto constato che non ho mai caricato di mia iniziativa il pacchetto calc, nemmeno quando ho creato il pacchetto curve2e dove vengono fatte operazioni di numeri reali e complessi nei limiti dell’aritmetica del sistema TeX, ma usando solo espressioni eTeX. Inizialmente avevo anche definito un algoritmo di long division fatta come la si farebbe a mano, calcolando una cifra alla volta del quoziente, e la cosa era stata molto più breve che ricorrere ai comandi di calc e ho imparato moltissimo sull’aritmetica interna di TeX/eTeX.

Invece al questione relativa a \ifodd\value{page} è delicata; in realtà il codice degli oggetti flottanti viene usato solo nella routine di output quando la pagina dove il float viene inserito è nota. Invece se usi quella sintassi per altri scopi, non per la posizione dei float, la cosa non funziona, ma si risolve definendo un label e andando a vedere il giro dopo quale numero di pagina è associato all’etichetta di quel label. La classe memoir fa così. Io, senza sapere che la cosa è già contenuta in memoir, avevo riscoperto l’acqua calda, cioè la soluzione di memoir, quando scrivevo la classe dictionaryscr (di cui ho parlato un paio di volte su ArsTeXnica) che funzionava con una classe costruita su una classe Koma Script. Nei miei articoli su Ars non parlavo di questo problema perché non mi sembrava imposrtante.

OldClaudio” post=100744[…] Gustavo, avevo letto che se le operazioni estese di eTeX sono abilitate (lo vedi dall’inizio del file .log) clac funziona da frontend rispetto alla sintassi di eTeX; ho però riguardato sia la documentazione di calc, sia il suo codice e constato che calc lavora nel solito modo […]

Allora siamo nella stessa situazione: anche a me pareva di aver sentito che calc sfruttasse le estensioni di e-TeX, se disponibili, ma dando un’occhiata all’implementazione si vede che non è così. Probabilmente, a più di uno sembra di aver sentito questa cosa perché sembrerebbe una cosa perfettamente logica da fare, ma evidentemente non è ancora stata fatta.

Siamo tutti d’accordo, ovviamente, che le estensioni e-TeX sono la scelta d’elezione; è solo per una questione di eleganza che uno si picca di restare fedele al TeX di Knuth. Anni fa, scherzando su questo forum con Enrico Gregorio, la paragonavo a una questione di religione: la disputa tra “ortodossi” ed “e-cattolici” (o meglio, “$\varepsilon$-cattolici”)! 🙂 Lo facevo per prendere in giro me stesso, vestendo, a quei tempi, i panni del “\TeX-ortodosso” (e anche oggi, sono un convertito che ha ancora retropensieri :wink:).

OldClaudio” post=100744Invece al questione relativa a \ifodd\value{page} è delicata; in realtà il codice degli oggetti flottanti viene usato solo nella routine di output quando la pagina dove il float viene inserito è nota.

Non mi è chiaro. La figura viene salvata in una scatola, ovviamente come lista verticale. Questa lista verticale contiene, fra le altre cose, la scatola prodotta da `\makebox[][]{…}`che sarà una hbox della dimensione voluta con colla infinitamente allungabile e accorciabile (“\hss”) o all’estremo sinistro, o all’estremo destro, a seconda del valore che il contatore “page” ha al momento in cui “\makebox”, con quel che segue, viene digerito. La hbox, una volta costruita, non cambia più, quale che sia la pagina su cui va a finire.

OldClaudio” post=100744[… La cosa] si risolve definendo un label e andando a vedere il giro dopo quale numero di pagina è associato all’etichetta di quel label. […]

Giusto: perché insistere a voler far tutto in un’unica compilazione? Il ricorso a un’etichetta permette di risolvere il problema con grande semplicità, anche se obbliga a ricompilare. Con la spaventosa velocità degli elaboratori di oggi, chi si preoccupa più di queste cose? 🙂

Ciao.

—
Gustavo

Non sono convinto che un float, qualunque cosa contenga, si sotto forma di lista verticale già composta in bozza non impaginata (galley proof) come avviene per il testo. Certamente i float sono cose diverse; come lo sono le note marginali e le note al piede con i quali i float condividono alcune proprietà, tanto che troppe note marginali possono produrre l’errore “Floats losts”. Ne ho esperienza diretta. Poi ci sono altre cose fatte apposta per essere eseguite solo al momento del shipout, operazione che avviene dopo l’esecuzione di uno degli stadi della routine di output.
Peccato che la lettura della routine di output richieda competenze molto superiori alla mia.
Quindi quanto dico a proposito del fatto che il numero di pagina è quello definitivo quando un float viene impaginato può essere sbagliato, ma mi ha sempre funzionato bene; fortuna? forse.

Per certe cose non flottanti ho dovuto ricorrere all’uso di un label creato apposta, oppure a comandi \afterpage annidati. L’operazione con i label funziona sempre, ma per scriverla bisogna andare a vedere i comandi interni e se si usa hyperref i label hanno cinque campi invece di due, quindi la cosa diventa ancora più elaborata.

La velocità delle macchine di oggi è strepitosa ma nonè usata in modo efficiente; quasi tutta la potenza di calcolo e del tempo di CPU viene consumato per gestire il multitasking e la grafica sempre più elaborate dei PC moderni che richiedono RAm enormi per ridurre le impaginazioni nella memoria virtuale; se questa è su un disco meccanico, non ne parliamo più. Con i moderni SSD le cose vanno moto meglio, ma non strepitosamente meglio.

Quando ho scritto il mio primo testo di elettronica, con LaTeX209 con uscita in dvi, DOS 6.1, 30 MHz di clock e 2MiB di RAM, le700 pagine circa, che contenevano circuiti elettronici disegnati accostando un numero incredibile di puntini, ci metteva circa 35 s. Oggi con una macchina con Latex2e e uscita in pdf, So Yosemite, 3GHz di clock, 16 GiB di RAM, quelle stesse 700 pagine con i circuiti disegnati con i comandi interni di pdftex, ci mette circa 20s. cero è di meno, ma non in proporzione inversa con le enormi risorse messe a disposizione dall tecnologia moderna.

Non voglio essere un “laudator temporis acti”; ma certo queste mie esperienze mi fanno pensare. Ora sto lavorando con un disegno fatto con pgfplots; una sfera con meridiani e paralleli e i percorsi di una lossodromica e di una ortodromica che connettono gli stessi due punti sulla sfera; quando compila, si ferma da 4s a 6s solo per eseguire i calcoli di quella figura; il rusultato non sarebbe stato possibile 26 o 27 anni fa, tuttavia…