Re: Problème avec l'affichage de l'accord de Ré

[Jean Abou Samra]

    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é :-)
    
    Malheureusement, les bugs de ce genre ont une fâcheuse tendance à ne
    se produire que sur un système.

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.
    
    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 ã.
    
    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
    ».
    
    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).
    
    Cordialement,
    Jean

OpenPGP_signature
Description: OpenPGP digital signature