table* e figure* in ambiente multicols

illinguista1972″ post=67950Per scrivere un documento su più colonne ci sono diverse strade.

1.
Dare alla classe in uso l’opzione twocolumn, che produce l’intero documento su due colonne. Per inserire un oggetto galleggiante posso usare table e figure riferiti a \columnwidth per averlo largo quanto la colonna di testo, mentre table* e figure* riferiti a \textwidth per averlo largo quanto la giustezza della gabbia definita dalla classe.

Giusto, per me. Occhio che un autore potrebbe volere una figura larga metà colonna, e allora la includerà con
`\begin{figure}
\includegraphics[width=0.5\columnwidth]{…}
…
`
oppure una figura larga il 70 per cento della pagina, e allora scriverà
`\begin{figure*}
\includegraphics[width=0.7\textwidth]{…}
…
`
Nella frase che hai appena scritto questa possibilità non è immediata, forse.

illinguista1972″ post=67950
2.
Dare la dichiarazione \twocolumn per avere su due colonne solo la parte di documento che la segue, con lo svantaggio che la parte a due colonne va in una pagina nuova.

Nell’Arte non lo direi. Il nostro lettore ideale compone a tutta pagina aut (più raramente) su più colonne. Un documento “ibrido” potrà anche servire in qualche caso, ma il nostro lettore ha esigenze più delimitate. Ecco, un caso potrebbe essere voler scrivere, in un articolo su una colonna, l’indice su due colonne: lì però userei senz’altro multicols (anche) per avere il bilanciamento.

illinguista1972″ post=679503.
Il pacchetto multicol e l’ambiente multicols. Per inserire un oggetto mobile posso usare table e figure riferiti a \columnwidth per averlo largo quanto la colonna, ma table* e figure* sembrano funzionare in modo particolare.

Da quanto ricordo, direi che non funzionano: è una limitazione (un difetto) del pacchetto multicols.

Ma aspettiamo pure i più esperti!

illinguista1972″ post=67961Dal manuale di Lamport:

C.9.1 Figures and Tables
These environments produce floating figures and tables. In two-column format, the ordinary forms produce single-column figures and tables and the *-forms produce double-column ones. The two forms are equivalent in single-column format. The body is typeset in a parbox of width \textwidth.

Non si fa menzione di \columnwidth.

Si attendono lumi 🙂

Ciao
Tommaso

E perché dovrebbe menzionarlo lì? \columnwidth è il parametro che contiene la larghezza della colonna di testo; ognuno è libero di usarlo dove gli pare. Viene menzionato \textwidth perché è rilevante nella discussione.

Ciao
Enrico

Vediamo un po’ di capire la differenza che c’è tra introdurre un oggetto con
`\begin{figure}
\includegraphics[width=\columnwidth]{…}
…
`oppure con
`\begin{figure}
\includegraphics[width=\textwidth]{…}
…
`
Se si sta scrivendo (come di si fa di solito) su una sola colonna di composizione, non c’è differenza: \columnwidth e \textwidth coincidono. Però immaginiamo di voler trasformare il nostro documento scritto per una colonna in uno a due colonne. Se abbiamo usato la seconda forma, quello che otteniamo è un errore (l’ambiente figure, in un ambiente a due colonne, piazza l’oggetto sulla colonna di composizione, ma ora quel \textwidth fa sì che sia troppo largo per starci): dobbiamo sicuramente correggere, per esempio trasformando l’ambiente figure in figure*, oppure cambiando quel \textwidth in \coumnwidth.

Invece se abbiamo usato la prima forma (quella con \columnwidth) il codice va bene (almeno dal punto di vista sintattico): la figura sarà questa volta larga tutta la colonna.

Naturalmente, anche se abbiamo usato la forma con \columnwidth è (molto) probabile che dobbiamo fare comunque degli aggiustamenti: se una figura a tutta pagina è leggibile, magari non lo sarà più se larga una colonna. Però in questo caso la correzione è “solo” (molto) probabile, non sempre necessaria: in altre parole, spesso dovremmo correggere il codice, ma magari non sempre. Ecco perché usare \coumnwidth è leggermente meglio che usare \textwidth.

Almeno, io l’ho capita così! 😉

