Comportamento anomalo di b5paper… 😕

Nel file di configurazione di pdf viene indicato (di solito da noi in Italia) il formato di default A4.
Quindi benché tu specifichi b5paper comep opzione al documento, quel file di configurazione compone su una carta virtuale in formato A4, anche perché nella quasi totalità dei casi le stampati di cui si dispone , magari capaci di gestire cara B5, di fatto stampano su carta A4 e poi l’utente o la copisteria provvede a passare il blocco delle pagine alla taglierina per riderne il formato; produce sfrido, ma generalmente le copisterie riciclano tutto il riciclabile, compreso lo sfrido.

Infatti in Italia è difficilissimo, quasi impossibile, procurarsi carta B5. Vistiando Fabriano ho chiesto come fosse possibile ottenere tale formato di carta; mi è stato dato l’indirizzo di una cartiera con l’indicazione di rivolgermi a quella cartiera per farmelo fare apposta; Comodo no? Evidentemente ho rinunciato.

Tornando però al sistema TeX, tieni presente che il formato DVI non ha bisogno di conoscere il formato effettivo della carta, perché usa comme coordinate di quel che stampa l’angolo superiore sinistro del foglio. Quindi lavorando con latex (e non con pdflatex) la trasformazione in PDF (dove le coordinate hanno l’origine nell’angolo inferiore sinistro del foglio) è necessario specificare il formato del foglio al programma di trasformazione, che sia fvips_pstopdf o dvipdfm non ha importana.

Lavorando direttamente con pdflatex, l’opzione b5paper riguarda solo l’impaginazione, ma il formato della carta è quello specificato nel file di configurazione. Ma si può ovviare; come al solito la modalità è descritta nella documentazione (di geometry), ma la via più semplice è semplicemente quella di invocare geometry cona la sola opzione b5paper,perché ci pensa geometry a inviare a pdflatex l’informazione sul formato della carta reale. Oppure si unsano classi diverse da book; cito fra le tante memoir e scrbook.

Una via alternativa è quella di inserire nel preambolo un paio di comandi come questi`\pgfpagewidth=\paperwidth
\pdfpageheigth=\paperheight` Questi due statement non hanno nessuna ( onon dovrebbero avere) influenza se se si lavorasse con latex, perché non se ne fa niente di questa informazione, invece che con pdflatex, lualatex, o xelatex, ma sono sicuro che funzionino benissimo con gli ultimi tre programmi.

In sostanza anche con pdflatex, l’opzione di formato riguarda solo l’impaginazione (griglia del testo, testatine, piedini, note marginali, margini ai quattrolati della pagina, eccetera) non le dimensioni della carta reale che va esplitata direttamante con quei due comandi o indirettamente tramite geometry o delle classi che ci pensano da sole.

Mi stupisco, quindi, di quello che dici a proposito degli altri file che con quello stesso preambolo producono l’uscita sul formato giusto; forse non si tratta dello steso identico preambolo; forse si è invocato qualche altro pacchetto che ha provveduto a fornire il formato giusto all’interprete pdftex. Forse in questo sei passato attraverso il formato DVI, magari hai usato uno di quei bottoni dell’editor che compilano in formato DVI e poi, quando tutto è pronto e trasformano il file DVI in un file PDF.
Che cosa hai fatto epr davvero lo sai solo tu. quindi rivedi la tua procedura alla luce delle spiegazioni che ti ho dato.

Nota che io non uso latex e il formato DVI da anni, quindi so per certo quello che dico a proposito di pdflaTeX, lualatex e xelatex.

Indrjo Dedej” post=112699Allora da quello che mi dici, mi è sfuggito qualcosa. Avrò usato qualche combinazione di comandi che avrà fatto in modo che le cose andassero così. Ti riporto il preambolo di un mio precedente lavoro, in cui la carta virtuale è in formato B5 – o almeno a me esce così.
[…]

Affinché pdfTeX imposti le dimensioni della «carta virtuale» a valori (diversi da quelli di default e) tali da riflettere le dimensioni specificate tramite un’opzione di formato pagina come [tt]b5paper[/tt], è (necessario e) sufficiente che le due «righe magiche» di codice che ti ha già indicato @OldClaudio, e cioè
`
\pgfpagewidth =\paperwidth
\pdfpageheigth=\paperheight
`
(o, equivalentemente,
`
\setlength{\pdfpagewidth} {\paperwidth}
\setlength{\pdfpageheight}{\paperheight}
`
se vogliamo usare la sintassi del LaTeX), vengano eseguite in un momento qualsiasi compreso fra l’esecuzione dell’opzione di formato stessa e l’istante in cui (pdf)TeX decide di inviare la prima pagina al file d’uscita. In pratica, questo vuol dire un momento qualsiasi compreso fra una fase alquanto precoce del caricamento della classe di documento e un evento che si verifica a documento già iniziato, cioè addirittura dopo il [tt]\begin{document}[/tt]. Durante questo ampio intervallo possono succedere molte cose, e in particolare vengono caricati non solo i pacchetti che l’utente finale indica direttamente nel preambolo, ma anche i pacchetti da questi richiesti tramite [tt]\RequirePackage[/tt], i pacchetti richiesti dai pacchetti richiesti dai pacchetti indicati dall’utente e così via ricorsivamente, inclusi gli eventuali pacchetti richiesti dalla classe di documento stessa o da classi di base che essa carica con [tt]\LoadClass[/tt], ecc.; inoltre, parecchi pacchetti caricano dei loro specifici file di configurazione, file di definizione contenenti drivers appropriati per lo specifico «motore» di tipocomposizione usato, e così via. In una parola, non è affatto raro che vengano eseguiti parecchie decine, o perfino qualche centinaio, di file, della maggior parte dei quali l’utente finale non è neppure ben consapevole. Se soltanto uno di questi file contiene le «righe magiche» sopra menzionate, la «carta virtuale» verrà impostata in modo da riflettere le dimensioni della pagina, sovrascrivendo le dimensioni di default (che, in Europa, sono quasi sempre quelle di [tt]a4paper[/tt]).

