Le rendu dans l’éditeur de texte confirme que LuaLaTeX ne transforme pas ;) Et c’est bien HyperRef qui fout le bronze et ça peut se comprendre : ça réécrit beaucoup de composants internes et est connu pour poser des soucis avec les autres paquetages (ce qui se résout souvent en chargeant hyperref en dernier et en remontant les soucis comme celui-ci) Je ne pense pas que le Frido soit en cause ici et voici mon hypothèse :
Lua(La)TeX et Xe(La)TeX exigent d’avoir leur source en UTF-8 et les adresses passées sont vues en UTF-8 (grosso modo)
pdf(La)TeX historiquement ne connait que l’ASCII. Le paquetage inputenc permet d’utiliser plusieurs encodages : ça dit comment doivent être interprété les octets du document. Je ne sais plus depuis quand, mais l’encodage par défaut est maintenant UTF-8 (ce qui peut expliquer que l’exemple fonctionne) Mais comme on ne sait pas avec quelle version notre destinataire va compiler il vaut mieux toujours préciser l’encodage ! (et ça se fait tout au début pour que le moteur mette en place le mécanisme de conversions...1) Or j’ai l’impression que hyperref écrase certains mécanismes et ne détecte pas inputenc ou le comprend mal ? Du coup, quand ton document est en UTF-8 et qu’il voit arriver deux/trois octets, il les affiche séparément comme si ce sont des codes ASCII... (et là, sans inputenc qui je rappelle est important, il voit bien l’UTF-8 parce-que tu as une version récente où c’est l’encodage par défaut ; mais une personne avec une version plus ancienne va retomber dans le même travers)
Quand je disais que ça supporte bien Unicode, c’est parce que ce n’est pas limité à UTF-8 mais aussi UCS (mais ce n’est pas encore sec...) Les conversions en interne consiste à reconnaitre les codes caractères et les mapper aux commandes associées (en gros son encodage interne) et plante quand la commande n’est pas honorée (on continue à travailler avec les paquetages les fournissant, comme avant, mais on peut saisir directement les caractères) tandis qu’avec les moteurs modernes c’est dans le document final qu’on va découvrir que la police finale n’a pas la glyphe. Bref, deux salles deux ambiances et bien que j’écrivais que pdf(La)TeX gère bien l’UTF-8 il ne faut pas comprendre que c’est trivial ou que c’est de la même façon que les autres moteurs. Fin de la longue parenthèse. ↩
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: je pensais que c’était su...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au journal pdfLaTeX, XeLaTeX et LuaLaTeX sont dans un bateau. Évalué à 4.
Le rendu dans l’éditeur de texte confirme que LuaLaTeX ne transforme pas ;) Et c’est bien HyperRef qui fout le bronze et ça peut se comprendre : ça réécrit beaucoup de composants internes et est connu pour poser des soucis avec les autres paquetages (ce qui se résout souvent en chargeant
hyperrefen dernier et en remontant les soucis comme celui-ci) Je ne pense pas que le Frido soit en cause ici et voici mon hypothèse :Lua(La)TeX et Xe(La)TeX exigent d’avoir leur source en UTF-8 et les adresses passées sont vues en UTF-8 (grosso modo)
pdf(La)TeX historiquement ne connait que l’ASCII. Le paquetage
inputencpermet d’utiliser plusieurs encodages : ça dit comment doivent être interprété les octets du document. Je ne sais plus depuis quand, mais l’encodage par défaut est maintenant UTF-8 (ce qui peut expliquer que l’exemple fonctionne) Mais comme on ne sait pas avec quelle version notre destinataire va compiler il vaut mieux toujours préciser l’encodage ! (et ça se fait tout au début pour que le moteur mette en place le mécanisme de conversions...1 ) Or j’ai l’impression quehyperrefécrase certains mécanismes et ne détecte pasinputencou le comprend mal ? Du coup, quand ton document est en UTF-8 et qu’il voit arriver deux/trois octets, il les affiche séparément comme si ce sont des codes ASCII... (et là, sansinputencqui je rappelle est important, il voit bien l’UTF-8 parce-que tu as une version récente où c’est l’encodage par défaut ; mais une personne avec une version plus ancienne va retomber dans le même travers)Quand je disais que ça supporte bien Unicode, c’est parce que ce n’est pas limité à UTF-8 mais aussi UCS (mais ce n’est pas encore sec...) Les conversions en interne consiste à reconnaitre les codes caractères et les mapper aux commandes associées (en gros son encodage interne) et plante quand la commande n’est pas honorée (on continue à travailler avec les paquetages les fournissant, comme avant, mais on peut saisir directement les caractères) tandis qu’avec les moteurs modernes c’est dans le document final qu’on va découvrir que la police finale n’a pas la glyphe. Bref, deux salles deux ambiances et bien que j’écrivais que pdf(La)TeX gère bien l’UTF-8 il ne faut pas comprendre que c’est trivial ou que c’est de la même façon que les autres moteurs. Fin de la longue parenthèse. ↩
"It is seldom that liberty of any kind is lost all at once." ― David Hume