egreg9″ post=70109
fontenc va caricato prima di inputenc
Ho sempre affermato il contrario su una base pragmatica, piuttosto che per vincoli imposti dai due pacchetti. In realtà per il motore di composizione è del tutto indifferente quale sia l’ordine di caricamento dei due pacchetti, perché entrambi eseguono solo delle definizioni che sono indipendenti le une dalle altre.
Ricordo che le definizioni contenute nei vari file come latin1.def, che corrispondono alle opzioni per inputenc, trasformano i caratteri esterni in sequenze interne di TeX, e quanto contenuto nei file delle opzioni per i font di uscita trasformano i comandi interni in codici specifici oppure in “indirizzi” compresi nella polizza dei caratteri di uscita.
I miei motivi pragmatici sono riassunti nella frase seguente: “Il motore di composizione, per esempio pdflatex, prima legge il file sorgente poi dopo un po’ di elaborazione scrive il file di uscita”.
Mi pare del tutto logico, quindi, che TeX prima faccia uso delle definizioni contenute nel file inputenc con l’opportuna opzione, poi durante l’elaborazione e la scrittura del file di uscita usi le definizioni contenute nel file fontenc con l’opportuna opzione.
Chiaramente non è il caso di aprire una diatriba su questo “prima questo poi quello”, tanto è indifferente e l’esperienza me lo conferma.
Nel caso specifico del quesito posto da @ameba, è chiaro che textcomp risolve tutto, però mi resta oscuro perché @ameba riceva il messaggio che:
Command \textdegree unavailable in encoding T1
O meglio: la cosa è chiarissima, perché i font in codifica T1 non contengono nulla che possa servire come circoletto dei gradi; invece mi resta oscuro perché i vari file latin1.def, ansinew.def, eccetera diano delle definizioni di default per comandi come \textdegree e altri, mediante definizioni eseguite con [tt]\ProvideTextCommandDefault[/tt] che vengono eventualmente sovrascritte da definizioni esplicite, mentre invece utf8enc.def non lo faccia o lo faccia solo per un sotto insieme più piccolo di comandi relativi a segni che non compaiono nella pagina ASCII (0-127); se @ameba avesse usato per la codifica d’entrata latin1, invece che utf8, il problema non si sarebbe presentato, grazie alla definizione di default contenuta dentro il file latin1.def.
Naturalmente usando textcomp il problema si risolve comunque e meglio, perché il segno contenuto nella polizza del Text Companion font è specifico per marcare i gradi, mentre la definizione di default usa in modo matematico solo un circoletto rialzato, che costituisce un “meglio che niente” ma non è il segno giusto.
Ciao
Claudio