Ce blocage à la compilation est récurrent, et l'origine de ce caractère invalide est toujours très long à identifier, malgré l'information sur la ligne concernée. N'y aurait-il pas un moyen de forcer la compilation à se poursuivre, afin que ce caractère invalide apparaisse clairement ? Ou un moyen de demander à inputenc d'être plus explicite ? Posée 05 Oct '19, 16:57 joseph-tux Pathe ♦♦ |
Lors du blocage de la compilation par pdflatex, au lieu de sortir par «X», on peut poursuivre avec «R». Publiée 05 Oct '19, 16:59 joseph-tux J'ai trouvé cette réponse avant d'adresser la question, mais tout compte fait, ça pourra peut-être servir à d'autres. Sinon, les modérateurs peuvent supprimer cette question sans que je m'en offusque;)
(05 Oct '19, 17:02)
joseph-tux
2
Deux remarques : – il me semblait que le fichier .log contenait le caractère fautif ; je crois me souvenir de l'avoir copié, puis cherché sur internet, ce qui s'était révélé pratique ; – choisir
(05 Oct '19, 18:01)
Pathe ♦♦
1
@Pathe Il y a des problèmes avec
(05 Oct '19, 18:19)
samcarter
2
D'après ltxnews30, la gestion de l'utf8 devrait être nettement améliorée avec la fournée qui doit sortir dans les prochains jours.
(05 Oct '19, 20:35)
Bernard
C'est une bonne nouvelle. Néanmoins la question subsiste lorsque le problème n'est pas l'UTF8, c'est à dire lorsqu'il y a réellement un caractère invalide, non utf8. Cependant, j'ai bien rencontré ce problème de l'utf8 valide avec le fichier de configuration de la classe lettre, réglé en notant «\'{e}» au lieu de «é» etc. Aux autres, merci aussi pour votre contribution; il me semble avoir parfois réglé le problème avec utf8x, et rencontré d'autres problèmes avec ce même utf8x, mais c'est loin dans ma mémoire de vieux poisson rouge.
(06 Oct '19, 15:16)
joseph-tux
|