Il problema si ripresenta regolarmente nonostante la specifica della codifica utf8 per il file sorgente e la codifica T1 epr il file di uscita; e la causa è la legatura.
Allora può darsi che il rpoblmea si semplifichi con la codifica T1 per l’uscita, ma ne ho seri dubbi; il problema si risolve stando attenti che nel file sorgente non compaia la legatura.
Mi spiego meglio: quando si usa la codifca utf8 questa non viene immediatamante seguita dalla lettura del file *enc.def come per le altre codifiche a 8 bit; essa viene dilaziona al momneto del \begin{document} quanto tutto ciò che riguarda i font è già stato specificato; a quel momento sono note tutte le codifiche da usare per le uscite; OT1, T1, LY1, eventualmente LGR, T2A, eccetera. A quel punto vengono ricodificati tutti i caratteri utf8 codificati con più di un byte e che sono presenti nei font di uscita; quindi, se vogliamo, anche la legatura fi, o ffi, o fl, o ffl possono venire codificate correttamnte, in quanto non appartengono alla serie di font a aASCII codificati a 7 bit, che formano al prima mezza pagina dei font UNICODE.
Quando però copi da un file PDF avendo composto con un font che non è UNICODE, come succede per i fotn Type1 che si usano con la codifica T!, meno che mai con i font LGR ecc., vengono copiate delle legature che erano presenti in quei font, ma che non corrispondono a codici né unicode né a nessun’altra codifica. Se incolli questi caratteri in una finestra di un editor che per sua natura no usa di default le legature, probabilmente nella finestra di editing il carattere appare correttamante, ma successivamente il pacchetto inputenc con l’opzione utf8 non riesce a convertirlo nella sequenza dei due o più byte che corrispondono alla legatura T1, e quindi componendo appaiono caratteri strani. Oppure appare il warning che il carattere fi (legato) non ha un corrispondente e non può essere codificato. risultato restano nel flusso di caratteri da inviare all’uscita nel documento composto due o più bite che non hanno nessuna significato epr gli umani.
Se si esamina con molta attenzione il file dove si è copiata la legatura, la si cancelli sostituendola con i due caratteri slegati, e tutto file liscio; questa operazione può venire eseguira con un find&replace globale, cosicché non si sostituisce una sola istanza, ma si sostituiscono tutte le istanze dei caratteri legati.
Non è tutto esatto quello che ho scritto, ma rende l’idea. Il fatto che a @franen sia andato tutto a posto esplicitando la codifica T!, secondo me è un caso, mentre non sarebbe, anzi non è un caso se la cosa si è aggiustata da sola perché usa un editor diverso con un diverso font’d’entrata e quindi salva i caratteri immessi i modo diverso.
Capisco che questa spiegazione sia complessa e volutamente imprecisa, perché sarebbe troppo complicato verificare quello che ho detto andando a leggere i codici dei vari pacchetti nominati e i file .def o .dfu coinvolti nelle specificazioni di codifica, ma sostanzialmente la cosa dovrebbe essere chiara: quando succedono queste cose, si eseguano delle sostituzioni globali dei glifi legati con i corrispondenti caratteri slegati.
PS: dopo aver inviato il messaggio precedente, sono andato ad aprire il file t1enc.dfu che viene usato da input enc per mappare i caratteri UNICODE in entrata nei comandi interni di LaTeX per gestire quei glifi; il file si trova (con Texlive) in texlive/2013,texmf-distr/tex/latex/base/
Se si scorrono le varie mappature non ce ne è nessuna per gestire le legature, perché in effetti non dovrebbe essercene bisogno; le legature sono una proprietà del font, non una proprietà della codifica.