inputenc e fontenc; quale dei due prima?

Certamente caricarli prima non fa male; anzi si è assolutamente sicuri che tutto si svolgerà per il meglio, indipendentemente dal fatto che inputenc con l’opzione utf8 dilazioni la definizione dei glifi al momento del [tt]\begin{document}[/tt].

Dopo aver letto completamente al documentazione sia di inputenc sia di utf8ienc ed averne constatato la sciatteria e l’incongruenza di diverse affermazioni, concordo che, nonostante possa essere indifferente (“possa”, congiuntivo presente, frase che implica la possibilità ma non la certezza 🙂 ) quale dei due si carica prima, è certamente meglio caricare prima fontenec. Sarà anche indifferente, ma non si sa mai.:neutral:

Questo thread, me ne rendo conto ed è colpa mia, rischia di essere una discussione di lana caprina; se lo proseguo è solo per schiarirmi le idee, non per polemica sterile e inutile, visto che abbiamo già convenuto che è conveniente e opportuno caricare inputenc dopo che sono stati caricati tutti i pacchetti che in qualche modo usino dei font.

Riassumo quanto sono riuscit a capire:

1) il nucleo di LaTeX carica di default gli encoding dei font OT1, T1, TS1, OML, OMS nell’ordine opportuno affinché il font testuale di default sia OT1 (poi speriamo che in futuro l’encoding di default sia T1, ma per il momento accontentiamoci di quello che c’è)
2) il pacchetto fontenc permette di caricare o di (tentare di) ricaricare altri font enconding; in realtà i font enconding già caricati impediscono di essere ricaricati, ma tra quelli caricati nel nucleo e quelli esplicitamente ricaricati con fontenc deve esserci una diversa interazione, altrimenti non potremmo mai sapere quale sia l’encoding di default e non potremmo mai imporre che questo sia T1; ricordiamo anche che se i file di encoding vengono caricati con \input non esistono limitazioni a quante volte lo stesso encoding possa essere ricaricato. Tutto questo permette anche di definire la macro \LastDefinedEncoding in modo che al momento di \begin{document} LaTeX sappia quale sia l’encoding definito per ultimo da usare come encoding di default.
3) il pacchetto inputenc stabilisce la corrispondenza fra i caratteri immessi con la tastiera o che il programma di tipocomposizione legge quando elabora il file tex da compilare. Con le altre codifiche non dovrebbe succedere niente di particolare, ma con la codifica utf8 la corrispondenza dei caratteri in input con la codifica interna di LaTeX è più complessa. Dice la documentazione di utf8enc.def (contenuta nel file xtf8ienc.dtx) che:

However, we don’t know if there are font encodings still to be loaded (either with fontenc or directly with \input by some some package). Font enconding files are loaded only if the corresponding encoding has not been loaded yet, and they always begin with \DeclareFontEncoding. We now redefine the internal kernel version of the latter to load the Unicode file if available.

Perciò, visto che ogni encoding comincia con il comando \DeclareFontEncoding, definito nel nuclo, quato comando viene ridefinito in modo che ogni nuovo font encoding richiamanto dopo inputenc usi la nuova definzione, la quale contiene quello che occorre per caricare gli appositi file enc.dfu che mettono in relazione i codici unicode con il glifi effettivamante contenuti nel fontencoding che si sta dichiarando.

Di qui si evince (io evinco) che se certi font enconding sono già stati caricati prima di inputenc (in particolare lo sono gli encoding elencati al punto 1) ma credo che la seguente operazione di ridifinizione non riguardi gli encoding matematici) questi sono già stati immessi con la dichiarazien del nucleo di LaTeX e sono già noti a in qualunque momento si chiami inputenc nel preambolo, che sia prima o dopo di fontenc. Invece i font dichiarati con fontenc o con \input dopo aver letto inputenc, vengono caricati con la nuova definizione di \DeclareFontEncoding che provvede ad aggiungere il nome alla lista dei font encoding conosciuti e a caricare gli appositi file dfu.

Tutto ciò premesso mi pare ovvio che sia conveniente caricare qualunque cosa riguardi i font prima di inputenc come raccomanda Enrico ma da quanto si evince (io envinco) dalla lettura della documentazione e del codice, sembrerebbe che la cosa sia davvero indifferente, nel senso che è stato previsto che chi scrive classi o chi usa LaTeX possa anche commettere delle “violazioni” delle raccomandazioni, come si legge all’inizio del paragrafo 2.4 di utf8ienc.pdf:

The original plan was to set up the UTF-8 support at \begin{document}; but then any text characters used in the preamble (as people do even though advised against it) would fail in one way or the other. So the implementation was changed and the Unicode definition files for already defined encodings are loaded here.