Ora, si dà il caso che i pacchetti che eseguono quelle «righe magiche» non siano pochissimi, e siano anche fra i più usati da chi vuol produrre un’uscita in formato PDF (a dire il vero, più che direttamente nel codice del pacchetto, le «righe magiche» sono contenute in un driver, specifico per il «motore» pdfTeX, che il pacchetto richiama, ma questo non ha importanza qui): andando a memoria, e quindi con il rischio di sbagliare, elencherei fra questi:

• i pacchetti del graphics bundle, come graphics/x e color;
• i pacchetti grafici per figure, come pict2e;
• il pacchetto hyperref;
• naturalmente, il pacchetto geometry.

È assai probabile che ve ne siano diversi altri che ora, su due piedi, non mi vengono in mente. Tutto ciò considerato, si può ben capire che non è affatto impossibile che un utente possa usare il LaTeX (con uscita PDF) per anni prima che gli capiti di comporre un documento il quale, per puro caso, non richiami, nemmeno indirettamente, alcun pacchetto che esegua le «righe magiche» menzionate all’inizio, e quindi lo stupisca per il fatto di non impostare le dimensioni della «carta virtuale», contrariamente a ciò che quell’utente aveva visto succedere in tutti i suoi documenti precedenti. Questo è tanto più vero, se la gran maggioranza dei documenti che quell’utente compone usano il formato di pagina di default, dato che in tal caso è del tutto indifferente che le «righe magiche» vengano eseguite o meno.

Questo basti per quanto riguarda le spiegazioni. Veniamo ora ai suggerimenti.

Come alternativa all’inclusione diretta delle «righe magiche» nel preambolo, @OldClaudio suggerisce correttamente di caricare il pacchetto geometry, con l’opzione [tt]b5paper[/tt]. Per amor di chiarezza, però, osserverei quanto segue:

1. Se l’opzione [tt]b5paper[/tt] è già specificata nel comando [tt]\documentclass[/tt], non c’è ovviamente bisogno di ripeterla anche quando si carica geometry (essendo, in tal caso, un’opzione «globale»).
2. Il semplice fatto di caricare il pacchetto geometry, anche senza alcuna opzione, può modificare i margini impostati dalla classe di documento; questo può essere evitato specificando a geometry l’opzione [tt]pass[/tt], nel modo seguente`\usepackage[pass]{geometry}`(ripeto che ciò fa sì che i margini impostati dalla classe siano mantenuti).

Altre — pedanti! 🙂 — osservazioni non collegate alla questione posta:

1. Con la classe book non occorre specificare le opzioni [tt]openright[/tt] e [tt]twoside[/tt], in quanto già implicite per default.
2. Il pacchetto amsfonts viene già caricato automaticamente quando si carica amssymb.
3. mathptmx è un pacchetto piuttosto vecchio: mi è permesso suggerire`\usepackage{newtxtext,newtxmath}`come alternativa?

Ciao.

—
Gustavo

Spiegazione chiarissima, Gustavo; ti confermo che graphics/s, hyperref e ovviamente geometry impostano \pdfpagewidth|height; per color non ho verificato. Invece pict2e è “innocente’, non specifica le dimensioni della carta virtuale.

La puntualizzazione non cambia la sostanza della tua spiegazione, come sempre, lucida e chiarissima.

Confermo e sottoscrivo il pregio dei pacchetti \newtxtext e newtxmath rispetto a mathptmx; M. Sharpe li sta mantenedo e ne sta estendendo la collezione anche ad altri font meno gettonati dei tradizionali Times (chissà perché sono così apprezzati, forse perché sono quelli di default quando si usa Word?…); vorrei segnalare anche i Libertinus e i LibertinusT1math, font molto recenti e innovativi, nel senso che quelli matematici usano font a 256 glifi e forniscono gli stili di scrittura matematica conformi anche alla tradizione francese (ma a noi in Italia non interessa) e lo stile ISO per la fisica e la tecnologia. Sono anche molto belli e non sono “magrolini” come i Times né “panciuti” come i Palatino. Con polizze da 256 caratteri il pericolo di eccedere il limite dei 16 gruppi matematici è praticamente scongiurato rispetto a quando si usano polizze a 128 caratteri.