Discussion:
Combinaisons lettre+accent [Fut : Accents (Firefox, Linux)]
(trop ancien pour répondre)
Olivier Miakinen
2007-10-19 07:43:29 UTC
Permalink
http://worldcat.org/oclc/53770324&referer=brief_results
SysteÌ\200me d'eÌ\201dition
Bon sang, je n'en avais jamais rencontré alors je n'y pensais pas !
Pourtant je savais bien que ça existait.
http://forum.mathematex.net/aide-latex-f6/conversion-latex-vers-words-beurk-t931.html?sid=0db758da1f284c4b4abb88b97159604e
http://minilien.com/?SkcWiKzDsO
Math˩matique
Ok.
L'une de ces pages n'est donc pas vraiment en utf (ou alors l'utf est mal
spécifié).
Eh si, les deux sont tout-à-fait corrects :

UTF-8(65 CC 81) = U+0065 U+0301 = e + accent aigu = é
UTF-8(C3 A9) = U+00E9 = é

Il faudrait maintenant comprendre d'où vient que le logiciel de Denis
puisse lire de l'UTF-8, mais pas combiner « lettre + accent » pour
reconstituer la lettre accentuée.

Je fais suivre sur fr.comp.normes.unicode en rappelant le contexte.

Environnement : Firefox sur Linux Debian Etch
Firefox 1.5.0.7, X11, rv:1.8.0.7, en-us, Gecko 20060830

Page de test :
http://worldcat.org/oclc/53770324&referer=brief_results
Antoine Leca
2007-10-30 12:05:29 UTC
Permalink
Post by Olivier Miakinen
Il faudrait maintenant comprendre d'où vient que le logiciel de Denis
puisse lire de l'UTF-8, mais pas combiner « lettre + accent » pour
reconstituer la lettre accentuée.
Ce sont deux moments différents de la chaîne de restitution.

Lire l'UTF-8 est fait au niveau de la réception du protocole, assez près de
la communication réseau (car dans la pratique on a besoin de l'information
*externe* que constitue par exemple un champ content-encoding-charset=, ou
un paramètre de page de code spécifié dans l'appel ou récupéré dans le
registre ou que-sais-je.
Le même morceau qui fait ce décodage (éventuellement ne fait rien,
d'ailleurs), range en même temps, pour consommation par les étages
supérieurs (ou inférieurs), le texte ainsi récupéré, dans l'encodage utilisé
par le logiciel (et avec Firefox, ce sera ou UTF-8, ou UTF-16, ou utf-32, je
ne sais pas lequel mais les spécialistes préciseront).

Bien plus tard, la (les) routine(s) chargée(s) de la restitution à l'écran
(indispensable pour les humains normaux :-)) récupère le flux produit
ci-dessus, et produit les appels au moteur graphique qui vont bien ; ici, ce
sera un décodage caractère-vers-glyphe, puis envoi des glyphes dans le
contexte graphique aux coordonnées adéquates. Dans le cas considéré la
seconde partie doit être faite par Freetype, pour ce qui concerne le
décodage je ne sais pas précisement (Pango ? dans Gecko ?)

D'après ce que j'ai compris, la ou les routines de décodage ne font pas le
traitement complet des diacritiques Unicode (<U+0065, U+0301> remplacé par
/eacute). Je suis sûr (:-)) que Freetype ne le fait pas, ou alors uniquement
sous fortes contraintes (;-)), genre polices OpenType et options de layout
des versions de développement de Freetype.
Donc c'est du ressort de la routine, que je ne connais pas, chargée de la
correspondance codepoints Unicode vers glyphes.


Une autre possibilité serait que le code de lecture du flux venant du réseau
fasse ce que l'on appelle une normalisation canonique (qui entre autres
effets réduit <U+0065,U+0301> à <U+00E9>).
Cependant, je peux comprendre que pour des raisons de performance, le code
de niveau réseau s'abstienne de cette étape tant que ce n'est pas absolument
indispensable (ça c'est de la litote, ou je ne m'y connais pas !)


Antoine

Loading...