Re: Nombres de systèmes par page (2.10 - > 2.11)

[Nicolas Sceaux]

Le 20 janv. 08 à 23:53, Xavier Scheuer a écrit :

> It's not a bug, it's a feature!
>
> Non, plus sérieusement, un tout grand merci pour cette réponse.
> Non seulement c'est complet et bien expliqué, mais en plus on sait  
> le pourquoi des choses.
> Ça fait vraiment plaisir d'avoir des personnes qui connaissent bien  
> le sujet et qui partagent leur savoir en aidant les autres via cette  
> liste de diffusion (et en plus on reçoit la réponse dans sa langue  
> maternelle)!

En fait j'ai implémenté certains petits bouts, en tout cas j'ai pas mal
lu tout ce code, donc je comprends assez bien cette partie.

> Il faudra m'expliquer l'utilité de ly:minimal-breaking s'il utilise  
> la même estimation pour le calcul de la hauteur des systèmes (et  
> donc du nombre de systèmes par page) que ly:optimal-page-breaking...

ly:optimal-breaking tente de placer les sauts de lignes et les
sauts de page de telle façon que le résultat soit le plus homogène
possible sur la totalité du document. L'algorithme est assez coûteux
quand le nombre pièces et de lignes est élevé. Voire, dans le cas
d'un opéra entier, il peux ne pas finir du tout sur une machine bien
lotie en RAM et processeurs. Comme je fais des bouquins assez
volumineux, j'ai eu besoin d'algorithmes plus légers, c'est pourquoi
j'ai implémenté ly:minimal-breaking. Cet algo se contente dans
une premier temps de calculer tous les sauts de lignes sans
considérer la mise en page, puis place les systèmes obtenus sur les
pages selon une recette simpliste : mettre autant de système qu'on
peut sur une page, puis passer à la suivante. Par exemple si on a 4
systèmes, et que 3 tiennent sur une page, il fera une page de 3, et
une page de 1 système. Tandis que ly:optimal-breaking opère
différemment : il pourra faire deux pages 2 systèmes.

ly:minimal-breaking a aussi l'avantage de traiter les parties
textuelles plus élégemment : il remplira en entier une page de texte,
plutôt que de lisser le texte sur plusieurs page (avec du blanc en bas
des pages).

> [...]
> Bon alors je n'y connais pas grand chose en programmation et je suis  
> loin d'avoir une longue expérience de lilypond mais je trouve la  
> première démarche plus "logique".
> Je ne suis pas pour des systèmes "étirés", je préfère des systèmes  
> bien dessinés, quitte à devoir les espacer par après pour remplir la  
> page (espacer les systèmes plutôt que de les étirer).
> Surtout que dans certains cas (mon exemple en est la preuve), le  
> fait de vouloir étirer les systèmes plutôt que de les espacer  
> conduit à des espaces entre systèmes plus grands (un comble)!
>
> Quant à l'avantage du système de référence des numéros de page et  
> des tables de matières en une seule compilation je suis assez mitigé.
> Il est, à mon humble avis, préférable d'avoir un nombre de système  
> par page cohérent (et non résultant d'une vague estimation) plutôt  
> que de "gagner" une compilation.

Je ne partage pas cet avis. De plus, comme tu as toujours
optimal-page-breaks ce n'est même pas un problème. Si tu veux
le calcul au plus près, utilise optimal-page-breaks, sinon,
utilise les autres.

J'ai oublié un détail dans mon explication. Le nouvel algo
ly:optimal-page-breaking utilise des estimations des hauteurs
car il effectue à la fois le calcul des sauts de lignes *et*
des sauts de pages (c'est ça la raison première, les autres,
étirement et table des matières, ne sont que des conséquences)
C'est-à-dire qu'il pourra tasser un peu plus les notes pour faire
tout rentrer sur une page quand l'ancien algo optimal-page-breaks
débordera sur deux pages.

Je suis d'accord pour dire que le nouvel algo est perfectible, et
n'atteint peut-être pas la qualité de l'ancien dans certains cas
(en particulier des systèmes à plusieurs portées). Mais son potentiel
est bien plus élevé, il demande juste à être tournevissé pour être
plus efficace. Pour cela, il faut l'utiliser et reporter des bugs ou
proposer des patches.

Nicolas