Discussion:
accents (affichage)
(trop ancien pour répondre)
Jean-Marc Desperrier
2004-09-13 17:15:37 UTC
Permalink
Tiens, je viens de me rendre compte que cet accent aigu solitaire fait
partie des � combining diacritical marks �. Ne faut-il pas le mettre
*avant* le caract�re � modifier plut�t qu'apr�s ?
Cela donnerait � priv'e � au lieu de � prive' � et � priv%cc%81e � au
lieu de � prive%cc%81 �.
non, je ne pense pas
(sur fciws on m'a dit que c'est normal)
Les caract�res combinants se placent toujours *apr�s* le caract�re
qu'ils modifient.
Cela �tant,
- chez moi la page est d�j� en UTF-8 (Mozilla page info dixit) ;
tiens, avec moi aussi, je croyais que non
et malgr� ca ca ne s'affiche pas comme il faut ?
Mozilla ne g�re pas les caract�res combinants quand il affiche un texte
brut (� l'int�rieur d'une balise <PRE>, ainsi que les 'text/plain', en
l'occurence c'est le premier cas).
Une limitation certainement un peu regrettable.

Si je clique sur le lien
(http://tdecontes.hd.free.fr/aide/web/prive%cc%81/), j'arrive sur une
page d'erreur avec le contenu suivant :

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>403 Forbidden</TITLE>
</HEAD><BODY>
<H1>Forbidden</H1>
You don't have permission to access /aide/web/privé/
on this server.<P>
<HR>
<ADDRESS>Apache/1.3.29 Server at tDeContes.hd.free.fr Port 80</ADDRESS>
</BODY></HTML>

Et si je force manuellement cette page � s'afficher en UTF-8, alors
l'apostrophe s'affiche bel et bien au-dessus du 'e' (il n'y a plus le
<PRE>).

Cette page d'erreur 403 est configur�e dans Apache pour �tre renvoy�e en
ISO-8859-1, ce qui m'oblige � forcer pour avoir le UTF-8. L'en-t�te
suivant est pr�sent :
wget -S --spider http://tdecontes.hd.free.fr/aide/web/prive%cc%81/
6 Content-Type: text/html; charset=iso-8859-1

Alors que la premi�re page elle ne pr�cise rien :
wget -S --spider http://tdecontes.hd.free.fr/aide/web/
6 Content-Type: text/html

Un peu curieux, mais je suppose que la deuxi�me est auto-g�n�r� par un
module qui ne pr�cise pas l'encodage, et que la premi�re est extraite
d'une liste de page pr�sente par d�faut avec Apache, avec une version
par langue, et des instruction dans le config de apache qui font qu'il
choisit l'encodage en fonction de la langue ... Enfin, �a peut �tre
autre chose, il faudrait regarder en d�tail.

Ah, au fait, le probl�me � la base est que le nom n'est pas g�n�r� sous
la forme de normalisation C, ce qui devrait �tre le cas dans tous les
�diteurs sous peine d'emmerdes s�rieuses.

Cf Formes de normalisation dans la traduction fran�aise d'unicode :
http://cooptel.qc.ca/%7Epandries/pdf/Chapitre-6.pdf

Je ne vois pas bien s'il y a une diff�rence avec le TR-15 :
http://www.unicode.org/reports/tr15/
Thomas
2004-09-13 18:32:45 UTC
Permalink
Cela étant,
- chez moi la page est déjà en UTF-8 (Mozilla page info dixit) ;
tiens, avec moi aussi, je croyais que non
et malgré ca ca ne s'affiche pas comme il faut ?
Mozilla ne gère pas les caractères combinants quand il affiche un texte
brut (à l'intérieur d'une balise <PRE>, ainsi que les 'text/plain', en
l'occurence c'est le premier cas).
Une limitation certainement un peu regrettable.
.....
http://cooptel.qc.ca/%7Epandries/pdf/Chapitre-6.pdf
http://www.unicode.org/reports/tr15/
bon, tout ca c'est un peu confu pour moi, mais je relirais demain

merci pour la reponse :-))
--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE

"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"
Antoine Leca
2004-09-16 11:52:56 UTC
Permalink
Les caractères combinants se placent toujours *après* le caractère
qu'ils modifient.
<SUPER-PÉDANT>
Sauf U+035D .. U+0362.
</SUPER-PÉDANT>


Antoine
Olivier Miakinen
2004-09-16 12:44:42 UTC
Permalink
Post by Antoine Leca
Les caractères combinants se placent toujours *après* le caractère
qu'ils modifient.
<SUPER-PÉDANT>
Sauf U+035D .. U+0362.
</SUPER-PÉDANT>
Merci pour la précision !

[ suivi positionné vers un seul des deux groupes du crosspost ]
Jean-Marc Desperrier
2004-09-17 12:37:18 UTC
Permalink
Post by Antoine Leca
Les caractères combinants se placent toujours *après* le caractère
qu'ils modifient.
<SUPER-PÉDANT>
Sauf U+035D .. U+0362.
</SUPER-PÉDANT>
On corrigera par "caractère de base" alors :-)

Si cela se trouve, il y a aussi des cas encore plus tordus en devanagari.
Antoine Leca
2004-09-17 17:44:57 UTC
Permalink
Post by Jean-Marc Desperrier
Si cela se trouve, il y a aussi des cas encore plus tordus en
devanagari.
Je ne pense pas, en tous cas pour la nâgarî.

Le système de base de la nâgarî, et de toutes les écritures à virâma
héritées de la brahmî, c'est d'avoir des marques (caractères combinants)
pour représenter les signes des voyelles qui remplacent la voyelle a (les
écritures indiennes considèrent que les consonnes comme nous les connaissons
n'existente pas, car il est impossible de prononcer une consonne sans
l'appui d'une voyelle; donc l'élément de base est une consonne avec la
voyelle a). Jusque là, aucun souci, puisque ces signes combinent logiquement
avec la consonne précédente. Idem pour les caractères (appelés points,
/bindus/) qui indiquent la nasalisation de la dite voyelle. Idem aussi avec
le nukta, ce point qui se place sous une consonne pour indiquer une
prononciation modifiée par rapport à la norme sanscrite; ce nukta est très
très ressemblant aux accents (diacritiques) du latin.

Plus complexe est le cas du virâma proprement dit (U+0x4D ou U+0xCD,
x=9,A,B,C,D). /Virâma/ est un concept, pas un caractère graphique. Il
pourrait s'analyser effectivement comme un caractère (de contrôle) combinant
double, quand il sert à relier entre eux deux consonnes (comme le [t] et le
[w] du [twa] de Antoine). Mais on a atttribué à ce code une autre fonction,
quand il apparaît en finale pour indiquer que la dernière consonne ne se
prononce pas (comme le [n] à la fin de mon nom). Dans ce dernier cas,
visuellement c'est rendu en nâgarî avec le symbole qui est présenté dans les
tables (appelé /halant/ en hindî et parfois /halanta/ en sanscrit). Et les
grammairiens indiens ont choisi d'expliquer le fonctionnement à partir de ce
dernier comportement, qui est baptisé comme celui de la consonne pure. Donc
le virâma est analysé comme lié à la consonne qui le précède, et ensuite ce
groupe est lié à la consonne suivante, et éventuellement ligaturé, comme
c'est expliqué dans le chapitre 9 du bouquin Unicode (d'ailleurs, ce
chapitre est trop centré sur la nâgarî, cela pose problème pour généraliser
aux autres écritures qui ont gardé un schéma plus proche de la brahmî
originale, où les consonnes suivantes sont écrites en plus petit sous la
première ou légèrement sur la droite).

Donc pour en revenir à la vue que peut en avoir le système Unicode, le
virâma se comporte bien comme un caractère qui combine avec son précédent.

Plus tangent est le cas des signes de voyelles de gauche du thaï et du lao
(U+0E40 - U+0E44 et U+0EC0 - U+0EC4). Mais la tendance générale est de ne
pas considérer ces caractères comme des caractères combinants, et de faire
une exception pour l'algorithme de tri.


Antoine

Loading...