letteracdp

claudio” post=101081ho risolto così
`
\documentclass{article}
\begin{filecontents*}{elenco4.csv}
n;citazione
1;A bene placito
2;A capite ad calcem
3;A cruce salus
4;A Deucalione
5;A fortiori ratione
6;A latere
7;A mari usque ad mare
8;A mortuo tributum exigere
9;A pedibus usque ad caput
10;A posse ad esse non valet consequentia
11;A quo
12;Ab aestu et tempestate
13;Ab aeterno
14;Ab antiquo
15;Ab assuetis non fit passio
16;Ab epistulis
17;Ab hoc et ab hac
18;Ab illo tempore
19;Ab imis
20;Ab immemorabili
\end{filecontents*}
%\usepackage[first=1, last=20,counter=die]{lcg}
\usepackage[utf8]{inputenc}
\usepackage{datatool}
\DTLsetseparator{;}
\DTLloaddb{myDB}{elenco4.csv}
\newcommand{\cesare}[1]{%
\ifthenelse{#1<\DTLrowcount{myDB}}{% \DTLforeach {myDB} {\n=n,\citazione=citazione}{% \ifthenelse{\DTLiseq{\n}{#1}} {\citazione} {}% }% }{}}% % \newcommand{\oracolo}{ \cesare{\pdfuniformdeviate 20}} \begin{document} come disse \cesare{15} faremo \oracolo \end{document} ` il problema è la funzione per il random che è compilatore dipendente che usare in alternativa? ciao claudio

Ottimo. Ma perché fare ogni volta un ciclo attraverso la base di dati? Usa [tt]\dtlgetrow[/tt]:
`
\documentclass{article}
%\usepackage[first=1, last=20,counter=die]{lcg}
\usepackage[utf8]{inputenc}
\usepackage{datatool}
\DTLsetseparator{;}
\DTLloaddb{myDB}{elenco4.csv}
\newcommand{\cesare}[1]{%
\ifthenelse{#1<\DTLrowcount{myDB}}{% \dtlgetrow{myDB}{#1}% \dtlgetentryfromcurrentrow{\citazione}{2}% \citazione }{}% }% % \newcommand{\oracolo}{ \cesare{\pdfuniformdeviate 20}} \begin{document} come disse \cesare{14} faremo \oracolo \end{document} ` Appare verosimile (ma non lo so con certezza) che la primitiva [tt]\pdfuniformdeviate[/tt] restituisca numeri pseudo-casuali di qualità superiore al semplice generatore a congruenza lineare usato dal pacchetto lcg (che è poi esattamente lo stesso che si trova nel vecchio [tt]random.tex[/tt]); tuttavia, poiché la qualità del generatore non è un parametro critico per un’applicazione come questa 🙂 , penso che tu possa usare tranquillamente lcg, che impiega soltanto l’aritmetica intera presente su ogni compilatore TeX.

Attento, però, che`\pdfuniformdeviate 20`ritorna un intero compreso fra 0 e 19, non fra 1 e 20.

Ciao.

—
Gustavo

Carissimi,

svelato l’arcano! 🙂 Innanzitutto, ho trovato questo bug report che sembrava proprio fare centro; peccato, però, che l’errore fosse stato già risolto nella versione 1.40.11. Ho fatto un tentativo, aggiungendo una seconda riga fittizia al «preflight», riga che poi cestinavo (assieme a interline glue e widow penalty precedenti), e con questa correzione già l’“incantesimo”, finalmente, funzionava! 🙂 Ma poi mi si è accesa un’altra lampadina: non avevo azzerato [tt]\parfillskip[/tt]! Facendolo, l’aggiunta della riga in più diventava inutile. In definitiva, la “cura” che potrebbe (ma vedi sotto) essere proposta per eliminare il puntino spurio è la seguente:
`
\@ifdefinable\@DTLfix@saved@kern{}
\def\@dottedtocline#1#2#3#4#5{%
\ifnum #1>\c@tocdepth \else
\vskip \z@ \@plus.2\p@
% Preflight: typeset a fake toc entry in a temporary \vbox, which is just
% an empty line with the line number at the far right.
\setbox\z@ \vbox{%
\parfillskip \z@skip
\indent\nobreak\hfill
{\normalfont \normalcolor #5}\par
% Save \rightmarginkern of the last (and unique) \hbox.
\setbox\z@ \lastbox
% Diagnostics:
% \showboxbreadth = 1000
% \showboxdepth = 3
% \showbox\z@
% \typeout{\rightmarginkern\z@}%
\xdef\@DTLfix@saved@kern{\rightmarginkern\z@}%
}%
% Now do the actual typesetting of the entry.
{\leftskip #2\relax \rightskip \@tocrmarg \parfillskip -\rightskip
\parindent #2\relax\@afterindenttrue
\interlinepenalty\@M
\leavevmode
\@tempdima #3\relax
\advance\leftskip \@tempdima \null\nobreak\hskip -\leftskip
{#4}\nobreak
\leaders\hbox{$\m@th
\mkern \@dotsep mu\hbox{.}\mkern \@dotsep
mu$}\hfill
\nobreak
\kern -\@DTLfix@saved@kern
\hb@xt@\@pnumwidth{\hfil\normalfont \normalcolor #5}%
\par}%
\fi
}
`

