Punti di spaziatura Indice

Puoi mandare un esempio minimo compilabile che riproduca l’errore? C’è infatti bisogno di vedere il codice sorgente.

Ciao.

—
Gustavo

Da quel che vedo l’esempio non riproduce l’errore.
Fran

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

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

letteracdp” post=101038Carissimi,

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

Se il problema è microtype, allora per l’indice se ne può eliminare l’intervento con una cosa del genere`\begingroup
\microtypesetup{activate=false}
\tableofcontents
\endgroup`racchiudendo il tutto dentro un gruppo in modo che composto l’indice, microtype riprenda a funzionare con la protrusione e l’espansione dei font/caratteri.

OldClaudio” post=101039Se il problema è microtype, allora per l’indice se ne può eliminare l’intervento con una cosa del genere`\begingroup
\microtypesetup{activate=false}
\tableofcontents
\endgroup`racchiudendo il tutto dentro un gruppo in modo che composto l’indice, microtype riprenda a funzionare con la protrusione e l’espansione dei font/caratteri.

Ah, be’, certo, ma questa non è una soluzione: questo è nascondere il problema sotto il tappeto! 🙂 😉 (E in realtà, non è nemmeno necessario disattivare tutto il pacchetto, basta disattivare la protrusione dei caratteri.)

Se c’è un bug in microtype, bisognerebbe correggerlo. Una soluzione sbrigativa potrebbe essere quella di disattivare, appunto, la protrusione dei caratteri negli indici; ma questo comporterebbe la rinuncia a un comportamento che, invece, probabilmente è voluto, proprio per migliorare l’allineamento dei numeri di pagina contro il margine destro. C’è un’alternativa migliore: rilevare, con [tt]\rightmarginkern[/tt], l’ammontare della protrusione e aggiungere, alla sinistra della scatolina che contiene il numero di pagina una crenatura (positiva) esattamente opposta. Le due crenature si compensano e la colla contenente i [tt]\leaders[/tt] “vede” esattamente lo stesso spazio vuoto da riempire, indipendentemente dall’ammontare della protrusione.

Però, ripeto, su questo dovrebbe parlare qualcuno con competenze molto superiori alle mie… 🙂

Tutto ciò si dice, naturalmente, lasciando indelibata la questione se sia giusto oppure no allineare, negli indici, i numeri di pagina al margine destro: se non erro, Bringhurst la considerava un’idiozia. 😀

Ciao.

—
Gustavo

Letteracpd ha ragione quando dice che disabilitare microtype quando si compone l’indice corrisponde a nascondere la spazzatura sotto il tappeto.

Non sono abituato a nascondere la spazzatura sotto il tappeto ma, lo confesso, qualche volta lo faccio con cose “latexiane” per le quali non ho intenzione di consumare tempo per risolverle in modo pulito.

Tuttavia in questo caso riterrei che la disabilitazione delle funzionalità di microtype, sia l’espansione sia la protrusione, dovrebbe essere integrata nel comando \tableofcontents stesso.

Infatti microtype serve essenzialmente per comporre capoversi a pacchetto (assenti nell’indice) per diminuire la spaziatura interparola e mantenere un “colore” più omogeneo al capoverso composto a pacchetto; la protrusione è un modesto trucco per risolvere il problema, mentre l’espansione dei font è quella che svolge la maggior parte del lavoro per una soluzione efficace; peccato che l’espansione funzioni solo se il motore di composizione è pdftex (quindi pdflatex e lualatex) e non funzioni quando il motore di composizione è tex o xetex (latex e xelatex).

Ma, ripeto, negli indici “normali” non ci sono capoversi a pacchetto.

L’altra domanda se sia preferibile l’indice con i puntini e i numeri di pagina allineati a destra, oppure l’indice senza puntini con i numeri di pagina non allineati a destra, non è una domanda a cui si possa dare una risposta precisa, visto che riguarda una questione di stile e non una questione tecnica. Nei secoli in cui si è usata la tipografia meccanica o elettronica per comporre e stampare libri e altri tipi di documenti si sono usati entrambi gli stili ed altri ancora, per esempio, l’intero indice composto a pacchetto (dove forse sarebbe utile microtype), che risulta particolarmente compatto, ma risulta anche particolarmente inutile nelle sua funzione di indicare dove si trovino le informazioni che si stanno cercando.

Bringhurst stigmatizza l’indice composto tipo elenco del telefono, altri trovano che l’indice composto come ne L’Arte di scrivere con LaTeX ad alcuni non piace proprio perché è abituato alla forma tabulare (elenco del telefono).

Personalmente trovo che l’indice alla Bringhurst (e a “L’Arte”) sia più elegante, ma non lo trovo adatto a testi di tipo tecnico-scientifico dove la funzione di navigazione del documento da consultare, non da leggere sequenzialmente, è molto importante. Uso entrambi i tipi di indice per documenti con contenuti e scopi diversi.

Mentre continuo a restare in attesa di un intervento chiarificatore (@egreg9? Dove sei sparito? 🙂 ), provo a riprendere la parola, più che altro per raccontare quel che sto imparando in queste stesse ore. Va però osservato che forse, a questo punto, la discussione andrebbe spostata nella sezione Tipografia.