In definitiva, è una questione i lana caprina: se abbiamo scritto un documento per una colonna e vogliamo rivoluzionarlo mettendolo su due, gli oggetti inserirti andranno comunque esaminati tutti, uno per uno, per vedere se con la nuova impaginazione le dimensioni lo rendono leggibile. Quella preferenza per \columnwidth è più che altro una questione di voler spaccare il capello in 4. 😉

Secondo me stiamo confondendo due concetti importanti (tranne Enrico, che però è stato telegrafico).

Una cosa è dire che l’oggetto mobile è largo \columnwidth oppure \textwidth; un’altra è dire che l’immagine che è stata inserita delntro l’oggetto mobile ha ampiezza \columnwidth o \textwidth.

Lamport nella sua spiegazione dice che figure* e table* sono composti dentro una scatola \parbox larga \textwidth; ta parlando di oggetto mobile, non dell’immagine che vi è contenuta. e volendo si potrebbe scalare questi’ultimo a una frazione di \hsize, che è la giustezza dentro la scatola che forma l’oggetto mobile.

Componendo a due colonne gli oggetti obili senza asterisco sono inseriti nella colonna come oggetti mobili inscatolati dentro delle \parbox larghe \columnwidth, mentre quelli asteriscati sono formati da scatole larghe quanto \textwidth; in entrambi i casi si potrebbe poi scalare l’immagine ad una frazione di \hsize.

Naturalmente è sempre meglio non pasticciare con i parametri interni come \hsize !

Ha ragione Lorenzo quando sottolinea che se venisse in mente di cambiare impaginazione da una colonna a due colonne bisogna comunque rivedere tutto quanto per essere sicuri dhe le immagini rimpicciolite a causa del fattore di scala rispetto a \columnwidth siano ancora leggibili. Ma questo è un altro punto.

L’idea principale è che il layout di pagina deve essere scelto in anticipo e non a “metà dell’opra”, poi riferirsi a \columnwidth o a \textwidth potrebbe non avere più una grande rilevanza, se non a due colonne.

Con multicolumn le cose sono diverse, perché in realtà non sono concessi oggetti mobili in colonna, ma solo in testa. Per mettere con multicolum oggetti in colonna bisogna tenerli fissi, oppure interrompere le due colonne e metterli a piena pagina dove si vuole (in testa, al piede, al centro), ma cadono dove le due colonne sono interrotte e l’interruzione non è mobile. In sostanza l’ambiente multicolumn non è adatto per gestire figure e tabelle mobili. Va benissimo per indici generali e analitici, e per pochi altri casi isolati, ma non per comporre un testo in generale; il suo unico vantaggio è quello di pareggiare le colonne quando viene terminato.

Per pareggiare le colonne in composizione twocolumn bisogna agire a mano nella versione finale e definitiva, perché qualunque correzione del testo che vari il numero di righe dell’ultima pagina implica che bisogna spostare il “fine colonna”. Nella classe arstexnica c’è un comando (\balance o \pareggia) che lo fa; ovviamente non è documentato, perché lo usa solo l’editor di ogni fascicolo di AT. Il trucco è quello di inserire un “whatsit”, un altro degli oggetti sconosciuti del nucleo di TeX.

OldClaudio” post=67982Una cosa è dire che l’oggetto mobile è largo \columnwidth oppure \textwidth; un’altra è dire che l’immagine che è stata inserita delntro l’oggetto mobile ha ampiezza \columnwidth o \textwidth.

Questa distinzione, però, non cambia la sostanza. Diciamo che sto scrivendo un documento su due colonne e voglio inserire una figura. I casi sono due:
a) voglio che la figura stia nella colonna di composizione: e allora userò figure, e la cosa più naturale è riferire l’immagine a \columnwidth.
b) voglio che la figura sia a tutta pagina: e allora userò figure*, e la cosa più naturale è riferire l’immagine a \textwidth.

OldClaudio” post=67982Ha ragione Lorenzo quando sottolinea che se venisse in mente di cambiare impaginazione da una colonna a due colonne bisogna comunque rivedere tutto quanto per essere sicuri che le immagini rimpicciolite a causa del fattore di scala rispetto a \columnwidth siano ancora leggibili.

Visto che le cose, in definitiva, stanno così, nell’Arte potremmo anche decidere, quando presentiamo gli oggetti mobili, di riferirci sempre a \textwidth, che mi pare didatticamente più immediato quando si scrive su una colonna (ricordiamo che il nostro principiante è un laureando, che “quindi” scrive la sua tesi su una colonna). Poi, nel paragrafo sulla composizione a più colonne (che è una specialità) facciamo menzione di table* e figure* e di \columnwidth.

