Re: Inclusion des sources

[Jean Abou Samra]

On 01/02/2023 00:06, Valentin Villenave wrote:
> 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).


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

OpenPGP_signature
Description: OpenPGP digital signature