Subject: Inclusion des sources

From: Vincent Gay <[email-masked]>
Date: Mon, 30 Jan 2023 23:08:54 +0100

Hello les colistier(e)s, une petite histoire personnelle qui vous amusera peut-être.

après quelques semaines de vacances (en fait de travaux de rénovation dans notre maison) je me suis remis gentiment gentiment à mon ouvrage lilypondien. Pour rappel il s'agit d'un recueil d'environ 150 partitions de Jazz, j'en ai codé 132 à ce jour, intégrées dans un fichier principal avec la fonction \include. "Évidement" les sources sont incluses dans le PDF et... tout d'un coup je suis pris d'un doute. Est-ce qu'un PDF peut contenir autant de pièces jointes ? Est-ce que Lily sait faire ça ? Comment peut-on les enregistrer sur son ordinateur ?

J'ouvre mon fichier résultat avec Okular qui est mon lecteur de PDF par défaut. Toutes les pièces jointes sont bien là, c'est la seule bonne nouvelle.

premier hoquet, et non des moindres, le nom des fichiers est présenté avec leur chemin complet. Si vous ne le saviez pas l'auteur du document se prénomme Vincent,  travaille sous Linux et utilise Nextcloud. Échaudé je jette un coup d'œils aux méta-données mais rien de méchant à ce niveau là.

Notez au passage l'ordre totalement aléatoire des fichiers : ni alphabétique, ni date de modif ou de création, ni taille...

Bon, j'essaie d'enregistrer. Je sélectionne tout, je clique sur le bouton prévu à cet usage. Pourquoi suis-je surpris ? il m'est proposé le chemin enregistré et non le répertoire ou j'ai déplacé le pdf !  Arf... je change de répertoire, clique là où ça va bien et... constate qu'il n'a été enregistré qu'un seul fichier et qu'il m'est proposé de renouveler l'opération pour les 135 fichiers restants en repartant du chemin originel ! Naturellement je clique sur Annuler mais... il m'est demandé de cliquer 134 fois supplémentaires sur Annuler => console => killall Okular

Mais comment fait-il si le chemin n'existe pas ? Je renomme mon répertoire Musique en MusiqueSOS et recommence. Okular me demande donc de choisir un répertoire et - bonne nouvelle - le garde en mémoire. Mais l'idée de cliquer 136 fois sur Enregistrer me décourage donc retour à la console et re killall Okular.

Bon, si la plus grosse faute reviens d'abord à Lilypond (quelle idée de mémoriser le chemin des fichiers !) peut-être qu'un autre logiciel s'en sortira mieux que Okular ? Par exemple Firefox ?

Premier bon point Firefox n'affiche pas le chemin, ce qui confirme qu'il est vraiment focus sur la défense de la vie privée. Il me propose comme dossier d'enregistrement le dernier utilisé pour un téléchargement et mémorise le répertoire choisi pour le fichier suivant. Parce que ça c'est la mauvaise nouvelle : on ne peut sélectionner qu'un fichier à la fois.

Tient ! l'ordre est le même que celui affiché par Okular, c'est donc celui enregistré par Lily dans le PDF.

Passons à autre-chose. Dans l'environnement Gnome il y a Evince qui a plutôt bonne presse. Je l'installe et l'essaie aussitôt.

La présentation n'est pas top et on voit toujours le chemin (mais pour ça on connaît le coupable)

Je sélectionne quelques fichiers, clic droit, enregistrer sous...  Le répertoire qui m'est proposé est celui du PDF, ça me va et je clique sur le bon bouton. Miracle ? Non, pas du tout,  il n'y a rien d'enregistré nulle part ! Je sélectionne un seul fichier et  recommence (qui a dit têtu ?). Je vois alors que Evince me propose le chemin originel et ne veut pas en changer. Je recommence le renommage du répertoire Musique, me ressert un café et recommence. Bilan : il faut prendre les fichiers un par un et supprimer dans la zone de texte de l'adresse le chemin proposé pour ne laisser que le nom de fichier. Et ceci 136 fois !

MasterPdfEditor (logiciel privatif) voit qu'il y a des pièces jointes mais n'en voit pas le nom (difficile pour enregistrer) et Chrome, le navigateur de Google, ne sait même qu'il peut y avoir une pièce jointe dans un PDF. Quand à Acrobat Reader ça fait des années que cela n'existe plus sous Linux.