E’ solo un’idea, a Tommaso la decisione! 😉

illinguista1972″ post=67985Ho anche letto che figure* e table* producono figure e tabelle non numerate.

O hai letto male oppure chi l’ha scritto aveva bevuto. 🙂

È \caption che produce il numero; figure(*) e table(*) non se ne occupano affatto.

Ciao
Enrico

illinguista1972″ post=67990Bentrovato 🙂

La seconda che hai detto. Il passo incriminato è contenuto in ben due file:

http://www.stat.wvu.edu/~jharner/courses/stat512/LaTeX-and-Friends.pdf

e

http://www.google.it/search?client=safari&rls=en&q=10.1.1.189.1560.pdf&ie=UTF-8&oe=UTF-8&redir_esc=&ei=a-caT4iGPPGK4gSVs5nXDQ#sclient=psy-ab&hl=it&client=safari&rls=en&source=hp&q=dongen+latex&pbx=1&oq=dongen+latex&aq=f&aqi=g-jL1&aql=&gs_sm=e&gs_upl=6278l7794l4l8007l12l8l0l0l0l0l613l2470l2-3.3.0.1l7l0&bav=on.2,or.r_gc.r_pw.,cf.osb&fp=ecd3b99f77e5d1fc&biw=1280&bih=639

che poi sono dello stesso autore. Segnalo che tra qualche settimana il libro di Dongen sarà pubblicato a più di 50 euro.

Birra tra un po’?

Ciao
Tommaso

Mon Dieu!

Ti mando un SMS

Ciao
Enrico

Chiedo scusa, ho preso un abbaglio: all’interno di un ambiente multicols sono gli ambienti table e figure che non funzionano:le varianti asterisco vanno egregiamente. Provare per credere.
`\documentclass[a4paper]{article}
\usepackage{booktabs,lipsum,caption}
\usepackage{multicol}
\begin{document}
\begin{multicols}{2}

\lipsum[1]

\begin{table*}
\caption{Alcalodi.}
\centering
\begin{tabular}{ll}
\toprule
Alcaloide & Origine \\
\midrule
atropina & belladonna \\
morfina & papavero \\
nicotina & tabacco \\
\bottomrule
\end{tabular}
\end{table*}

\lipsum
\end{multicols}
\end{document}
`
Si provino a togliere gli asterischi, e la tabella sparisce. Questo è un grosso problema, che, a mio giudizio, restringe molto la possibilità di usare questo ambiente. Per un testo con tabelle figure non lo consiglierei (ricordo una discussione analoga quando si trattò di scrivere la classe per ArsTaXnica: se ben ricordo multicols fu scartato proprio per l’incompatibilità con gli ambienti per gli oggetti mobili). Quando usare multicols? Io direi solo per un documento esclusivamente testuale (senza tabelle e figure), oppure per scopi particolari (per esempio, per bilanciare le colonne dell’indice analitico).

Ancora, Tommaso, mi ha fatto notare che le varianti asterisco degli ambienti per gli oggetti mobili mettono l’oggetto sempre in cima alla pagina: le preferenze di collocazione vengono ignorate. Ecco, questo non è un vero problema, anzi, va benissimo: in un documento su più colonne un oggetto a piena pagina in mezzo renderebbe la pagina meno leggibile.

In sintesi, che cosa consiglierei al lettore dell’Arte?

1.
Se il documento è su una sola colonna (come accade di regola per il nostro laureando) e si vogliono inserire tabelle e figure mobili, si usino gli ambienti standard table e figure riferendoli (quando necessario) a \textwidth.

2.
Se il nostro lettore vuole scrivere su due colonne, può usare l’opzione globale twocolumn: gli ambienti table e figure (da riferire, quando necessario, a \columnwidth) piazzano l’oggetto sulla colonna di composizione. Ci sono anche le relative varianti asterisco (da riferire a \textwidth quando necessario), che piazzano l’oggetto a tutta pagina, sempre in cima (le eventuali preferenze di collocazione vengono ignorate). Le colonne di un documento scritto così non vengono bilanciate.