Rimangono però due questioni, anzi tre:

1. La comparsa del puntino addizionale è un bug: su questo, personalmente, non ho dubbi. Se si decidesse di correggerlo nel modo sopra descritto, dove andrebbe incluso il codice per il “rattoppo” di [tt]\@dottedtocline[/tt]?
2. Rimane, secondo me, un bug in pdfTeX: la presenza della [tt]\parfillskip[/tt] glue non nulla non inibisce la protrusione dell’ultima riga del capoverso (e invece, probabilmente, dovrebbe), ma ciò nonostante provoca l’azzeramento di [tt]\rightmarginkern[/tt].
3. In ogni caso, io continuo a preferire la soluzione di @OldClaudio, cioè sopprimere la protrusione nell’indice. 😉

Qualche suggerimento?

(Ma sinceramente: interessa a qualcuno tutto ciò? O sto parlando da solo? 😀 )

Ciao.

—
Gustavo

Scusa, avevo capito male: il [tt]\clearpage[/tt] serve, ovviamente, proprio a scaricare tutte le figure nel punto in cui lo dai.

Per quel che vuoi fare tu, invece, la soluzione mi sembra ovvia: sposta il codice sorgente delle figure alla fine del capitolo… 🙂

Ciao.

—
Gustavo

ernded” post=101052Compilando un file che contiene 23 figure che, per vari motivi, vorrei mettere alla fine del capitolo con l’opzione [p] latex si ferma con l’errore `Too many unprocessed float.`
Forzando la compilazione con l’opzione s genera un tot di pagine di figure ma non me le mette tutte.
Quindi c’è un massimo di ambienti flottanti che gestisce
Mi chiedo se è un problema di “numero” di figure (non più di tot – e allora qual’è questo tot?) o di “peso” delle stesse, cioè se riesco ad alleggerirne qualcuna poi me le accetta tutte?
Oppure è una questione di RAM del mio Mac?
Grazie
ciao
Ernesto

No, il problebma è proprio nel numero delle figure: al momento sono costretto ad andare a memoria, ma mi pare che il massimo sia di 18 figure in coda. Metti`\clearpage`dopo la diciottesima figura o giù di lì.

Ciao.

—
Gustavo

Vedere solo il preambolo in generale serve a poco, e in questo caso specifico, direi, a niente: dovresti mandare un Esempio Minimo Compilabile (EMC), cioè un Esempio che noi si possa compilare (Compilabile) per riprodurre il comportamento che lamenti, e che sia il più corto possibile (Minimo), per ovvie ragioni.

In particolare, l’essere compilabile implica che il codice deve essere completo di tutto, da [tt]\documentclasss[/tt] a [tt]\end{document}[/tt].

Comunque, tieni presente che LaTeX lascia protrudere una parola fuori dal margine di una singola riga (tipicamente) quando non riesce a dividere un capoverso in linee secondo i suoi rigidi criteri estetici. Ciò può capitare quando il capoverso contiene oggetti indecomponibili e troppo lunghi, come una lunga parola che non può essere sillabata (capita spesso se la parola è scritta con un carattere a spaziatura fissa per il quale la sillabazione è espressamente disabilitata) o una complessa formula matematica in testo. Probabilmente è questo quel che ti succede. I rimedi sono descritti in tutte le guide di base e, se ne hai il tempo, di consiglio di spendere un paio d’ore per leggere, per esempio, la classica guida di Pantieri e Gordini che trovi nella sezione Documentazione di questo sito.

Ciao.

—
Gustavo

Carissimi,

la questione si sta rivelando interessante. 🙂 Premetto che non sono un esperto di microtipografia e so molto poco delle primitive che pdfTeX mette a disposizione a questo riguardo e del modo in cui il pacchetto microtype le utilizza; quindi il contributo che posso dare è solo di fornire un indizio che, ritengo, mette sulla strada giusta, per poi cedere la parola a chi ne sa più di me.

Analizzando con [tt]\showlists[/tt] le scatole prodotte dal file [tt].toc[/tt] fornito da Antilia (mille grazie per la collaborazione 🙂 ), si vede che le righe anomale contengono, in corrispondenza del margine destro, un implicit kern etichettato come [tt]right margin[/tt] (per esempio,`.\kern-0.9566 (right margin)`per la riga del paragrafo intitolato «bla bla»): si tratta del piccolo spazio negativo che pdfTeX introduce alla fine delle righe, in corrispondenza dei margini, quando è attivata la protrusione dei caratteri. Per il carattere «1» del font utilizzato, la protrusione ammessa è insolitamente alta (quasi 1pt), ed è significativamente maggiore di quella ammessa per le altre cifre: ciò fa sì che i numeri di pagina che terminano con «1» siano insolitamente spostati verso destra, appunto per farli sporgere dal margine, e questo causa la comparsa del puntino addizionale. Ciò è del tutto indipendente dalla lunghezza del titolo mostrato sulla riga, come invece avevo scioccamente congetturato in precedenza.