Nota: Ho preparato questo intervento off-line, senza leggere l’ultimo messaggio di @OldClaudio, che vedo solo ora. Vi prego di tenere presente questo fatto. 🙂

A pagina 24 del manuale pdftex-I.pdf c’è scritto:

If you want to protrude some item other than a character (e. g. a [tt]\hbox[/tt]), you can do so by padding the item with an invisible zero-width character, for which protrusion is activated.

Questo mi aveva indotto a pensare (e concorderete con me che il testo citato induce proprio a ciò) che se una cesura di riga cade subito dopo una [tt]\hbox[/tt], non venga aggiunta alcuna protrusione, e che se, al contrario, si vuole che la scatola protruda nel margine dell’ammontare appropriato per l’ultimo carattere in essa contenuto, bisogna “sollevare” manualmente l’[tt]\rpcode[/tt] di tale carattere nella lista orizzontale esterna, per esempio tramite il trucchetto suggerito.

Pensandoci meglio, però, la cosa appariva priva di senso. Innanzitutto, cosa sarebbe quest’idea di includere un carattere fittizio? Attribuendogli di volta in volta un [tt]\rpcode[/tt] desunto dal [tt]\rightmarginkern[/tt] della scatola interna? Che senso ha? Non sarebbe molto più semplice usare un [tt]\kern[/tt] esplicito? In secondo luogo, nel tracciato che avevo prodotto non c’era nessuna traccia di un tale «invisible zero-width character», e d’altro canto la crenatura responsabile della protrusione, e talvolta del puntino in più, era palesemente inserita “a livello macchina” (crenatura implicita, e — soprattutto! 🙂 — chiaramente etichettata come [tt](right margin)[/tt]).

Poiché non capivo, ho provato a fare degli esperimenti. È risultato non solo che pdfTeX, al contrario di quel che il manuale mi aveva indotto a credere, applica la crenatura per la protrusione anche se in fin di riga c’è una [tt]\hbox[/tt], “sollevando” automaticamente (anzi, quasi automagicamente, visto quel che sto per dire) l’[tt]\rpcode[/tt] dell’ultimo carattere al suo interno, ma anche che lo fa con notevole pertinacia (e pervicacia). Esaminando le liste prodotte ho infatti constatato che la crenatura di protrusione di un carattere che nella stampa risultante venga effettivamente a trovarsi in fin di riga viene inserita indipendentemente da:

1. la profondità alla quale tale carattere è annidato dentro [tt]\hbox[/tt], e.g.,`…resto della riga, ultima \hbox{\hbox{…\hbox{parola.}…}}`
2. l’interposizione di scatole vuote, e.g.,`…resto della riga, ultima parola.\null`
3. l’interposizione di crenature di larghezza nulla, e.g.,`…resto della riga, ultima parola.\kern\z@`
4. l’interposizione di scatole contenenti crenature o colla di larghezza nulla, e.g.,`…resto della riga, ultima parola.\hbox{\hskip\z@skip}`
5. combinazioni dei punti precedenti.

Quindi, con quello che succede ad @Antilia il pacchetto microtype non c’entra per niente, o meglio, c’entra solo nella misura in cui attiva la protrusione: non interviene intenzionalmente per garantire che la protrusione si applichi anche ai numeri di pagina dell’indice, perché lo fa autonomamente pdfTeX.

Una volta capito che microtype non ha “colpe”, si può cercare di implementare una soluzione del problema. Come ho detto nel mio messaggio precedente, la mia prima idea è stata quella di preservare la protrusione del numero di pagina, compensandola alla sinistra dello stesso. Ho provato con il programma seguente, da includere subito prima di [tt]\tableofcontents[/tt]:
`
\@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{%
\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
}
`
Purtroppo, non funziona. 🙁 Non capisco perché, ma non c’è verso di prelevare, con [tt]\rightmarginkern[/tt], l’ammontare della protrusione. Sembra, semplicemente, che tale sequenza di controllo non funzioni come documentato (si espande sempre a [tt]0pt[/tt]). Sto sbagliando qualcosa, ma cosa? (@egreg9…?)

Comunque, forse non è così grave: ripensandoci, visto che uno si dà pena di incolonnare i numeri di pagina, non ha molto senso, dopo, distruggere quest’incolonnamento applicando ai numeri stessi protrusioni che risultano diverse tra loro! Quindi, in conclusione, mi sto convertendo alla semplice soluzione di @OldClaudio (osservo che va sempre a finire così… 😉 ), cioè`\begingroup
\microtypesetup{protrusion=false}
\tableofcontents
\endgroup`e buonanotte! 🙂

Visto cosa può venir fuori da un semplice puntino in più? 😀

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

Ultimi aggiornamenti sulla questione.

Ho chiesto lumi su TeX.SX. Un utente che sembra abbastanza accreditato condivide il mio parere che, partendo da un semplice puntino in più, @Antilia abbia permesso di individuare un piccolo, ma insidioso bug del compilatore pdftex. Vedremo se giungeranno altri pareri e, qualora questi eventuali pareri confermassero il sospetto, come segnalare il bug al team di sviluppo di pdftex.

Ciao.

—
Gustavo