Mais bon sang mais c’est bien sûr ! (1) Rien ne vaut la ligne de commande
(1) référence à une série télé que seules les tête chenues ont pu connaître

man pdftk :

unpack_files
Copies all of the attachments from the input PDF into the current folder or to an output directory given after output. For example:

pdftk report.pdf unpack_files output ~/atts/

Et ça marche !

Conclusions :  Je ne me servirai plus de Lilypond pour attacher mes fichiers sources, cette histoire de chemin me défrise complètement. À la place je les mettrai dans un zip sans chemin (Ark fait ça très bien) puis je j'attacherai ce dernier au PDF avec pdftk avec lequel j'ai par ailleurs quelques options intéressantes :

attach_files <attachment filenames | PROMPT> [to_page <page number | PROMPT> | relation <relationship>]
Packs arbitrary files into a PDF using PDF's file attachment features. More than one attachment may be listed after attach_files. Attachments are added at the document
level unless the optional to_page option is given, in which case the files are attached to the given page number (the first page is 1, the final page is end). Attach‐
ments at the document level may be tagged with a relationship among Source, Data, Alternative, Supplement, and Unspecified (default).

For example:

pdftk in.pdf attach_files table1.html table2.html to_page 6 output out.pdf

pdftk in.pdf attach_files in.tex relation Source output out.pdf

--
Vincent Gay
Envoyé depuis mon saxo-phone :)
https://myrealbook.vintherine.org/ - http://photos.vintherine.org/

---

From: Jean-Jacques Gerbaud <[email-masked]>
Date: Mon, 30 Jan 2023 23:58:23 +0100

Le 30/01/2023 à 23:08, Vincent Gay a écrit :
> après quelques semaines de vacances (en fait de travaux de rénovation
> dans notre maison) je me suis remis gentiment gentiment à mon ouvrage
> lilypondien. Pour rappel il s'agit d'un recueil d'environ 150 partitions
..........

Bonsoir Vincent,

Avant d'aller me coucher, un petit dernier regard à mes messages et je
tombe sur ton dernier au sujet des chemins....

Moi aussi ça me hérisse mais je n'ai pas entamé un recueil de
récapitulation. Je te comprends mais je ne suis pas allé aussi loin pour
trouver une solution. Pour l'instant, je me contente de l'enregistrement
de base. Mes fichiers sont quand même enregistrés dans une certaine
logique :

Un fichier principal : Fichiers_Lilypond puis, par auteur : (Beethoven,
Boismortier, Campra, etc...) et dans chaque sous dossier les morceaux
.ly). (pas les mêmes genres de fichiers que toi ! :-)
Mais je dois dire qu'il y a des doublons, des bouts de codes qui se
promènent un peu partout et d'autres qui ne contiennent que les PDF,
(les fichiers .ly ayant disparu quelque part) ! Bref, il me faudrait un
bon bout de temps pour avoir quelque chose de propre.

Mais je te félicite de ta persévérance et surtout d'être arrivé à une
conclusion que te satisfasse.

En conclusion, rien ne vaut la ligne de commande ! Et si tu as un petit
tuto, peut être que ça pourra servir à d'autres.

Bonne nuit !

-- 
JJG
Drôme provençale

---

From: Jean Abou Samra <[email-masked]>
Date: Tue, 31 Jan 2023 00:04:27 +0100

Bonjour Vincent,

