fontenc prima di tutto

Non è proproo così; Enrico nel suo introxelatex.pdf (a quanto pare non nell’ultima versione) proponeva un codice di questo genere per poter usare un font Type 1 al posto di un font OpenType:
`
\usepackage[T1]{fontenc}
\usepackage{fontspec}
\renewcommand{\sfdefault}{pag}
\usepackage{etoolbox}
\cspreto{sffamily }{\fontencoding{T1}}
`
Quindi fontspec è consigliabile che sia caricato per primo, a meno che non si presentino condizioni particolari che richiedano di fare diversamente.
Nota che un esempio volto allo stesso scopo, ma con fontspec caricato per primo, si trova nella documentazione del pacchetto fontspec che propone la seguente soluzione:
`
\documentclass{article}
usepackage{fontspec}
\newfontfamily\unicodefont{Lucida Grande}
\usepackage{mathpazo}
\usepackage[T1]{fontenc}
\begin{document}
A legacy \TeX\ font. {\unicodefont A unicode font.}
\end{document}
`
che, secondo quel che ho capito io, usa di default i font Type 1, ma volendo, può usare anche dei font OpenType; non è proprio la stessa situazione descritta da Enrico nel codice sovrastante, dove di default si usano i font OpenType, e solo per i font sanserif si usa un font Type 1.

Invece Enrico usa in un suo esempio mathpazo, che ricorre a font Type 1, ma solo matematici, con un preambolo fatto così:
`
\documentclass{article}
\usepackage{fontspec}
\usepackage{mathpazo}
\setmainfont{TeX Gyre Pagella}
…
\usepackage{…,amsmath}
`

antonio.macrì” post=65428Tutti sanno o dovrebbero sapere che fontenc va caricato prima di tutti gli altri pacchetti. Qual è il motivo?

Una (vaga) idea è che faccia qualcosa che deve essere fatto prima di caricare altri pacchetti. Vorrei avere maggiori dettagli, magari anche qualche link.

Il punto è questo: non possono sorgere problemi con i pacchetti caricati necessariamente prima di fontenc, cioè nella document class?

Spazziamo via il dubbio, prima di tutto: non ci possono mai essere conflitti di opzioni con fontenc, perché questo pacchetto finge, dopo ogni chiamata, di non essere stato caricato. È quindi buona cosa metterlo per primo (il possibile “pacchetto zero” è etex), in modo da essere sicuri di quale sia la codifica principale di output del documento.

Va messo prima di inputenc perché questo pacchetto esamina le codifiche caricate quando gli si dà l’opzione utf8. E babel va messo dopo inputenc perché, con certe lingue, ha bisogno di sapere quale sia la codifica di input.

Ciao
Enrico

antonio.macrì” post=65463Grazie delle risposte.

Per OldClaudio: grazie Claudio, tornerò più avanti sugli esempi che hai riportato.

Spazziamo via il dubbio, prima di tutto: non ci possono mai essere conflitti di opzioni con fontenc, perché questo pacchetto finge, dopo ogni chiamata, di non essere stato caricato. È quindi buona cosa metterlo per primo (il possibile “pacchetto zero” è etex), in modo da essere sicuri di quale sia la codifica principale di output del documento.

Tu parli di conflitti di opzioni, nel senso che si può fare
`
\usepackage[FOO]{fontenc}
…
\usepackage[BOO]{fontenc}`
senza generare “option clash”, giusto?

Certo; gli altri pacchetti darebbero “Option clash”, con fontenc non può succedere.

antonio.macrì

Va messo prima di inputenc perché questo pacchetto esamina le codifiche caricate quando gli si dà l’opzione utf8. E babel va messo dopo inputenc perché, con certe lingue, ha bisogno di sapere quale sia la codifica di input.

Quindi deduco che a essere rigoroso è l’ordine di caricamento dei tre pacchetti fontenc/inputenc/babel. Quello che ancora mi chiedo, però, è se, così come inputenc esamina le codifiche di output caricate, ci sono altri pacchetti che fanno qualcosa di simile. Chessò, mathpazo citato da Claudio o beramono o qualche altro pacchetto che carica font: c’è necessità per qualcuno di essi di venir caricato dopo fontenc?

Alcuni pacchetti per font particolari richiedono la codifica T1; in genere non hanno il supporto per altre codifiche (eventualmente solo la TS1, cioè i simboli testuali aggiuntivi). Se scrivi in russo, per esempio, non caricherai mai mathpazo da solo, perché non c’è il font cirillico corrispondente. Carica sempre T1, eventualmente con altre codifiche specificate prima, e non avrai problemi.

Ciao
Enrico

Ho l’impressione che questo filone stia diventando una cosa kafkiana e cominci ad avere difficoltà a raccapezzarmi. Cerco di riassumere:

1) Stiamo parlando di usare XeLaTeX, non pdfLaTeX, col quale fontspec credo che non si possa usare.
2) XeLaTeX richiede di sicuro la codifica di ingresso utf8 e non vuole nessuna chiamata a inputenc con nessuna specifica di codifica. O mi sbaglio? credo di no, ma non lo escludo. Mi spiego meglio: se si fa andare XeLaTeX con un file predisposto per pdfLaTeX, genralmente lo compila bene, ma quel file contiene inputenc e fontenc e non usa affatto font OpenType; inputenc legge i caratteri non ASCII immessi con la tastiera e registrati nel file TeX e li converte in sequenze TeX in un modo particolare, attraverso le definizioni che si trovano in .def, per esempio latin1.def. una volta fatta questa conversione i font di output non sono ancora stati presi in considerazione; questi vengono presi in considerazione sia attraverso le informazioni metriche per la composizione dei capoversi non ancora spezzati in righe e le istruzioni contenute nei file enc.def (per esempio t1enc.def), e i comandi primitivi eventuali rimasti dopo la composizione del capoverso vengono usati solo dopo la divisione in righe per mettere il cpaoverso spezzato in righe dentro la famosa scatola 255 e poi per essere trasferite nel file di uscita. Con Xelatex che usa solo l’enoding utf8 per l’ingresso, non c’è nessuna sostituzione; all’occorrenza la cofica utf8/unicode usata all’interno viene mantenuta se si usa un font OpenType, mentre viene trasformata in altro modo se viene usato un font Type 1 con una codifica, per esempio T1; queste trasformazioni sono contenute dentro file enc.dfu (per esempio t1enc.dfu).
3) babel non andrebbe usato con XeLaTeX, ma se si compila un file sorgente predisposto inizialmente per pdfLaTeX, ebbene babel, indipendentemente dal motore di composizione, analizza la codifica di uscita, non di entrata, per scegliere certi glifi piuttosto che certi altri o, meglio, per scegliere gli indirizzi giusti degli stessi glifi che con codifiche diverse possono trovarsi in posizioni diverse.
4) Xelatex è in grado di gestire anche i font di uscita di tipo Type 1, purché il comando di selezione di quel font specifichi anche la codifica di uscita; vedi esempio di Enrico che aggiunge la parte \fontencoding{T1} in testa al comando di selezione dei font sans serif.
5) è bene che fontspec sia caricato per primo; ne siamo tutti d’accordo e sappiamo perché (più o meno chiaramente); Enrico dice che so potrebbe caricare etex prima di fontspec; forse è vero, ma mi pare che anche senza etex il motore xetex conosca già le estensioni di etex; forse non conosce i comandi di allocazione per nome dei registri oltre la posizione 255 e qualche altra cosetta, ma a quel punto io preferirei caricare etoolbox che carica etex e fornisce diversi altri comandi utilissimi. Non ho mai provato a caricarlo prima di fontspec, ma mi pare che la cosa sia irrilevante — nel senso che è meglio caricare fontspec per primo a scanso di qualunque equivoco, ma non c’è nessuna prescrizione dogmatica di caricarlo per primo. L’episodio di questa estate, che ha spezzato le gambe a polyglossia, è che questo pacchetto assumeva che fontspec fosse già stato caricato e che avesse caricato anche il pacchetto keyval. L’aggiornamento di fontspec aveva rinunciato a keyval, e polyglossia si è ritrovato in braghe di tela. Mai assumere che qualche pacchetto necessario sia già stato caricato da altri pacchetti; esistono forme molto semplici per non ricaricare due volte gli stessi pacchetti, magari con opzioni diverse. fontspec invece è costruito apposta per non fa sapere a nessuno che è già in memoria così lo si può richiamare con opzioni diverse senza fare danni. Provate invece a chiamanre, per esempio, babel con opzioni diverse e vedete che cosa succede.

OldClaudio” post=65471Ho l’impressione che questo filone stia diventando una cosa kafkiana e cominci ad avere difficoltà a raccapezzarmi. Cerco di riassumere:

1) Stiamo parlando di usare XeLaTeX, non pdfLaTeX, col quale fontspec credo che non si possa usare.

Si sta parlando di fontenc, non di fontspec.

Ciao
Enrico

Sto dicendo che fontspec con pdflatex non si può usare; mi pare che all’inizio di fontspec.sty ci siano dei controlli per verificare che il motore in uso sia xetex o luatex.

Però riocnosco che con la similitudine dei nomi, questo filone è cominciato con fontenc prima di tutto e io ho acquisito nel mio cranio invecchiato fontspec prima di tutto

Scusatemi. 🙁 🙄

Però parlando di fontenc (quindi il motore è pdftex con pdflatex come formato) Io non credo di averlo mai messo per primo ma di avere comunque messo sempre babel dopo fontenc. Per me (a parte etoolbox, che a sua volta carica etex) la sequenza ottimale è:
`
\documentclass[…]{…}
\usepackage[…]{inputenc}
\usepackage[…]{fontenc}
\usepackage[…][font a scelta}
\usepackage[…]{babel}
…
`
Se non altro perché pdflatex prima legge il file sorgente e ha bisogno della codifica d’entrata, poi compone con i font di uscita e la loro codifica. babel controlla talvolta la codifica di uscita, non mi sono mai accorto che controlli la codifica di entrata, ma controlla anche talvolta quali sono i font di uscita, non solo la loro codifica; lo stesso si può dire, forse di altri pacchetti. ma certo i primi due sono inputenc e fontenc; non credo che l’ordine sia importante, ma preferisco seguire l’ordine che ho indicato, più per motivi “filosofici” che per una reale necessità.

OldClaudio” post=65496Sto dicendo che fontspec con pdflatex non si può usare; mi pare che all’inizio di fontspec.sty ci siano dei controlli per verificare che il motore in uso sia xetex o luatex.

Resta il fatto che il titolo del filone riguarda fontenc e non fontspec. 🙂

Ciao
Enrico