[Résolu] lexique sanscrit dans un livret

[donutboy]

Salut à vous,

actuellement je travail sur un livret qui à pour sujet la langue sanscrite. Dans ce livre différents sujets sont abordés et blablabla.... A la fin de ce livre je souhaite mettre un inde lexical qui regroupe tous les mots dudit livre, pour le moment ça baigne... mais là ou ça coince c'est pour l'ordre des mots dans ce lexique, il ne me propose pas la langue sanscrite.
Alors je me suis dit que je vais activer la prise en charge des scripts complexes, en pensant qu'il me proposera ce choix dans les options du lexique ... J'ai donc deux choix qui me sont proposés 1) langues occidentales et 2) langues complexes, avec choix sanscrit... mais c'est seulement le premier choix qui détermine l'ordre du lexique... là j'arrive au bout de mes connaissances d'OOo et fait appel à vous pour y voir plus clair...

je reste à votre disposition pour plus de détails...


see you

régis

[Jean-Louis Cadeillan]

Bonjour et bienvenue sur le forum,

avec choix sanscrit

Je n'ai pas ce choix dans la liste, mais j'ai Hindi par défaut (qui a priori a le même alphabet)

c'est seulement le premier choix qui détermine l'ordre du lexique

Avec ou sans script complexe, l'ordre de tri (Outils > Trier dans Writer ou Données > Trier dans Calc) est déterminé par le code des caractères (Unicode), donc tout dépend de la police utilisée. J'ai testé 2 polices devanagari que j'avais sous la main, Mangal, Raavi : effectivement,le tri se fait selon l'unicode et non selon l'ordre classique (j'ai pris comme base le travail de Gérard Huet) . Voici un exemple sur une vingtaine de caractères, classés par la fonction de tri :

donutboy_02.png

Ajout : Merci à --<alhazred>--pour sa vigilance, j'ai mis en rouge les corrections apportées, espérant qu'il ne reste pas d'erreur