seguito dal capoverso che ho citato prima. [“already defined encodings are loaded here” si riferisce alla definizione di \cdp@elt e all’esecuzione di \cdp@list; poi segue la ridefinizione di \DeclareFontEncoding che gestisce i font che venissero caricati dopo inputenc]

A me pare di essermi schiarito le idee; se ho interpretato male, mi piacerebbe essere corretto.

Resta il fatto che la raccomandazione di Enrico di caricare tutto ciò che riguarda i font prima di chiamare inputenc con l’opzione utf8 sia un’ottima raccomandazione.

Se mathpazo definisce altri encoding allora la seconda versione è quella giusta, ma in questo caso deve avere definito sia MOenc.def sia MPenc.dfu (se il nuovo encoding si chiamasse MP). Ma se mathpazo usa solo l’encoding T1 (per il testo), non è obbligatorio seguire il consiglio di caricarlo prima.

Metterei la cosa sotto un altro punto di vista; se carichi il pacchetto per la composizione del russo, probabilmente non espliciti che vuoi usare la codifica T2a con fontnec; probabilmente il pacchetto stesso definisce o importa un suo file *enc.def; allora sarebbe meglio caricarlo prima di inputnec.

Però, come mi pare di avere spiegato nel mio messaggio, se non ho capto male gli inner workings dei vari pacchetti, la cosa dovrebbe essere del tutto irrilevante, perché tutto ciò che viene caricato dopo inputenc con l’opzione utf8, viene definito con un \DeclareFontEncoding ridefinito in modo tale che vengano ugualmente caricati i file dfu necessari.

Anche se termino il mio messaggio con la stessa raccomandazione di Enrico, e sempre che io non mi sbagli grossolanamente, è del tutto indifferente quel pacchetto venga caricato per primo.

Io infatti tutte le volte che uso utf8 con inputenc, continuo a caricare questo pacchetto per primo e tutti gli altri pacchetti vengono caricati dopo, ma non ho mai incontrato nessuna difficoltà, come ho potuto constatare leggendo nel dettaglio il file log.

Predico bene e razzolo male; razzolando male, lo scotto che pago, forse, è che le definizioni contenute nei pacchetti dfu vengono eseguite due volte con la perdita di tempo che ammonta a pochi millisecondi. Sarebbe razionale predicare bene e razzolare bene 😉

Nei log dei file che ho composto con l’ordine “sbagliato”, le definizioni unicode sono fatte una volta sola. Non è nemmeno una questione di millisecondi.:)

Forse hai ragione, ma a me sembra che il meccanismo sia diverso; se un pacchetto (non solo per la scelta dei font, ma anche per la scelta della lingua) chiama un pacchetto per i font o usa \DeclareFontEncoding dopo che è stato letto inputenc con l’opzione utf8, l’eventuale lettura avviene subito, non al momento di [tt]\atBeginDocument[/come quasi tutta la documentazione lascerebbe pensare, Infatti la ridefinizione di [tt]\DeclareFontEncoding[/tt] aggiunge l’eventuale nuovo encoding alla lista degli encoding già noti e lancia [tt]\cdp@list[/tt] che legge ill file dfu subito, non differito all’inizio del documento.

Come dicevo in un precedente messaggio, non è il caso di farne una questione di principio. Il pericolo che tu paventi potrebbe avverarsi anche se l’utente chiamasse i vari pacchetti parecchio prima di inputenc, perché i pacchetti chiamati prima non producono la lettura immediata del corrispondente file dfu, che viene letto solo durante l’esecuzione di inputenc. L’importante secondo me è avere presente nei dettagli ciò che avviene dietro le quinte per poter invocare i pacchetti che servono al momento giusto. Quando si conoscono quelle operazioni, che finora non mi ero mai preoccupato di conoscere nel dettaglio, si può fare tutto quel che si vuole perché si sa quello che si sta facendo. Poi per le raccomandazioni per un neofita, sono d’accordissimo di darle nella forma che tu raccomandi.

Forse la raccomandazione giusta sarebbe: “Il preambolo deve cominciare con l’impostazione della codifica dei font usati nel documento e quella del file di ingresso poi devono essere caricati tutti i pacchetti che in qualche modo potrebbero alterare la lista delle codifiche dei font, infine babel e alla fine di tutto il preambolo hyperref, se lo si vuole usare”. È tutta una questione di dipendenze, secondo me, tanto che è esperienza comune quella che certi errori spariscono se si altera l’ordine di caricamento dei file di estensione; l’ultimo che mi è capitato riguardava l’ordine di caricamento di wasysym e di marvosym (che tra l’altro gestiscono font, ma sono con codifica U e quindi nessuno ha da preoccuparsene perché a questa codifica non corrispondono né file def né file dfu).

Ciao a tutti
Claudio