3.
Esiste anche l’ambiente multicols del pacchetto multicol che serve per scrivere su (due o) più colonne con bilanciamento. Il bilanciamento è bello, la possibilità di scrivere su tre o più colonne può essere cool, ma si paga un prezzo: gli ambienti table e figure non funzionano più (anche se table* e figure* funzionano ancora), cosa che in definitiva rende sconsigliabile l’uso di questo strumento per un documento con tabelle e figure. Usare muticols va dunque bene o per un documento di solo testo, oppure per scopi particolari (per bilanciare le colonne dell’indice analitico, per esempio).

Ora dovremmo esserci! 😉

Ancora, Tommaso, mi ha fatto notare che le varianti asterisco degli ambienti per gli oggetti mobili mettono l’oggetto sempre in cima alla pagina: le preferenze di collocazione vengono ignorate. Ecco, questo non è un vero problema, anzi, va benissimo: in un documento su più colonne un oggetto a piena pagina in mezzo renderebbe la pagina meno leggibile.

Però potrebbe essere utile metterle in basso. Per correggere questo “difetto” di LaTeX e
permettere il posizionamento anche in basso (oltre che in alto e in una pagina a parte),
c’è il pacchetto dblfloatfix. A me è servito più di una volta.

Ciao ciao.
Fra

francesco.biccari” post=68054Però potrebbe essere utile metterle in basso. Per correggere questo “difetto” di LaTeX e
permettere il posizionamento anche in basso (oltre che in alto e in una pagina a parte),
c’è il pacchetto dblfloatfix. A me è servito più di una volta.

Non lo sapevo. Ho guardato la doc. del pacchetto. Questo punto non mi è chiaro:

floats in a twocolumn document come out in the right order

Che vuol dire che senza il pacchetto i float vengono messi nell’ordine sbagliato?

Un’altra domanda: cmi fai un esempio in cui ti è stato utile avere un oggetto “in basso”?

Grazie,
L.

P.S. Il punto 2, se decidiamo di menzionare il pacchetto, diventerebbe qualcosa come:

2.
Se il nostro lettore vuole scrivere su due colonne, può usare l’opzione globale twocolumn: gli ambienti table e figure (da riferire, quando necessario, a \columnwidth) piazzano l’oggetto sulla colonna di composizione. Ci sono anche le relative varianti asterisco (da riferire a \textwidth quando necessario), che piazzano l’oggetto a tutta pagina, sempre in cima o in una pagina di soli oggetti mobili (mai in basso, a meno che non si carichi anche il pacchetto dblfloatfix). Le colonne di un documento scritto così non vengono bilanciate.

illinguista1972″ post=68058Vuol dire che se in un documento twocolumn hai oggetti a piena pagina e oggetti nelle colonne, probabilmente quelli che inserisci con figure* dopo quelli con figure verranno messi prima, e dunque in una pagina potresti avere in alto la figura 14 a piena pagina, mentre in basso la figura 13.

Brutta storia. Fra l’altro questo confligge con quello che diciamo a proposito degli oggetti mobili, ovvero che LaTeX rispetta sempre l’ordine in cui vengono inseriti. A questo punto direi che dblfloatfix va senz’altro caricato, se si scrive un documento su più colonne con figure e/o tabelle mobili.

illinguista1972″ post=68058Non dimentichiamo che in un ambiente multicols si possono mettere oggetti larghi quanto la colonna con float e H. Il problema è che si avranno delle grane, perché di fatto non sono oggetti galleggianti.

Dimentichiamocelo, invece! Non consiglierei al nostro principiante di usare sistematicamente float: è uno strumento (lo diciamo altrove) da usare eccezionalmente, e solo per ottenere effetti particolari di impaginazione.

In conclusione, la mia idea è di procedere come altre volte facciamo nell’Arte:
1. dando senz’altro per caricato un pacchetto che ci toglie un bel po’ di castagne da fuoco (dblfloatfix, in questo caso; altre volte abbiamo fatto lo stesso con caption, booktabs, amsmath, amsthm, eccetera);
2. rinunciando alla completezza: della possibilità di usare float è bene che noi ne siamo al corrente, mentre non presenterei questa informazione al nostro lettore.

(Ri)provo a sintetizzare.

1.
Se il documento è su una sola colonna (come accade di regola per una tesi) e si vogliono inserire tabelle e figure mobili, si usino gli ambienti standard table e figure riferendoli (quando necessario) a \textwidth.

2.
Per scrivere su due colonne si può usare l’opzione globale twocolumn: gli ambienti table e figure (da riferire, quando necessario, a \columnwidth) piazzano l’oggetto sulla colonna di composizione.