On voit bien que c'est l'unicode qui conditionne le tri et ce avec ou sans script complexe, dans Calc ou Writer.
Solution --> trouver une police dont les caractères sont conformes à l'ordre classique. J'ai une autre police, Sanscrit New, qui construit ses caractères (quand c'est nécessaire) par agrégation et dont le classement par tri ne correspond ni à l'ordre classique, ni à l'unicode (?)
Peut-être d'autres membres du forum auront des idées plus constructives...
Cordialement
Jean-Louis

[alhazred]

Bonjour,

J'ai fait un petit essai de tri sur les mots d'un texte hindi (police mangal) pris sur un site au hasard; tout me semble fonctionner correctement.

Texte Hindi

L'ordre des caractères unicode respecte l'ordre traditionnel. À ce sujet, le tableau présenté dans le message précédent contient des erreurs; par exemple, ligne 11, le caractère présenté se lit "ka" et non "pha"...

Un petit rappel si on tape क (ka U+0915) + ् ("virama", absence de voyelle U+094D) + र (ra U+0930), l'affichage produit la ligature क्र (kra unicode ?). Il se pourrait donc que certaines ligatures de ton texte aient été introduites directement, sans passer par leurs composants, ce qui ruinerait le résultat du tri (simple supposition de ma part tant que tu ne fournis pas un exemple où le tri échoue).

Ajout : Je viens de tester Sanscrit New; belle apparence, permet de composer un texte plus ou moins phonétiquement (plutôt moins que plus), mais rien à voir avec unicode, donc à éviter, spécialement si le fichier est destiné à être partagé!

[Grenouille]

Bonjour,

OOo 3.2, mandriva 2010

Ta version est obsolète et sûrement en provenance des dépôts de ta distribution Mandriva.

Mets toi à jour avec la version officielle.

A+

[Jean-Louis Cadeillan]

là ou ça coince c'est pour l'ordre des mots dans ce lexique

Si ça ne vient pas de la police devanagari, on peut supposer que donutboy a utilisé pour son lexique une police de translitterration, style Nina 1.0, qui elle ne respecte pas du tout l'ordre devanagari dans son Unicode...affaire à suivre.
Quelques autres remarques :

• Arial propose les mêmes caractères, dans les mêmes unicodes (c'est bien l'avantage de la normalisation)
• une seule lettre ॠ n'est pas classée comme il faut, elle devrait être après ऋ mais son unicode est 2400 et elle se retrouve donc en dernier.
• j'ai regroupé dans le fichier joint
  donutboy_01.ods
  les 46 caractères devanagari, leur translittération et leur groupe.

A+
Jean-Louis

[alhazred]

Bonjour,

D'accord avec toi, Jean-Louis Cadeillan, mais, je ne sais pourquoi, ton fichier s'est affiché chez moi avec des signes bizarres (étoile, même un signe d'intégration...) lorsqu'il devait y avoir des diacritiques, alors je me suis permis de le réviser -- pas tout à fait parfaitement, spécialement pour le positionnement du macron sur la voyelle r longue (peu fréquente):

donutboy_01 (révisé).ods

[Jean-Louis Cadeillan]

Merci pour ton adaptation ! Effectivement j'ai utilisé la police Nina 1.0 qui permet une très bonne translittération. On peut la trouver ici par exemple. Elle est gratuite, mais je ne connais pas son type de licence. Malheureusement, elle n'est pas Unicode, donc la portabilité des documents laisse à désirer...la preuve...
Si tu connais une police en alphabet latin qui permettent comme Nina 1.0 tous les signes diacritiques utiles, mais en Unicode, je suis preneur (il faudrait que je prenne le temps de lire le fichier que j'ai fait l'autre jour )
A+
Jean-Louis

[donutboy]

Salut à vous et merci pour vos réponses...

effectivement j'utilise une police sanscrite romanisée : http://www.sanskritweb.net/fonts/#CSX pour faire ce livret... pourquoi celle-ci ?? et bien elle possède tous les caractères dont j'ai besoin et de plus c'est mon premier projet de ce style... c'est en forgeant que l'on devient forgeron

je vais potasser toutes vos infos et je reviendrais vers vous pour vous tenir au courant de mes "soucis"

en tout cas merci pour l'aide apportée...

P.s: je n'ai pas internet sur le poste ou je travail... donc pas de mise à jour, je ferais avec


a bientôt

[alhazred]

Merci à Jean-Louis Cadeillan pour ce fichier unicode; je n'aurai pas la patience de tout vérifier; ci-jointe une variante avec classement hexadécimal (plus proche du système unicode)

Caracteres02 (version hexa).rar

À ce stade, voyons un peu les possibilités pour écrire une langue comme le sanscrit:

• Utiliser des polices plus ou moins maison qui permettent par exemple d'obtenir ब (ba) en tapant b et भ (bha) en tapant B; en changeant de police, on retrouve b et B par exemple.
Inconvénients: portabilité quasiment nulle à moins d'intégrer au document la police utilisée (avec d'éventuels pb de copyright); de plus, pour obtenir बि (bi) il faudrait taper ib (police Sanscrit New par exemple, qui d'ailleurs n'est pas si phonétique que ça: bh est associé au point d'exclamation)
• Utiliser un clavier adapté à la langue (relativement facile à fabriquer en utilisant MS Keyboard Layout Creator), en associant par exemple à la touche b le caractère unicode ब (et भ à shift-b)
avantages: le texte ainsi produit sera unicode, donc portable, et permettra aussi des tris corrects. inconvénients: la translittération est perdue, mais une macro (pas très facile) pourrait éventuellement la reconstituer à partir du texte sanscrit
• Pour la translittération, de nombreux caractères sont disponibles directement en unicode, mais pas forcément tous: dans le cas du sanscrit, la voyelle r longue serait représentée par un r avec une sorte de cédille en dessous (pas un point: il désigne en général le r rétroflexe de l'hindi) et un macron au-dessus. On peut donc utiliser ŗ (U+01157) suivi de l'accent macron ˉ , ŗ̄ , et comme vous le voyez, la police utilisée ici ne le place pas correctement

[Jean-Louis Cadeillan]

• Merci pour la version hexa, c'est carré ! (et même 256 au carré )
• Pour le r long avec un point, à défaut de la cédille, ṝ code 7773 (1E5D en hexa) s'édite directement dans ce message sous Win XP en tapant Alt + 7773, la même combinaison de touche est inopérante sous Writer ==> De là à penser qu'il faille rédiger ses textes dans le forum pour les copier/coller ensuite dans Writer, il y a un pas que je n'oserais franchir
• Insertion > Caractères spéciaux dans Writer ou Calc donne accès à un échantillon de caractères spéciaux.
  Par exemple, pour Arial, on n'a pas accès à cette partie de la zone Latin étendu additionnel, où pourtant se trouve le ṝ. Dans la boîte Caractères spéciaux, cette zone commence à U+1E80, donc après 1E5D (le caractère précédent dans la boîte est le U+06FE !)
• Par contre, pour d'autres polices Unicode, comme e-Phon Translit UNI, on y a accès ==> bizarre.
• Cette dernière police permet ,dans la zone à usage privé de la police d'avoir kh, gh, ch, jh, ṭh, ḍh, th, dh, ph, bh en une seule lettre, ce qui est un (petit) pas vers un classement correct dans un lexique...
• Reste donc à créer une police, dans la zone à usage privé,donc les caractères de translittération soient classés correctement : FontForge, DoubleType ?
• Il existe une macro qui permet sous Writer en tapant les 4 chiffres de l'Unicode d'avoir le caractère correspondant, mais je n'ai pas réussi à la faire marcher...

A+
Jean-Louis

[alhazred]

Bonjour,

Insertion > Caractères spéciaux dans Writer ou Calc donne accès à un échantillon de caractères spéciaux.

Ce n'est pas la faute des Caractères spéciaux: toutes les polices ne contiennent pas tous les caractères possibles. Pour ce qui est de ṝ, il existe dans Times New Roman que j'utilise le plus souvent possible.

Cette dernière police permet ,dans la zone à usage privé de la police d'avoir kh, gh, ch, jh, ṭh, ḍh, th, dh, ph, bh en une seule lettre

À mon avis, l'ordre dans la translittération doit suivre celui des caractères latins (bg < bh <bi) sinon pourquoi ne pas utiliser les caractères natifs? De plus, à la césure d'un mot composé, ou entre deux mots, b+h (ou p+h) donne bh -- à moins que ce ne soit bbh, études lointaines, tout ça
De plus, quid de la portabilité? Je n'ai pas e-Phon Translit UNI (et ne m'en porte pas plus mal ). Je ne l'ai par ailleurs pas trouvée sur Internet.

Pour ceux que ça intéresse, j'ai posté une fonction de translittération (pas question de la mettre ici sinon Vilains modOOos venir dire "gnaaah pas être place macro" )

[Jean-Louis Cadeillan]

toutes les polices ne contiennent pas tous les caractères possibles

Tu as raison, mais force est d'avouer que Writer ou Calc faussent les pistes :

donutboy_03.png

En fait, il semble qu'à l'affichage Writer cherche la police qui a un glyphe défini pour ce code, même si on lui impose par formatage une police qui ne l'a pas !

Pour ce qui est de ṝ, il existe dans Times New Roman que j'utilise le plus souvent possible

D'après FontMatrix*, Arial ou Times New Roman ont chacun 1674 glyphes référencés, mais ni l'un ni l'autre n'ont ṝ (enfin, pas mon Times New Roman) et si je peux l'afficher dans Writer ou Calc, c'est que j'ai des polices qui contiennent le caractère unicode 7773, comme le permet e-Phon Translit UNI (à ce propos je l'ai trouvé ici dans ce package). Donc je suppose que tu as une autre police qui référence ce glyphe ou bien que tu as un Times New Roman enrichi dans la zone à usage privé.

À mon avis, l'ordre dans la translittération doit suivre celui des caractères latins (bg < bh <bi) sinon pourquoi ne pas utiliser les caractères natifs?

Je crois que tu résumes là la meilleure réponse que l'on puisse apporter à donutboy
A+
Jean-Louis
PS : *Je viens d'installer Fontmatrix qui est un outil sensationnel pour analyser toutes les polices, installées ou pas !==> en particulier les droits d'utilisation sont explicités. Ainsi pour e-Phon Translit UNI

Copyright (c) Elmar Kniprath, 2005. All rights reserved. No commercial use or distribution allowed.

[alhazred]

Bonjour,

Writer cherche la police qui a un glyphe défini pour ce code

Exact, sûrement pour éviter de nombreux rectangles "caractère inconnu", mais c'est parfois un peu gênant...

En tout cas, Caractères spéciaux ne donne que les caractères de la police indiquée
Et je confirme, mon Times New Roman contient bien ṝ unicode 7773 (version 5.05, 3414 glyphes dans la fonte normale)
Grand merci pour le lien de FontMatrix, c'est effectivement extra, ainsi que pour celui de Indolipi.

À ce sujet, je n'ai pu faire qu'un essai très incomplet car le système utilise des macros MSBasic (à traduire en OOo Basic si j'ai le temps... )

[Jean-Louis Cadeillan]

Bonjour,

mon Times New Roman contient bien ṝ unicode 7773 (version 5.05, 3414 glyphes dans la fonte normale)

eh oui XP SP2 ne fournit que la version 3
Mais j'ai trouvé cette page qui fait le point sur les polices unicodes utilisables en translittération pour le sanscrit : ainsi XP SP2 fournissait Tahoma, de 1E00 à F71D, des glyphes à diacritiques en tous genres !
Et sous licence libre et en Serif, DejaVu ! C'est déjà pas si mal !

à traduire en OOo Basic si j'ai le temps

le temps est rarement, lui, sous licence...libre
A+
Jean-Louis

[donutboy]

Salut à vous,

je comprend un peu mieux le fonctionnement des polices... auparavant je pensais qu'il fallait une police occidentale et une police qui prenne en charge le sanscrit. Et en parcourant vos réponses je me suis aperçus que les polices occidentales pouvaient contenir tous les caractères, alors je me suis tournés vers une police unicode Linlibertine http://www.linuxlibertine.org/index.php?id=91&L=1 police très belle (ressemble à Times) et qui possède tous les caractères recherchés, bingo.

Mais voilà toujours se soucie d'index, alors je vous ai joint un fichier qui reprend quelques mots tirés du livret, suffisant pour montrer mon soucis, c'est à dire l'ordre alphabétique abcdef... alors que je souhaite l'ordre de l'alphabet sanscrit a ā i ī u u etc.

je vous remercie pour tout


régis

[alhazred]

Bonsoir,

Comme je l'ai déjà dit, il me semble plus judicieux, pour une translittération, de suivre l'ordre latin (ce n'est qu'un avis tout personnel).

Mais j'ai constaté qu'un simple tri semble considérer a et ā comme une même lettre (comme en français acide, puis âcre, puis acte; mais put et pût sont triés dans cet ordre).

Ton lexique, lui, fait la différence, mais place incorrectement ā, en ne le changeant pas en majuscule. Et pour une lettre donnée, le classement suit la règle du paragraphe précédent.

Je ne vois aucune solution toute faite à ton problème; simplement, attends d'avoir terminé ton ouvrage, crée ton lexique, et mets-le dans l'ordre voulu par des copier-coller (bien sûr, décoche la case "protégé contre les modifications manuelles"); attention, si tu actualises ou édites le lexique, tes modifications sont perdues.

[donutboy]

Merci de la réponse... de toute façon je continue l'ouvrage et verrais par la suite pour le lexique. une chose m'intrigue le "copier-coller", c'est à dire ?

a tchao bonsoir

[alhazred]

Bonsoir,

Par exemple, la série des ā n'est pas placée à ta convenance: tu la copies (ctrl-C) supprimes (ctrl-X) et tu la colles (ctrl-V) à sa place "normale" c'est-à-dire après la série des a.
Un peu fastidieux pour tout remettre dans l'ordre voulu, mais lorsque tu as ton index définitif, ça ne doit pas prendre plus de cinq minutes (ne pas oublier de décocher la case "protégé contre les modifications manuelles" dans l'édition de l'index et à nouveau ne pas actualiser ou modifier la présentation de l'index sinon tout est à refaire)

Ajout : et s'il n'y a pas de contre-indication* (copyright, personnel, tout ça) ça me plairait bien de voir le résultat. * j'avais tapé contrindication et il n'y avait pas d'erreur d'orthographe... où va le monde?

[donutboy]

re,

merci pour l'info... et pour le coup de main....


thanks

[Jean-Louis Cadeillan]

Bonsoir,
Je te propose une solution (en tout cas une tentative...) en passant par Calc :

donutboy_02.ods

• Tu copies ta liste de mots translittérés dans le désordre dans la colonne jaune (la E)
• Tu as la même liste triée en respectant l'ordre des caractères sanscrits dans la colonne verte (la BB)

Les colonnes intermédiaires sont cachées (pour les voir : Ctrl+A, Format>Colonne>Afficher)
Les explications sont sur la ligne 3 en commentaires (bulles à partir des points rouges).
Cette solution suppose une police type Mangal (en tout cas Unicode avec zone des caractères sanscrits 2300 => 2400) et une police de translittération Unicode type Tahoma.
Cordialement
Jean-Louis

[donutboy]

salut à vous tous,

je viens d'essayer l'astuce d'alhazred et elle me va bien... Alors je crois que je vais mettre "résolu"

je vous remercie beaucoup pour votre aide, et à bientôt sur le forum pour de nouvelles aventures

bien à vous


régis

[alhazred]

Bonjour à tous,

Jean-Louis Cadeillan, ta solution me semble un peu lourde (sans offense )

• Grand nombre de colonnes qui ne font que des opérations élémentaires
• Pourquoi utiliser les caractères sanscrits alors que les voyelles ne se combinent pas? (शउनयअ s'écrit en fait शुन्य)

Il serait préférable à mon avis d'utiliser une fonction qui transforme chaque mot translittéré en une suite de codages et classer selon le codage.
De plus, ce n'est pas seulement des mots qu'il faut classer, dans le problème de donutboy, mais des paragraphes.

Voici un fichier où ceux que ça intéresse trouveront la fonction en question:

donutboy_03.ods

[Jean-Louis Cadeillan]

Grand nombre de colonnes qui ne font que des opérations élémentaires

Une boucle de programmation fait aussi un grand nombre d'opérations élémentaires...c'est l'éternel débat entre l'algorithmique cellulaire et l'algorithmique linéaire : laquelle sollicite davantage le processeur ? A voir...Par ailleurs, il se trouve que la fonction SUBSTITUE n'est pas matricialisable (si tu me pardonnes ce néologisme)

Pourquoi utiliser les caractères sanscrits alors que les voyelles ne se combinent pas?

aucune importance ==> le choix de la palette de caractères intermédiaires est sans conséquence sur le résultat final; il s'agit de trouver des caractères qui se suivent au niveau alphabétique (reconnus comme tels par l'opérande >) ; j'aurais très bien pu utiliser a, à, â, ä, b, c, ç, d, e, etc... mais je n'arrivais pas à 46 caractères)