A conferma di questa interpretazione, il difetto scompare se si imposta a zero l’[tt]\rpcode[/tt] di 1 nel font in questione; per esempio, sostituendo`\tableofcontents`con`\begingroup
\rpcode\font`1=0
\tableofcontents
\endgroup`il difetto dovrebbe sparire.

Ora, in realtà, le cose non possono essere così semplici, perché il numero di pagina è contenuto in una piccola [tt]\hbox[/tt], non direttamente nel capoverso che costituisce la voce dell’indice (sì, le voce dell’indice sono composte come capoversi, non come semplici [tt]\hbox[/tt]’es), quindi qui deve entrarci lo zampino di microtype a “sollevare” l’[tt]\rpcode[/tt] da dentro la scatolina del numero di pagina al capoverso che si sta componendo; ma su questo, appunto, cedo la parola a chi conosce i dettagli del funzionamento di microtype per un’analisi più approfondita. Il punto è che, dipendendo da microtype, il comportamento indesiderato dovrebbe poter essere corretto. Insomma, sto dicendo che Antilia ha forse scoperto un bug molto insidioso del pacchetto microtype.

Un ultimo commento. Ovviamente, modificare [tt]\@dotsep[/tt] cambia lo spazio fra i puntini e quindi la piccola differenza di posizionamento del numero di pagina non fa più “scattare” un puntino addizionale: ciò infatti succede quando tale piccola differenza va a sommarsi a una “frazione di puntino” già prossima a uno (se così posso esprimermi). Questo rimedio, però, non impedisce che il problema possa ripresentarsi, per esempio, con una diversa larghezza della gabbia del testo.

Ciao.

—
Gustavo

franen” post=101019Da quel che vedo l’esempio non riproduce l’errore.
Fran

Confermo: neanch’io vedo l’errore con l’esempio inviato, nemmeno aggiungendo altri titoli di paragrafo ([tt]\section[/tt]; finché si mette un titolo solo per ogni gruppo, è più difficile fare raffronti… 🙂 )

È assai probabile che il comportamento anomalo si produca solo quando i titoli contengono un determinato testo; a me, però, non si presenta nemmeno dando come titolo «Il caos organizzato nei prezzi di mercato» alla sezione 2.1.

Un’altra cosa che potresti provare a fare è inviare il contenuto del file .toc, e magari anche del file .aux (quest’ultimo, però, rischia di essere voluminoso), prodotti da un “lancio” di LaTeX in cui si verifichi l’errore.

Ciao.

—
Gustavo

Ringrazio OldClaudio per la spiegazione che giudico di chiarezza davvero esemplare; in particolare è perfettamente calzante l’osservazione seguente:

OldClaudio” post=101011[…]
Usare il pacchetto float e il codice H non è più economico che caricare il pacchetto caption e il suo comando \captionof; Il pacchetto float serve davvero se si vogliono definire altre tipologie di oggetti mobili, non per usare H.

Si può forse solo osservare che l’opzione [tt]H[/tt] del pacchetto float ha il piccolo vantaggio di assicurare, in modo automatico, l’uniformità della spaziatura verticale dell’oggetto mobile/non più mobile inserito ([tt]\intextsep[/tt]).

OldClaudio” post=101011[…]
2) Il codice di posizione h non deve venire mai usato da solo, questo sì è vero e corretto; se lì dove lo si vorrebbe l’oggetto non ci sta, blocca le code degli oggetti flottanti omonimi.

… perché l’oggetto che non ha trovato posto viene, ovviamente, inviato alle code. Perfetto, ora ho capito.

Sono anch’io alla ricerca di capire come funziona l’output routine del LaTeX, da anni, e ogni tanto faccio un passetto avanti. Oggi, per esempio, grazie a OldCaudio ho imparato definitivamente come funziona [tt]H[/tt]: ero già abbastanza convinto che funzionasse così, ma ora lo so con certezza, che è un’altra cosa. Dunque, l’aver riaperto la discussione non è servito a nulla! 🙂

È sempre utile discutere quando ci sono aspetti non completamente chiariti: penso che ora abbiamo un post (quello precedente di OldClaudio) che si possa additare agli utenti del forum come riferimento definitivo circa l’uso dello specificatore [tt]H[/tt].

OldClaudio” post=101011[…]
Gustavo, se trovi che quel che ho scritto sopra ammetta dei controesempi che ne dimostrino la falsità, sono ben contento di rivedere la mia comprensione del meccanismo e te ne ringrazierò moltissimo. […]

Penso che quel che hai detto sia vero e non ammetta controesempi. 🙂 Naturalmente, potremmo sempre essere in errore entrambi… 😉

Ciao.

—
Gustavo