Ci sono anche le relative varianti asterisco (da riferire a \textwidth quando necessario), che piazzano l’oggetto in cima, in basso o in una pagina di soli oggetti mobili, mantenendo nel documento finito l’ordine con cui tabelle e figure sono inserite nel sorgente (a condizione però che sia caricato il pacchetto dblfloatfix, che consigliamo senz’altro). Si noti che le colonne di un documento così composto non vengono bilanciate.

3.
Esiste anche l’ambiente multicols del pacchetto multicol che serve per scrivere su (due o) più colonne con bilanciamento. Il prezzo da pagare per questa possibilità è che gli ambienti table e figure non funzionano più (table* e figure*, invece, si possono usare), cosa che in definitiva rende sconsigliabile l’uso di questo strumento per un documento con tabelle e figure. in definitiva, l’uso di muticols è indicato per comporre documenti di solo testo oppure per scopi particolari (per bilanciare le colonne dell’indice analitico, per esempio).

Che te ne pare? 😉

Ciao Lorenzo,

per la numerazione ti ha correttamente risposto Tommaso.

I casi in cui ho usato figure* in basso sono tutti casi di pura estetica. Niente
di eccezionale e anzi opinabili. Per esempio quando ci sono due o più oggetti mobili
per pagina, di cui almeno uno è di tipo figure* o table*, averli tutti in cima alla
pagina fa “cozzare” le didascalie tra di loro. Immagina una tabella (table)
nella colonna e una figura sopra di essa larga due colonne (figure*).
Tu mi dirai “metti la tabella in basso”. A volte è possibile, è vero, ma spesso
si vuole che la tabella sia sì fuori testo ma il più vicino possibile a dove la
si cita e discute.

Questo affollarsi di oggetti mobili negli articoli scientifici di tipo sperimentale
spesso capita, soprattutto quando l’articolo deve essere al massimo di 3 pagine
e ci devi mettere svariate tabelle e figure!

Ciao ciao.
Fra

francesco.biccari” post=68061I casi in cui ho usato figure* in basso sono tutti casi di pura estetica. Niente
di eccezionale e anzi opinabili. Per esempio quando ci sono due o più oggetti mobili
per pagina, di cui almeno uno è di tipo figure* o table*, averli tutti in cima alla
pagina fa “cozzare” le didascalie tra di loro. Immagina una tabella (table)
nella colonna e una figura sopra di essa larga due colonne (figure*).
Tu mi dirai “metti la tabella in basso”. A volte è possibile, è vero, ma spesso
si vuole che la tabella sia sì fuori testo ma il più vicino possibile a dove la
si cita e discute.

Questo affollarsi di oggetti mobili negli articoli scientifici di tipo sperimentale
spesso capita, soprattutto quando l’articolo deve essere al massimo di 3 pagine
e ci devi mettere svariate tabelle e figure!

Ciao Francesco, la tua spiegazione è del tutto convincente. Mi pare di averne tenuto conto nella (bozza di) sintesi che ho appena proposto: dimmi pure se c’è qualcosa che cambieresti.

Grazie mille! 🙂

lorenzo.pantieri” post=68062

I casi in cui ho usato figure* in basso sono tutti casi di pura estetica. Niente
di eccezionale e anzi opinabili. Per esempio quando ci sono due o più oggetti mobili
per pagina, di cui almeno uno è di tipo figure* o table*, averli tutti in cima alla
pagina fa “cozzare” le didascalie tra di loro. Immagina una tabella (table)
nella colonna e una figura sopra di essa larga due colonne (figure*).
Tu mi dirai “metti la tabella in basso”. A volte è possibile, è vero, ma spesso
si vuole che la tabella sia sì fuori testo ma il più vicino possibile a dove la
si cita e discute.

Questo affollarsi di oggetti mobili negli articoli scientifici di tipo sperimentale
spesso capita, soprattutto quando l’articolo deve essere al massimo di 3 pagine
e ci devi mettere svariate tabelle e figure!

Ciao Francesco, la tua spiegazione è del tutto convincente. Mi pare di averne tenuto conto nella (bozza di) sintesi che ho appena proposto: dimmi pure se c’è qualcosa che cambieresti.

Grazie mille! 🙂

Mi sembra che le linee guida esposte sopra siano perfette!
Quindi niente da dire 🙂

Ciao ciao.
Fra