'utiliser une fonction qui transforme chaque mot translittéré en une suite de codages et classer selon le codage

c'est exactement ce que je fais.

ce n'est pas seulement des mots qu'il faut classer, dans le problème de donutboy, mais des paragraphes

ça marche aussi avec des paragraphes...

Merci pour ta lecture attentive et pour ta fonction !
Cordialement
Jean-Louis

[alhazred]

Bonjour,

laquelle sollicite davantage le processeur ?

C'est vrai ça, j'ai perdu l'habitude de ce genre de questions (ça me rappelle mon vieil Apple ][ 128K, plus de temps passé à optimiser un programme qu'à le concevoir )

j'aurais très bien pu utiliser a, à, â, ä, b, c, ç, d, e, etc... mais je n'arrivais pas à 46 caractères

C'est pour ça que j'ai préféré coder sur deux chiffres.

J'ai aussi beaucoup apprécié cette utilisation de SOMMEPROD à laquelle je n'aurais pas pensé (n'empêche que je préfère ma méthode, na!!!)

ça marche aussi avec des paragraphes...

Exact, j'ai vérifié, mais là, l'optimisation... on vérifie tous les caractères et pas seulement le premier mot, le seul significatif, c'est pour ça que j'ai mis la constante finDevanagari qui stoppe les remplacements.

Cordialement