Intéressant ... Je pense qu'on peut légitimement considérer comme un bug le fait
que LilyPond puisse ajouter des fichiers avec des chemins absolus. Note que ce
n'est pas systématique, ça se produit si tu donnes toi-même d'une manière ou
d'une autre un chemin absolu quelque part, en l'occurrence probablement dans
les réglages des dossiers inclus de Frescobaldi (qui les passe à LilyPond
avec l'option -I).

Je suis trop fatigué ce soir, j'essaierai de réfléchir à ça demain.

Au passage, l'ordre dans lequel LilyPond met les pièces jointes, c'est juste
l'ordre des commandes \include.

Cordialement,
Jean

---

From: Jean Abou Samra <[email-masked]>
Date: Tue, 31 Jan 2023 00:22:31 +0100

> Je suis trop fatigué ce soir, j'essaierai de réfléchir à ça demain.

En attendant, j'ai quand même ouvert une page de bug :

https://gitlab.com/lilypond/lilypond/-/issues/6526

---

From: Vincent Gay <[email-masked]>
Date: Tue, 31 Jan 2023 08:45:57 +0100 (GMT+01:00)

> l'ordre des commandes \include.
Ah non vu que pour des raisons de toc j'ordonne moi-même les includes par ordre alphabétique. Bonne journée.

---

From: Ben <[email-masked]>
Date: Tue, 31 Jan 2023 09:04:24 +0100

Bonjour Jean-Jacques, 

Pour ma part, je gère tout avec un gros script python que j'appelle depuis frescobaldi:

Il me compile tous mes recueils de récapitulation, vérifie que toutes les partitions y soient représentées et me retournent celles qui n'y sont pas, me fait une page finale de statistiques, ainsi qu'un index par recueil et un index général qui permet de retrouver dans quel recueil est une partition donnée… J'y ai passé plusieurs jours, d'autant que je ne connaissais pas du tout le python, mais je ne peux plus m'en passer.

Au plaisir, 

Ben

> Le 30 janv. 2023 à 23:58, Jean-Jacques Gerbaud <[email-masked]> a écrit :
>

---

From: Jean Abou Samra <[email-masked]>
Date: Tue, 31 Jan 2023 13:05:35 +0100

> Le 31 janv. 2023 à 08:45, Vincent Gay <[email-masked]> a écrit :
> 
> 

Alors là, je ne comprends pas. D’après ma lecture du code, ils devraient apparaître dans l’ordre des commandes \include.

D’un côté, ça n’est pas très grave : il suffirait de trier les fichiers à inclure par ordre alphabétique juste avant de les
intégrer. D’un autre côté, j’aime bien creuser quand je ne comprends pas, on fait parfois des trouvailles. Tu voudrais bien m’envoyer le PDF (j’extrairai les sources avec pdftk) pour que je puisse analyser pourquoi les sources sont dans cet ordre ?

(En dehors des questions de droits d’auteur, il sera vraisemblablement trop lourd pour passer sur la liste.)

---

From: Vincent Gay <[email-masked]>
Date: Tue, 31 Jan 2023 20:55:46 +0100

Le 31/01/2023 à 13:05, Jean Abou Samra a écrit :
> Tu voudrais bien m’envoyer le PDF (j’extrairai les sources avec pdftk) pour que je puisse analyser pourquoi les sources sont dans cet ordre ?

le fichier est ici : 
https://zzz.zaclys.com/remise/5c58a7db0683e0036377e8ac9e59046f/2023-01-31_Recueil_Vincent.zip

Pour l'analyser il y a mieux que pdftk : la bibliothèque poppler qui 
fournit par exemple pdfdetach

pour simplement lister  les pièces jointes :
> pdfdetach -list Recueil-1.pdf

ce qui donne :
> 1: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1.ly
> 2: /home/vincent/Nextcloud2/Musique/Lilypond/Inclusions/jazzchords.ily
> 3: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/AfricanSkies.ly
> 4: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/Rapture.ly
> 5: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/RoadSong.ly
> 6: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/SantaCruz.ly
> 7: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/Sensuality.ly
> 8: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/September2nd.ly
> 9: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/Shadow.ly
> 10: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/Sidewinder.ly
> 11: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/SinceYouAsked.ly
> 12: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/SisterCheryl.ly
> 13: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/Slinky.ly
> ...

dans mon fichier l'ordre des inclusions est :
\include "jazzchords.ily"
\include "lilyjazz.ily"
\include "MRB22314.ly"

puis
include "213ChaCha.ly"
\include "500Miles.ly"
\include "AFelicidade.ly"
\include "AGoGo.ly"
\include "AfricanFlower.ly"
\include "AfricanQueen.ly"
\include "AfricanSkies.ly"
\include "AlfiesTheme.ly"
\include "AllBlues.ly"
\include "AloneTogether.ly"
\include "AlongCameBetty.ly"
etc...

à part les 3 premières toutes on fait l'objet le 27/01 d'un convert-ly 
-e * (ce qui explique leurs date de dernière modification)

-- 
Vincent Gay
Envoyé depuis mon saxo-phone :)
https://myrealbook.vintherine.org/  -http://photos.vintherine.org/

---

From: Vincent Gay <[email-masked]>
Date: Tue, 31 Jan 2023 21:00:12 +0100

