Re: fontenc prima di tutto

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.