Hello Vivien,
En fait c'est vraiment une bonne question, parce qu'on peut assez facilement imaginer une ébauche de police où on fait apparaître des correspondances qui semblent canoniques comme par exemple p -> parma, t -> tinco, et du coup de prime abord on imagine que ça se passerait relativement bien pour les consonnes du quenya et du sindarin. Mais les bémols vont vite arriver (je choisis d'exposer des problèmes qui me viennent en vrac à l'esprit) :
Du coup on se retrouve vite à ne plus trop savoir quoi mettre où, ce qui semble canonique finit par ne pas l'être vraiment dès qu'on sort des cas classiques et qu'on envisage l'usage à plusieurs langues et modes, beaucoup de cas de transcriptions dépendent du contexte donc il faut prévoir une multitude de cas, le nombre de symboles en jeu peut être assez grand, tout ça fait que l'on va vite déborder et qu'on arrivera pas à maintenir un mapping simple ni sur le clavier ni dans la plage latine.
Pour synthétiser, on peut dire que l'idée de Dan Smith était vraiment ingénieuse, et finalement la plus canonique : elle choisissait de correspondre au tableau des tengwar, la manière dont Tolkien nous présente l'écriture elfique dans sa logique phonologique naturelle. Mais elle atteint vite ses limites : tout n'est pas si régulier et simple que cela en a l'air (placement des diacritiques, tengwar alternatives, ponctuation...) et on arrive vite à inonder le layout du clavier ; et en plus il y a ce problème de compabitilité des layouts qui casse tout dès qu'on n'a pas un clavier qwerty. S'ajoutant les problèmes de langues et de modes et on est vite perdu. Et s'ajoute également la complexité due aux nouvelles publications linguistiques qui forcent à 'empiler' sur l'existant. Du coup, à moins d'avoir un clavier tengwar physique vraiment bien fichu je ne vois pas trop comment on peut se passer d'un système d'aide à la transcription.
J'aurais tendance à dire que la meilleure solution serait carrément de tout clarifier et remettre le système à plat en suivant ce qui se fait sur le plan technologique pour les écritures réelles : japonais, arabe, sanscrit, etc. qui posent finalement des problématiques analogues qui pour le coup impactent le monde primaire. Pour toutes ces écritures, on a des plages unicodes indépendantes pour définir les caractères, et là il n'y a pas d'ambiguïtés vis à vis de la phonétisation latine, tout est propre et indépendant. Des propositions ont été faites pour faire adopter les écritures tolkiéniennes dans unicode mais cela n'a pas abouti. A mon humble avis ce n'est pas plus mal : vu ce qui sort dans les parma ces derniers temps, il serait prématuré de graver dans le marbre une nomenclature incomplète. Et ce n'est pas bloquant, car il y a des zones privées dans l'unicode qu'on peut utiliser librement.
Je pense qu'une étape importante de cette refonte serait de créer une nomemclature propre (ou de compléter celles qui existent déjà) des symboles des écritures tolkiéniennes (avec références, cas d'usage, etc) qui puisse servir de document de base à une nouvelle génération de polices tokiéniennes plus modernes, utilisant des plages unicodes communes complètement séparées de la partie latine. Cette 'norme' devrait également définir les choix technologiques qui vont bien (qu'est-ce qui doit être une ligature, une ancre, etc.) car dans certains cas le choix n'est pas simple. L'utilisation enfin, devra inévitablement se faire à l'aide d'un moteur de transcription / d'aide à la frappe car elle bannit définitivement l'usage direct du clavier classique occidental du fait du mapping unicode. Cela pourrait être une intégration niveau système d'exploitation, comme pour le japonais par exemple, avec un choix de mode/langue qui définit un contexte, puis quand on tape le texte en écriture latine phonétique, on se voit éventuellement proposer (si ambiguités) différents choix de transcription dans une liste dans laquelle on peut piocher (mais le moteur de transcription pourrait très bien être glaemscribe derrière).
Bref tout cela est bien compliqué et sortir du système existant pour quelque chose de plus propre risque de nécessiter de gros chantiers!
Pffffiou je sais pas si j'ai été hyper clair... ^^;
En fait c'est vraiment une bonne question, parce qu'on peut assez facilement imaginer une ébauche de police où on fait apparaître des correspondances qui semblent canoniques comme par exemple p -> parma, t -> tinco, et du coup de prime abord on imagine que ça se passerait relativement bien pour les consonnes du quenya et du sindarin. Mais les bémols vont vite arriver (je choisis d'exposer des problèmes qui me viennent en vrac à l'esprit) :
- en l'état actuel, les tehtar sont un cauchemar : dans les polices issues de la lignée 'Dan Smith' (l'immense majorité), le placement des tehtar se fait par une triche assez moche (mais inévitable et maline à l'époque) : les tehtar sont des caractères sans largeur, avec un décalage gauche négatif, ce qui fait que quand on les tape, ils viennent se mettre sur la tengwa d'avant. Du coup il existe, pour chaque diacritique, 4 versions différentes du signe avec différents décalages pour essayer de couvrir une majorité de cas de placement en fonction de la largeur de la tengwa qui précède. Voire même plus que 4, car pour les signes souscrits, il faut compter aussi les versions qui viennent se mettre à l'intérieur du lambe et à côté du rómen. Cela veut dire qu'il faut arriver à caser sur le clavier, dans le champ de gravitation de chaque voyelle a,i,e,o,u etc, toutes ces versions des tehtar ... donc déjà on commence à déborder et à rendre le principe pas très amical. Mais à la limite, je pense que ce problème est un faux problème : il y a une solution technique simple à ces soucis de versions de tehtar qui est de créer des polices opentype utilisant des ancres de placement. C'est ce que j'ai implémenté comme preuve de concept en modifiant la police Sarati Eldamar de Måns Björkman et cela simplifie énormément les choses (chaque diacritique n'existe plus qu'en une seule version) tout en améliorant le rendu (chaque diacritique est parfaitement placé) et en rendant possible les empilements de diacritiques. On trouve une autre solution encore dans la police FreeMonoTengwar où sont utilisées des ligatures (on remplace des combinaisons de caractères par d'autres caractères complexes qui sont le rendu des dites combinaisons), mais cela a ses limites : cela veut dire qu'il faut prévoir toutes les combinaisons, et si on rentre dans la complexité des tengwar et des sarati ce nombre peut devenir astronomique.
- également, sur le problème des diacritiques, il y a des modes qui utilisent (pour gagner de la place) des diacritiques au dessus ET en dessous des tengwar (grosso modo, quand on a un trou de libre et une voyelle à placer on la case dedans). Il faudrait arriver à mapper toutes les voyelles souscrites et suscrites sur le clavier / dans la police. Alors peut-être oui, dans le cas d'une police opentype, ça pourrait s'envisager avec l'usage de voyelle minuscule / voyelle majuscule. Sans opentype... argh, je vois pas trop comment on peut s'y prendre pour trouver un système simple
- en fonction des langues et des modes on n'utilisera pas les mêmes tengwar pour les mêmes phonèmes, en général on rempli le tableau des tengwar en donnant priorité aux phonèmes les plus fréquents, qui vont occuper les premières lignes. Du coup soit on choisit une langue de référence (quenya?) pour faire le mapping des tengwar sur les phonèmes les plus courants de la langue en question (mais cela implique de faire un effort mental quand on va utiliser la police pour écrire une autre langue donc là on perd les 3/4 des utilisateurs). Soit on fait une police pour chaque langue mais là aussi plus personne ne va y comprendre quoi que ce soit (sans compter qu'une des polices les plus courantes s'appelle déjà 'Tengwar Sindarin' ... ).
- En quenya, un débutant serait tenté d'écrire nd comme n+d avec son clavier mais en réalité il serait sans doute plus naturel d'avoir nd directement sur la lettre d de la police car un d seul est très peu commun, n'appartenant pas à la phonologie du quenya on risque de ne le rencontrer que dans des emprunts ou des composés bizarres (de même que b/mb, g/ng).
- Idem pour ld en quenya qui devient une seule tengwa (alda).
- Le traitement de la semi-voyelle y est différent en fonction de si elle est plutôt voyelle ou plutôt consonne, donc il faut bien se poser la question avant de choisir les bons caractères (plusieurs entrent en jeu). Idem pour h en fonction de sa position.
- Le cas des diphtongues est encore une autre galère.
- ...
Du coup on se retrouve vite à ne plus trop savoir quoi mettre où, ce qui semble canonique finit par ne pas l'être vraiment dès qu'on sort des cas classiques et qu'on envisage l'usage à plusieurs langues et modes, beaucoup de cas de transcriptions dépendent du contexte donc il faut prévoir une multitude de cas, le nombre de symboles en jeu peut être assez grand, tout ça fait que l'on va vite déborder et qu'on arrivera pas à maintenir un mapping simple ni sur le clavier ni dans la plage latine.
Pour synthétiser, on peut dire que l'idée de Dan Smith était vraiment ingénieuse, et finalement la plus canonique : elle choisissait de correspondre au tableau des tengwar, la manière dont Tolkien nous présente l'écriture elfique dans sa logique phonologique naturelle. Mais elle atteint vite ses limites : tout n'est pas si régulier et simple que cela en a l'air (placement des diacritiques, tengwar alternatives, ponctuation...) et on arrive vite à inonder le layout du clavier ; et en plus il y a ce problème de compabitilité des layouts qui casse tout dès qu'on n'a pas un clavier qwerty. S'ajoutant les problèmes de langues et de modes et on est vite perdu. Et s'ajoute également la complexité due aux nouvelles publications linguistiques qui forcent à 'empiler' sur l'existant. Du coup, à moins d'avoir un clavier tengwar physique vraiment bien fichu je ne vois pas trop comment on peut se passer d'un système d'aide à la transcription.
J'aurais tendance à dire que la meilleure solution serait carrément de tout clarifier et remettre le système à plat en suivant ce qui se fait sur le plan technologique pour les écritures réelles : japonais, arabe, sanscrit, etc. qui posent finalement des problématiques analogues qui pour le coup impactent le monde primaire. Pour toutes ces écritures, on a des plages unicodes indépendantes pour définir les caractères, et là il n'y a pas d'ambiguïtés vis à vis de la phonétisation latine, tout est propre et indépendant. Des propositions ont été faites pour faire adopter les écritures tolkiéniennes dans unicode mais cela n'a pas abouti. A mon humble avis ce n'est pas plus mal : vu ce qui sort dans les parma ces derniers temps, il serait prématuré de graver dans le marbre une nomenclature incomplète. Et ce n'est pas bloquant, car il y a des zones privées dans l'unicode qu'on peut utiliser librement.
Je pense qu'une étape importante de cette refonte serait de créer une nomemclature propre (ou de compléter celles qui existent déjà) des symboles des écritures tolkiéniennes (avec références, cas d'usage, etc) qui puisse servir de document de base à une nouvelle génération de polices tokiéniennes plus modernes, utilisant des plages unicodes communes complètement séparées de la partie latine. Cette 'norme' devrait également définir les choix technologiques qui vont bien (qu'est-ce qui doit être une ligature, une ancre, etc.) car dans certains cas le choix n'est pas simple. L'utilisation enfin, devra inévitablement se faire à l'aide d'un moteur de transcription / d'aide à la frappe car elle bannit définitivement l'usage direct du clavier classique occidental du fait du mapping unicode. Cela pourrait être une intégration niveau système d'exploitation, comme pour le japonais par exemple, avec un choix de mode/langue qui définit un contexte, puis quand on tape le texte en écriture latine phonétique, on se voit éventuellement proposer (si ambiguités) différents choix de transcription dans une liste dans laquelle on peut piocher (mais le moteur de transcription pourrait très bien être glaemscribe derrière).
Bref tout cela est bien compliqué et sortir du système existant pour quelque chose de plus propre risque de nécessiter de gros chantiers!
Pffffiou je sais pas si j'ai été hyper clair... ^^;