Le 31/01/2023 à 00:04, Jean Abou Samra a écrit :
> Note que ce
J'ai testé cette hypothèse en mettant tous les fichiers inclus dans le 
même répertoire que mon fichier principal, en l’occurrence Recueil-1.test

pdfdetach -list 000Recueil.pdf
137 embedded files
1: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1.test/000Recueil.ly
2: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1.test/jazzchords.ily
3: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1.test/AfricanSkies.ly
4: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1.test/Rapture.ly
5: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1.test/RoadSong.ly
6: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1.test/SantaCruz.ly
7: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1.test/Sensuality.ly
8: /home/vincent/Nextcloud2/Musique/Recueils/Recueil-1.test/September2nd.ly
etc...

Détail amusant, c'est le même ordre que dans l'exemple précédent, ce qui 
exclue définitivement l'ordre par date de modification puisque entre 
temps j'ai passé jazzchords.ily lilyjazz.ily et MRB22314.ly en 2.24

---

From: Jean Abou Samra <[email-masked]>
Date: Tue, 31 Jan 2023 21:04:28 +0100

On 31/01/2023 21:00, Vincent Gay wrote:
> J'ai testé cette hypothèse en mettant tous les fichiers inclus dans le même répertoire que mon fichier principal, en l’occurrence Recueil-1.test
> 
> Détail amusant, c'est le même ordre que dans l'exemple précédent, ce qui exclue définitivement l'ordre par date de modification puisque entre temps j'ai passé jazzchords.ily lilyjazz.ily et MRB22314.ly en 2.24

Mais toujours dans Frescobaldi ? Car il passe le fichier .ly
lui-même avec un chemin absolu, à ce que je vois. J'ai testé
avec les fichiers extraits du PDF que tu as partagé, et j'obtiens
des chemins relatifs avec

$ lilypond -dembed-source-code Recueil.ly

