Bonsoir Jean,
Bonjour,
Le 26/11/2022 à 00:03, Eulogia a
écrit :
En effet, le changement des messages en français résout
le problème!
Sauf que j'ai déjà renommé tous mes fichiers et dossiers,
j'ai eu trop de galères cette semaine avec les encodages
entre frescobaldi, le shell script et ce dernier bug.
J'espère aussi surtout que le prochain Frescobaldi
corrigera le bug des menus qui ne répondent pas correctement
au lancement, car cela lui donne un côté vraiment pas très
sérieux.
Qu'est-ce que le bug des menus qui ne répondent pas ? C'est un bug
connu de Frescobaldi (dans la liste
https://github.com/frescobaldi/frescobaldi) ? Si non, il faudrait
que vous donniez plus de détails sur ce qui se passe pour qu'il
puisse être réglé :-)
J'avais écrit au support de Frescobaldi, il y a longtemps, mais sans réponse…
Si j'ouvre Frescobaldi en cliquant l'icône du programme ou en cliquant sur un fichier .ly, aucun menu (barre, contextuel, bouton des fragments) ne fonctionne correctement dans le logiciel. Si l'on clique une seule fois sur le menu, l'intitulé devient sombre, mais sans dérouler le menu, si l'on appuie plusieurs fois dessus, le menu apparaît brièvement pour disparaître tout seul… Si par contre, on clique plusieurs fois et on déroule en même temps, on peut arriver à utiliser le menu, mais il faut vraiment avoir le coup de main… La musique a toujours été une question de dextérité.
Heureusement, j'ai une fois trouvé par hasard une manière de contourner le bug:
Il faut lancer Frescobaldi en cliquant sur son icône, attendre qu'il soit lancé, puis ouvrir un fichier .ly depuis le Finder en cliquant dessus: dès que le fichier est ouvert dans Frescobaldi, tous les menus fonctionnent correctement…
Malheureusement, les bugs de ce genre ont une fâcheuse tendance à ne
se produire que sur un système.
J'ai le bug sur plusieurs macs différents, avec plusieurs versions de macos, et le bug est présent depuis la version 3 de Frescobaldi, à tel point que je suis resté le plus longtemps possible sur la 2, jusqu'à ce qu'elle ne fonctionne définitivement plus avec les update de macos et que j'ai réussi à le contourner.
Et si c'était le réglage au moment de l'installation de
lilypond qui restait en usage indépendamment des
changements de session?
J'ai réessayé pour être sûr, et maintenant il affiche bien
quelque chose:
GNU LilyPond 2.22.2
Traitement de « /Users/benedikt/Desktop/test2.ly »
Analyse...
Interprétation en cours de la musique...[8]
Pré-traitement des éléments graphiques...
(process:4822): Pango-WARNING **: 23:33:59.546: Invalid UTF-8 string passed to
pango_layout_set_text()
Avertissement : aucun glyphe ne correspond au
caractère U+FFFD dans la fonte
« /opt/local/share/fonts/urw-core35-fonts/NimbusSans-Regular.otf »
Avertissement : aucun glyphe ne correspond au
caractère U+FFFD dans la fonte
« /opt/local/share/fonts/urw-core35-fonts/NimbusSans-Regular.otf »
Détermination du nombre optimal de pages...
Répartition de la musique sur une page...
Dessin des systèmes...
("52" "e3" "a9")
Conversion à « test2.pdf »...
Compilation menée à son terme, avec succès.
Ce changement pourrait venir du fait que j'ai réinstallé
lilypond via macport, ou alors, je ne peux pas non plus
exclure une fausse manœuvre de fin semaine de ma part…
Au moins, je suis rassuré sur le fait qu'il me reste au moins une
partie de ma tête.
Complètement!
Donc, avec cette information, le phénomène paranormal s'éclaire pour
moi. Une explication si vous êtes curieux(se?) : Le caractère « é »
est représenté en UTF-8 par deux octets, C3 (11000011) et A9
(10101001). LilyPond 2.22 utilise Guile 1, qui ne comprend pas
l'UTF-8, et y voit deux caractères séparés. LilyPond appelle sur la
chaîne « ré » la fonction « string-capitalize » de Guile pour mettre
la première lettre en majuscule. Or, cette fonction met aussi le
reste en minuscules. Pour cela, elle utilise la fonction C standard
tolower(), qui met en minuscule un caractère encodé dans l'encodage
du système. En l'occurrence, votre encodage système, comme le mien,
est l'UTF-8, sauf que E3 isolément n'est pas un caractère valide en
UTF-8 ! Donc la fonction tolower() est susceptible de faire…
n'importe quoi, et apparemment la bibliothèque C de macOS se
comporte différemment sur ce point de la bibliothèque C sur mon
système GNU/Linux (glibc). Elle a l'air de faire comme si le
caractère était encodé en latin1. De ce point de vue là, Ã est
changé en ã.
Merci pour l'explication, c'est un des aspects pénibles avec Apple, même les bibliothèques standards peuvent avoir un comportement différent sur leur plateforme.
Je parie que ça fonctionne dans Frescobaldi à cause du fameux «
Lancer LilyPond avec des messages en anglais », qui met LC_ALL à C,
ce qui configure un encodage « ASCII seulement » plutôt que « UTF-8
».
Pari gagné!! Si je mets les messages en français avec la 2.22.2, j'ai les accords en "R" au lieu de "Ré", comme avec le terminal.
Bref, trêve d'explications : comme LilyPond 2.23.81 utilise Guile 2,
qui comprend l'UTF-8, le problème ne risque plus d'arriver (et je
suis soulagé de ne pas avoir un bug d'encodage à pourchasser sur un
système que je ne possède pas).
Je comprends tout-à-fait. Si jamais, vous avez un jour besoin d'un mac (pour faire tourner un Linux ARM bien sûr), je peux en avoir pour des très bons prix…
Cordialement,
Ben |