|
|
|
|
|
|
La saisie et le partage de caractères spéciaux, et en particulier de symboles phonétiques, représentent des casse-têtes pour les linguistes depuis les débuts de l'informatique. Il existe maintenant des solutions satisfaisantes, même si tous les problèmes ne sont pas résolus.
Cette page présente
- un bref aperçu des problèmes du codage
- la saisie: des solutions pour les utilisateurs (Windows et Mac), selon qu'ils souhaitent saisir quelques caractères phonétiques, ou saisir de façon commode une grande quantité de texte en alphabet phonétique (exemple : transcription suivie d'un enregistrement), et pouvoir échanger les fichiers ainsi créés
- quelques liens utiles.
|
" Avant d'être traitée par l'informatique, l'industrie du texte a été dominée par l'imprimerie. Les casses étaient des supports physiques pour les caractères de plomb utilisés dans l'édition. Dans une casse, chaque caractère était positionné à un endroit précis et invariable. Le caractère était donc identifiable par la place qu'il occupait, et ceci quelle que soit la taille, ou le style utilisé. La casse, qui comportait environ une centaine de cassetins, était le reflet d'une analyse de la langue qu'elle codait et des traditions typographiques qui lui étaient attachées. Ensuite, à l'avènement de l'informatique, les normalisations de codage de caractères se sont succédées, cherchant à reproduire l'association entre un code identifiant (position dans la casse) et la définition d'un caractère. Le principal objectif de ces normes est bien sûr la standardisation en vue de l'échange des données. " (Michel Jacobson, " Le codage de caractères ", magazine en ligne PrograZine, numéro 9 ; texte complet disponible en cliquant ici). |
Une première solution pour le codage des caractères de l'alphabet phonetique international (API), solution qui paraissait techniquement la plus simple, consiste à partir de la casse du code dit ASCII, qui comporte 128 caractères (ceux que l'on voit sur les claviers : les 26 lettres latines, majuscules A-Z et minuscules a-z ; les chiffres arabe ; certains signes de ponctuation et caractères spéciaux), et à remplacer purement et simplement les caractères se trouvant dans certaines des 128 cases par un caractère phonétique. On crée ainsi une police phonétique.
Le procédé a été abondamment employé, et il existe un grand nombre de polices ainsi conçues, dont certaines sont très répandues. Ainsi, dans la police SILDoulosIPA, le symbole ʃ a été mis à la place du s majuscule. L'utilisateur qui a installé la police SILDoulosIPA sur son ordinateur et qui souhaite insérer ce caractère ʃ sélectionne SILDoulosIPA dans la liste des polices, puis il tape S sur son clavier, et c'est ʃ qui apparaît.
Problème : dans l'ordinateur, le caractère est codé comme un S (s majuscule), puisque c'est cette lettre que l'utilisateur a tapée sur son clavier, sans indiquer à aucun moment au logiciel que, dans la police phonétique choisie, la correspondance touches-symboles était différentes de la correspondance standard définie par le code ASCII. Autrement dit, le caractère n'est pas explicitement codé comme un ʃ, symbole de l'Alphabet Phonétique International.
Ce problème n'apparaît pas tant que l'utilisateur travaille sur un ordinateur où la police SILDoulosIPA est installée, et échange ses fichiers avec d'autres utilisateurs qui possèdent comme lui cette police. En revanche, impossible pour un utilisateur qui n'a pas cette police d'afficher correctement les fichiers qui l'utilisent.
Le problème devient aigu avec la multiplication des polices phonétiques ainsi créées. Par exemple : si un autre utilisateur a pris l'habitude d'utiliser, non pas SILDoulosIPA, mais IPASAM, il verra le même texte s'afficher, non pas comme ʃa, mais comme Sa, une correspondance touches-symboles différente ayant été choisie par les créateurs des différentes polices. Il devient alors nécessaire, lorsqu'on envoie à un autre utilisateur un fichier contenant des caractères phonétiques, de lui envoyer aussi la police phonétique utilisée, ce qui complique les échanges, oblige à collectionner les polices, et n'est parfois tout simplement pas praticable, par exemple si un correspondant qui travaille sous Windows vous envoie une police Windows que vous ne pouvez pas installer sur votre Mac.
Une solution est offerte par le codage Unicode, qui établit une correspondance univoque entre une définition de caractère (exemple : " voyelle centrale, mi-ouverte, arrondie "), une glyphe (la forme du caractère : en l'occurrence ɞ), et un code que manie l'ordinateur (pour le ɞ, ce code est : ɞ). Ainsi, le système informatique manipule un caractère dont il connaît l'identité : notre ʃ est identifié comme une fricative post-palatale non voisée, qui s'écrit comme ʃ, et occupe la position ʃ dans la casse Unicode. (Un tableau indiquant la correspondance entre codes Unicode et caractères API est proposé par Michel Jacobson : voyelles, consonnes pulmoniques, consonnes non pulmoniques, et tons. Si vous souhaitez également obtenir la correspondance pour les diacritiques, vous référer aux liens).
Cela a une conséquence essentielle pour l'échange de données : les lettres API ainsi codées seront reconnues sur tous les systèmes utilisant Unicode ; il n'est plus nécessaire de faire passer des vessies pour des lanternes, comme c'était le cas pour notre ʃ lorsque la police SILDoulosIPA le mettait à la place du S.
Ainsi, la standardisation est acquise, non pas en imposant une certaine police et une certaine correspondance touches-symboles, mais en identifiant les symboles de façon non ambiguë. Voir également la présentation (en français) d'Unicode sur le site officiel du consortium.
ATTENTION, le standard Unicode ne résoud pas tous les problèmes : il pose encore des problèmes délicats pour certaines langues; en outre, tous les logiciels ne gèrent pas encore ce codage. Il est donc bon de conserver, à toutes fins utiles, vos polices " pré-Unicode ". Néanmoins, pour la grande majorité des utilisations (échange de fichiers .doc et .rtf, envois à des revues et des éditeurs, mise à disposition sur internet sous forme HTML ou XML...), il est préférable de passer aux outils Unicode, utilisés par une communauté large et active, tandis que les polices " pré-Unicode " deviennent peu à peu obsolètes et posent des problèmes croissants de compatibilité. (Voir par exemple l'annonce par le projet STEDT, de l'Université de Berkeley, de mettre fin au développement de leur propre police phonétique.)
Une fois résolu à saisir des caractères Unicode, il vous faut : une police qui implémente la partie API de l'Unicode, et un outil de saisie.
Polices Unicode :
Toutes les polices Unicode se valent dans la mesure où elles reposent sur le même codage et sont compatibles entre elles : si vous voyez ici le caractère ʃ (fricative post-alvéolaire), c'est que votre ordinateur possède une police Unicode, qu'il a utilisée pour afficher ce caractère (et vous pourrez sans difficulté afficher l'intégralité du tableau API Unicode mis en ligne par l'Université de Victoria). D'une police à l'autre, seul le détail de la glyphe varie (chaque police reflétant un certain style). Parmi les polices Unicode les plus commodes pour les utilisateurs employant des caractères phonétiques se trouve par exemple Doulos SIL... à ne pas confondre avec SILDoulosIPA ! Les créateurs de SILDoulosIPA, mesurant l'intérêt d'Unicode, ont réalisé une police Unicode qui cumule les avantages de lisibilité de la police " pré-Unicode " SILDoulosIPA avec les avantages (en terme d'étendue, de compatibilité...) du système Unicode. Elle est disponible sur le site du SIL : cliquer ici. Mais il n'est nullement indispensable d'utiliser cette police : de nombreuses polices implémentent la partie API de l'Unicode, et permettent donc le traitement des caractères phonétiques. Par exemple : LucidaSansUnicode, ArialUnicodeMS, Code2000...
Outils de saisie :
- Pour quelques caractères :
Il est possible d'aller chercher les caractères un par un via la palette des caractères. C'est malcommode, du fait que les polices sont souvent immenses, et n'est adéquat que lorsqu'on rencontre la nécessité ponctuelle d'ajouter quelques caractères à un document.
Les utilisateurs de Macintosh peuvent recourir à la palette de caractères IPA Palette, plus ergonomique que la simple palette des caractères : elle ne présente que les caractères API, qui plus est de façon ordonnée.
- Pour un usage régulier :
Pour saisir régulièrement de l'API, il est recommandé de définir un clavier. On associe certaines touches à certains caractères, selon ses préférences personnelles. (Il existe également un certain nombre de claviers déjà définis.) La procédure peut sembler identique à la création d'une police, à la mode " pré-Unicode ". Mais il y a une différence de taille : la police n'était pas commodément partageable ; tandis que le clavier va piocher dans Unicode, et vous donne un texte codé en Unicode. Personne n'a besoin de savoir avec quel clavier vous avez saisi votre texte. C'est là l'idée fondamentale à retenir.
Sous Windows, il existe plusieurs possibilités, dont KEYMAN. J'expose brièvement la façon d'utiliser Keyman dans un document PowerPoint disponible ici. Le logiciel lui-même (version étudiante gratuite) peut être téléchargé ici.
Sous Mac, l'outil (gratuit) qui permet de définir un clavier est Ukelele. Je ne l'ai pas utilisé personnellement ; de l'avis d'utilisateurs, il est moins commode d'emploi que ses équivalents sous Windows.
La page du SIL présentant l'emploi d'Unicode pour l'Alphabet Phonétique International.
La page Unicode de John Wells, University College London.
La référence : le site du consortium Unicode.
|
Cette page est issue de la formation "Saisir des caractères phonétiques en UNICODE" que j'ai assurée dans le cadre des formations "Savoir-faire" de l'Ecole Doctorale "Langage et Langues" de l'Université Paris 3 - Sorbonne Nouvelle. Les supports de cours (maintenant un peu anciens mais toujours utiles) sont librement disponibles en ligne. Pour accéder à la liste des Savoir-Faire, suivre ce lien. Dernière mise à jour : décembre 2011. |
Alimenté par Enercoop |