(dans le dossier où j'ai mis tout ça), alors que

$ lilypond -dembed-source-code $(pwd)/Recueil.ly

met effectivement des chemins absolus de partout.

(Pour l'ordre, je crois que je suis en train de comprendre.)

---

From: Vincent Gay <[email-masked]>
Date: Tue, 31 Jan 2023 21:47:45 +0100

OK, bien compris. Ce qui dédouane donc au moins partiellement Lilypond 
même si je maintiens que même dans le cas

on ne devrait pas voir de chemin, même relatif. Mais je conçois qu'il 
peut être difficile pour un développeur de Lily d'imaginer les 
conséquence de ceci sur la protection de la vie privée.

Ceci-dit reste les difficultés d'extraction liées aux visionneuses de 
documents. N'ayant ni  Windows ni mac-OS sur aucune de mes machines 
quelqu'un(e) de cette liste aurait-iel la gentillesse de tester avec 
acrobat reader et / ou tout autre logiciel permettant d'afficher des pdf 
sur ces système d'exploitation ? D'avance merci.

Enfin s'il était possible d'avoir une option de Lily pour compresser 
toutes les sources embarquées ce serait Byzance.

---

From: Jean Abou Samra <[email-masked]>
Date: Tue, 31 Jan 2023 22:02:20 +0100

On 31/01/2023 21:47, Vincent Gay wrote:
> OK, bien compris. Ce qui dédouane donc au moins partiellement Lilypond même si je maintiens que même dans le cas
> 
> on ne devrait pas voir de chemin, même relatif.

Oui, on est d'accord là-dessus (d'où la page de bug).

Mais je conçois qu'il peut être difficile pour un développeur de Lily d'imaginer les conséquence de ceci sur la protection de la vie privée.

Je pense surtout que personne n'avait vraiment remarqué le bug : comme
Frescobaldi n'affiche pas les fichiers inclus, c'est le genre de chose
qu'on teste plutôt en compilant le fichier depuis la ligne de commande et
en visualisant le résultat dans Evince ou autre. Il est rare pour moi
de compiler un fichier avec "lilypond /chemin/absolu/vers/fichier.ly",
je fais plutôt "lilypond fichier.ly" après un "cd" dans le dossier.

> Ceci-dit reste les difficultés d'extraction liées aux visionneuses de documents. N'ayant ni  Windows ni mac-OS sur aucune de mes machines quelqu'un(e) de cette liste aurait-iel la gentillesse de tester avec acrobat reader et / ou tout autre logiciel permettant d'afficher des pdf sur ces système d'exploitation ? D'avance merci.
> 
> Enfin s'il était possible d'avoir une option de Lily pour compresser toutes les sources embarquées ce serait Byzance.

Tu veux dire les mettre dans une archive ZIP ? J'ai bien
peur que ce ne soit demander un peu trop : il faudrait
pour cela une nouvelle dépendance (libzip ou équivalent),
et vu l'énergie de maintenance que cela absorbe déjà
de faire compiler LilyPond sur macOS et surtout de le
compiler pour Windows sous Linux, c'est quelque chose
qu'on n'envisage que pour de très bonnes raisons.

Cordialement,
Jean

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 31 Jan 2023 22:12:28 +0100

> Le 31 janv. 2023 à 21:47, Vincent Gay <[email-masked]> a écrit :
> 

Bonsoir,

Test avec Mac OSX :
- la visionneuse par défaut du Mac est le logiciel Aperçu : il ouvre le fichier PDF, mais je ne vois pas les fichiers lilypond ;
- avec Adobe Acrobat Reader, les pièces jointes sont présentes, et téléchargeables une par une. 

Je viens d’ouvrir le fichier avec la visionneuse de Firefox, celle-ci me donne accès à l’ensemble des fichiers .ly en téléchargement un par un.

À votre disposition pour d’autres tests,
Philippe

---

From: Vincent Gay <[email-masked]>
Date: Tue, 31 Jan 2023 22:45:38 +0100 (GMT+01:00)

31 janv. 2023 22:12:31 [email-masked]:

> avec Adobe Acrobat Reader, les pièces jointes sont présentes, et téléchargeables une par une.
Merci beaucoup Philippe.

J'espérais que l'herbe puisse être plus verte ailleurs mais il semble que non. Je comprends bien qu'un pdf avec 150 pièces-jointes ça ne doit pas se voir tous les jours, aussi je pense que je vais zipper le tout et l'attacher avec un logiciel externe.

---

From: Jean Abou Samra <[email-masked]>
Date: Tue, 31 Jan 2023 23:46:32 +0100

> J'espérais que l'herbe puisse être plus verte ailleurs mais il semble que non. Je comprends bien qu'un pdf avec 150 pièces-jointes ça ne doit pas se voir tous les jours, aussi je pense que je vais…

Bon, j'ai quand même un truc à te proposer :

\version "2.24.0"

% AVANT le book
#(define embed-source-code
   (if (ly:get-option 'embed-source-code)
       (begin
        (ly:set-option 'embed-source-code #f)
        #t)
       #f))

\book {
  { c' }
}

% APRÈS le book
#(let* ((zipname (string-append (ly:parser-output-name) ".zip"))
        (pdfname (string-append (ly:parser-output-name) ".pdf"))
        (tmpname (string-append pdfname ".tmp"))
        (sources (filter (lambda (s)
                           (not (string-startswith s (ly:get-option 'datadir))))
                         (map ly:find-file (delete "<included string>" (ly:source-files))))))
   (apply system* "zip" "-jq" zipname sources)
   (system* "pdfattach" pdfname zipname tmpname)
   (rename-file tmpname pdfname)
   (delete-file zipname))

Si LilyPond est lancée avec -dembed-source-code, ce code désactive
le fonctionnement normal de -dembed-source-code, et insère une archive
ZIP à la place. Évidemment, l'inconvénient, c'est qu'il faut
avoir installé les programmes zip et pdfattach (le second vient de
Poppler) pour compiler le fichier avec -dembed-source-code.

J'ai mis l'option -j de zip pour qu'il n'y ait aucun chemin à l'intérieur
de l'archive.

En espérant que ça t'aide ...

Jean

---

From: Valentin Villenave <[email-masked]>
Date: Wed, 1 Feb 2023 00:06:49 +0100

On 31/01/2023 00:04, Jean Abou Samra wrote:
> Je pense qu'on peut légitimement considérer comme un bug le fait
> que LilyPond puisse ajouter des fichiers avec des chemins absolus.

On pourrait le présenter dans l’autre sens : à partir du moment où 
LilyPond n’inclut pas une information qui lui est communiquée, il y a 
une perte d’information et une modification de la structure du système 
de fichiers (par exemple en mettant un fichier inclus avec -I dans le 
même répertoire que celui du fichier qui y fait appel).

À mon sens ce n’est pas un bug, c’est juste le résultat de la façon dont 
Frescobaldi a choisi de fonctionner par défaut. (Personnellement 
j’invoque toujours lilypond avec un chemin relatif pour cette raison 
précise.)

Par ailleurs si on veut trouver des failles de sécurité dans LilyPond, 
la façon dont les PDF sont générés permet de connaître quelques détails 
personnels qui me semblent tout aussi inconfortables, par exemple le nom 
des fontes installées, la version de gs utilisée, etc.

Maintenant puisque de toute façon il y a des choses à rafraîchir pour 
Cairo, c’est peut-être le moment opportun pour une remise à plat. 
Toutefois le fonctionnement actuel n’est pas le résultat d’un oubli : 
c’est le seul fonctionnement qui me semble acceptable pour ne pas perdre 
d’information.

-- V.

---

From: Jean Abou Samra <[email-masked]>
Date: Wed, 1 Feb 2023 00:33:01 +0100

On 01/02/2023 00:06, Valentin Villenave wrote:
> On pourrait le présenter dans l’autre sens : à partir du moment où LilyPond n’inclut pas une information qui lui est communiquée, il y a une perte d’information et une modification de la structure du système de fichiers (par exemple en mettant un fichier inclus avec -I dans le même répertoire que celui du fichier qui y fait appel).

C'est vrai qu'il y a une modification de la structure du système
de fichiers.

Si l'utilisateur écrit

\include "/home/nom/.../fichier.ly"

on ne peut pas grand-chose pour lui vu que la source .ly est
intrinsèquement liée à sa machine et ne sera pas compilable
ailleurs sans répliquer la structure.

De même, avec

\include "sous-dossier/fichier.ly"

où sous-dossier/ est dans le même dossier que le fichier principal,
on peut se poser la question d'enlever la partie "sous-dossier/" ou
pas. Il est sans doute légitime dans ce cas de ne pas oublier le
dossier mais d'inclure vraiment le fichier avec ce chemin relatif dans
le PDF.

Par contre, pour -I absolu et \include relatif, je vois pas vraiment
l'inconvénient de garder un chemin relatif à l'intérieur de l'archive
en oubliant le -I. C'est vrai que ça fait un peu bizarre... mais après
tout ça marche.

Autrement dit :

\include absolu => on ne peut rien y faire (sauf peut-être un warning)

\include relatif => on met le même chemin relatif dans l'archive,
                    quel qu'ait été le dossier (-I ou autre) où a
                    été trouvé le fichier inclus

> À mon sens ce n’est pas un bug, c’est juste le résultat de la façon dont Frescobaldi a choisi de fonctionner par défaut. (Personnellement j’invoque toujours lilypond avec un chemin relatif pour cette raison précise.)

D'un côté, c'est vrai que c'est logique. D'un autre côté, je
comprends le sentiment de Vincent d'avoir eu une mauvaise surprise,
donc on peut réfléchir à l'améliorer, ne serait-ce qu'à coups
de warnings.

> Par ailleurs si on veut trouver des failles de sécurité dans LilyPond, la façon dont les PDF sont générés permet de connaître quelques détails personnels qui me semblent tout aussi inconfortables, par exemple le nom des fontes installées, la version de gs utilisée, etc.

Hum, hum. https://gitlab.com/lilypond/lilypond/-/issues/6451

Avec un problème similaire lorsque les utilisateurs distribuent
par mégarde des fichiers compilés avec point-and-click.

Hum hum. Embarrassant, toute cette affaire.

> Maintenant puisque de toute façon il y a des choses à rafraîchir pour Cairo, c’est peut-être le moment opportun pour une remise à plat. Toutefois le fonctionnement actuel n’est pas le résultat d’un oubli : c’est le seul fonctionnement qui me semble acceptable pour ne pas perdre d’information.

Malheureusement, pour Cairo, -dembed-source-code est un peu au point mort en
ce moment, cf.

https://gitlab.com/lilypond/lilypond/-/issues/6502

Maintenant, je suis d'accord sur le fait qu'une révision des chemins
qui peuvent être inclus dans le PDF serait opportune.

En tous cas, merci pour avoir précisé le contexte, et je suis d'accord
sur le fait que le problème n'est pas si simple.

Cordialement,
Jean