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

Bonjour,

Je suis récemment passé à la version 2.11.37 de lilypond (auparavant j'utilisais la 2.10.25 présente dans les dépôts d'Ubuntu 7.04) et en compilant mon fichier, je n'arrive pas à obtenir le même résultat que précédemment.
Je m'explique.

La partition (conducteur) se compose de 6 portées différentes (un StaffGroup de 4 portées et un PianoStaff de 2 portées).
En définissant #(set-global-staff-size 14), j'arrivais à avoir 3 systèmes par pages avec lilypond 2.10 alors qu'il n'en met que 2 avec la version 2.11 (et le résultat n'est vraiment pas beau).
J'ai essayé de modifier divers paramètres pour obliger lilypond à mettre 3 systèmes par pages (surtout que visiblement il y a la place nécessaire) sans résultats.
J'ai suivi les conseils de la documentation mais aucune des commandes suivantes n'arrive au résultat escompté.

  • #(define page-breaking ly:minimal-breaking)
  • page-limit-inter-system-space = ##t
    page-limit-inter-system-space-factor = 0.5
  • between-system-padding = #0.1
    between-system-space = #0.1
  • ragged-bottom = ##f
    Et même system-count = #3 ne fonctionne pas (Calcul des sauts de ligne... Avertissement : impossible de trouver un saut de ligne qui satisfasse aux contraintes et ça plante dès la 2e page).
    Pour arriver à 3 systèmes par pages avec la version 2.11 je suis obligé de définir #(set-global-staff-size 12.60) (#(set-global-staff-size 13) n'en mettant également que 2), mais ça commence vraiment à faire petit.
    Ce que je ne comprends pas surtout c'est cette différence de comportement entre la 2.10 et la 2.11 et surtout le fait que le résultat est meilleur avec la version la plus ancienne.
    Si bien que j'en arrive à me demander s'il ne s'agirait pas d'une "régression"...

Est-ce que l'un d'entre vous aurait une idée pour "résoudre" ce problème (sans changer global-staff-size 14)?

Vous trouverez ci-joint le fichier .ly du conducteur (pour compiler il vous faudra également les autres fichiers contenant les notes des différentes voix, disponibles sur simple demande) et, pour mieux illustrer mes propos, voici les URL des images des 2 premières pages, respectivement avec la version 2.10 et 2.11 (et annotate-spacing = ##t).

http://img124.imageshack.us/img124/3794/canon210page1jb1.png
http://img124.imageshack.us/img124/6334/canon210page2ce1.png
http://img134.imageshack.us/img134/2976/canon211page1qv6.png
http://img413.imageshack.us/img413/8418/canon211page2wq0.png

Un grand merci d'avance.

Xavier Scheuer

canon.ly (1.59 KB)

[...]
J'ai essayé de modifier divers paramètres pour obliger lilypond à mettre 3 systèmes par pages (surtout que visiblement il y a la place nécessaire) sans résultats.
J'ai suivi les conseils de la documentation mais aucune des commandes suivantes n'arrive au résultat escompté.
  • #(define page-breaking ly:minimal-breaking)

ly:minimal-breaking ne va être d'aucune aide ici, dans la mesure où cet
algo utilise la même estimation de la hauteur des différent systèmes que
les autres algo de calcul des sauts de page. Je pense qu'ici c'est
l'estimation de la hauteur qui pause problème et qui laisse penser à
l'algo de calcul des sauts de page que seulement 2 systèmes tiennent sur
la page.

  • page-limit-inter-system-space = ##t
page-limit-inter-system-space-factor = 0.5

Cela sert à limiter l'espace entre deux systèmes, ça n'influe pas sur le
calcul des sauts de page mais sur la répartition des systèmes sur une page,
une fois les sauts de pages calculés.

  • between-system-padding = #0.1
between-system-space = #0.1

Ces deux là en revanche peuvent influer sur les sauts de pages. Tu peux les
mettre à 0 même pour voir.

  • ragged-bottom = ##f

Ca n'influe pas sur le calcul des sauts de pages, mais seulement sur la
façon de répartir les systèmes sur une page.

Et même system-count = #3 ne fonctionne pas (Calcul des sauts de ligne... Avertissement : impossible de trouver un saut de ligne qui satisfasse aux contraintes et ça plante dès la 2e page).
Pour arriver à 3 systèmes par pages avec la version 2.11 je suis obligé de définir #(set-global-staff-size 12.60) (#(set-global-staff-size 13) n'en mettant également que 2), mais ça commence vraiment à faire petit.
Ce que je ne comprends pas surtout c'est cette différence de comportement entre la 2.10 et la 2.11 et surtout le fait que le résultat est meilleur avec la version la plus ancienne.
Si bien que j'en arrive à me demander s'il ne s'agirait pas d'une "régression"...

Je vais tenter une explication, qui ne sera peut-être pas exacte dans
la mesure où je ne me souviens plus exactement à quel moment certaines
évolutions ont eu lieu.

Dans la version 2.10 (?), les systèmes étaient entièrement dessinés
préalablement au calcul des sauts de pages. Résultat, les algos de calcul
des sauts de pages savaient exactement la hauteur des systèmes, et donc
pouvaient les placer au plus près.

Dans la version 2.11, les systèmes ne sont pas dessinés avant le calcul
des sauts de page, les algo utilisent une estimation de la hauteur des
système. Cette estimation est majorée de 10% il me semble pour éviter de
se retrouver avec des pages contenant plus de systèmes qu'elles ne
pouvaient en contenir. Un désavantage que présente cette technique est
celui que tu rencontres ici : on aurait pu mettre plus de systèmes sur
la page. Mais il y a aussi des avantages qui valent le coup :
  - en ne dessinant les systèmes qu'après avoir calculé les sauts de pages,
on sait au moment de les dessiner combien il y a de rab sur la page, que
l'on peut réinjecter dans les systèmes pour les aggrandir.
  - cela permet aussi le système de référence des numéros de page et des
tables de matières.
Auparavant, pour accomplir cela, il fallait effectuer 2 invocations de
LilyPond, la première servant à déterminer les sauts de pages, la seconde
utilisant ces données pour aggrandir les systèmes, ou construire une table
des matières.

Ce n'est pas une regression, puisque l'ancien comportement est toujours
disponible (voir plus bas).

Est-ce que l'un d'entre vous aurait une idée pour "résoudre" ce problème (sans changer global-staff-size 14)?

Plusieurs facteurs vont influer sur le calcul des saut de pages :
  - l'espace minimal entre les systèmes : between-system-padding
  - la hauteur estimée des systèmes, que tu peux essayer de réduire
en modifiant la hauteur minimale entre deux portées d'un système, par
exemple :
   \context {
     \Staff
     \override VerticalAxisGroup #'minimum-Y-extent = #'(-2 . 2)
   }

Tu peux aussi utiliser l'algo "classique" de 2.10: optimal-page-breaking
(sans "ly:").

Nicolas

···

Le 20 janv. 08 à 15:44, Xavier Scheuer a écrit :

Est-ce que l'un d'entre vous aurait une idée pour "résoudre" ce problème (sans changer global-staff-size 14)?

J'ai aussi beaucoup galéré avec certaines mises en page, et la chose suivante semble marcher :

1-
mettre une voix destinée uniquement au saut de page du genre
pgebreak = {s1 12 \pagebreak s114 \pagebreak ....}
2-
L'incorporer dans une piste, genre
<<
\violinI
\pgebreak

3-
Rajouter le code suivant dans le \layout :

\layout {
\context {
\Score
\override NonMusicalPaperColumn #'page-break-permission = ##f
}
}

Parfois Lilypond grogne un peu, mais ça l'oblige à faire les tournes de page exactement où l'on veut.
Dis moi si ça marche.Si tu n'as que 4 ou 5 pages ça devrait être assez rapide.

Gilles

As-tu vu une différence entre mettre les pagebreak 1) dans une voix dédié, comme ci-dessous, ou 2) les mettre plus classiquement à différents endroits d'une voix déjà existante?

Gilles THIBAULT 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)!

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...

Même en mettant between-system-padding et between-system-space à 0 lilypond (2.11) s'obstine à ne mettre que 2 systèmes sur la pages (collés l'un à l'autre avec plus d'un tiers de page vide).
À croire qu'il a déjà déterminé le nombre de pages avant!

Un grand merci pour l'explication, c'est vraiment intéressant.
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.
Cela en "vaut-il vraiment le coup"?
2 arguments (personnels à nouveau) dans ce sens :

  • les sauts de pages (nombres de systèmes par page) sont bien plus utilisés que les systèmes de référence (qui ont peu de chances d'être utilisés par un "débutant")
  • LaTeX nécessite aussi 2 compilations pour les références croisées
    Bref, le rôle principal de lilypond est de faire de belles partitions et pour ce faire je pense qu'il est préférable de bien calculer le nombre de systèmes par page plutôt que de se doter d'un système de référence type LaTeX au prix d'une approximation dans le rendu final des partitions.
    N'est-ce pas la philosophie de Gnome (et GNU en général) : "un logiciel pour chaque chose mais il le fait bien"?

Seul optimal-page-breaks (et non optimal-page-breaking) m'a donné 3 systèmes par page.

Je vais adopter cette solution cette fois-ci et garder tout ceci à l'esprit pour mes prochaines partitions.
Encore merci pour cette réponse.

Xavier

···

Le dimanche 20 janvier 2008 à 19:03 +0100, Nicolas Sceaux a écrit :

Le 20 janv. 08 à 15:44, Xavier Scheuer a écrit :
> [...]
> J'ai essayé de modifier divers paramètres pour obliger lilypond à  
> mettre 3 systèmes par pages (surtout que visiblement il y a la place  
> nécessaire) sans résultats.
> J'ai suivi les conseils de la documentation mais aucune des  
> commandes suivantes n'arrive au résultat escompté.
> 	• #(define page-breaking ly:minimal-breaking)

ly:minimal-breaking ne va être d'aucune aide ici, dans la mesure où cet
algo utilise la même estimation de la hauteur des différent systèmes que
les autres algo de calcul des sauts de page. Je pense qu'ici c'est
l'estimation de la hauteur qui pause problème et qui laisse penser à
l'algo de calcul des sauts de page que seulement 2 systèmes tiennent sur
la page.

> 	• page-limit-inter-system-space = ##t
> page-limit-inter-system-space-factor = 0.5

Cela sert à limiter l'espace entre deux systèmes, ça n'influe pas sur le
calcul des sauts de page mais sur la répartition des systèmes sur une  
page,
une fois les sauts de pages calculés.

> 	• between-system-padding = #0.1
> between-system-space = #0.1

Ces deux là en revanche peuvent influer sur les sauts de pages. Tu  
peux les
mettre à 0 même pour voir.

> 	• ragged-bottom = ##f

Ca n'influe pas sur le calcul des sauts de pages, mais seulement sur la
façon de répartir les systèmes sur une page.

> Et même system-count = #3 ne fonctionne pas (Calcul des sauts de  
> ligne...  Avertissement : impossible de trouver un saut de ligne qui  
> satisfasse aux contraintes et ça plante dès la 2e page).
> Pour arriver à 3 systèmes par pages avec la version 2.11 je suis  
> obligé de définir #(set-global-staff-size 12.60) (#(set-global-staff- 
> size 13) n'en mettant également que 2), mais ça commence vraiment à  
> faire petit.
> Ce que je ne comprends pas surtout c'est cette différence de  
> comportement entre la 2.10 et la 2.11 et surtout le fait que le  
> résultat est meilleur avec la version la plus ancienne.
> Si bien que j'en arrive à me demander s'il ne s'agirait pas d'une  
> "régression"...

Je vais tenter une explication, qui ne sera peut-être pas exacte dans
la mesure où je ne me souviens plus exactement à quel moment certaines
évolutions ont eu lieu.

Dans la version 2.10 (?), les systèmes étaient entièrement dessinés
préalablement au calcul des sauts de pages. Résultat, les algos de  
calcul
des sauts de pages savaient exactement la hauteur des systèmes, et donc
pouvaient les placer au plus près.

Dans la version 2.11, les systèmes ne sont pas dessinés avant le calcul
des sauts de page, les algo utilisent une estimation de la hauteur des
système. Cette estimation est majorée de 10% il me semble pour éviter de
se retrouver avec des pages contenant plus de systèmes qu'elles ne
pouvaient en contenir. Un désavantage que présente cette technique est
celui que tu rencontres ici : on aurait pu mettre plus de systèmes sur
la page. Mais il y a aussi des avantages qui valent le coup :
  - en ne dessinant les systèmes qu'après avoir calculé les sauts de  
pages,
on sait au moment de les dessiner combien il y a de rab sur la page, que
l'on peut réinjecter dans les systèmes pour les aggrandir.
  - cela permet aussi le système de référence des numéros de page et des
tables de matières.
Auparavant, pour accomplir cela, il fallait effectuer 2 invocations de
LilyPond, la première servant à déterminer les sauts de pages, la  
seconde
utilisant ces données pour aggrandir les systèmes, ou construire une  
table
des matières.

Ce n'est pas une regression, puisque l'ancien comportement est toujours
disponible (voir plus bas).

> Est-ce que l'un d'entre vous aurait une idée pour "résoudre" ce  
> problème (sans changer global-staff-size 14)?

Plusieurs facteurs vont influer sur le calcul des saut de pages :
  - l'espace minimal entre les systèmes : between-system-padding
  - la hauteur estimée des systèmes, que tu peux essayer de réduire
en modifiant la hauteur minimale entre deux portées d'un système, par
exemple :
   \context {
     \Staff
     \override VerticalAxisGroup #'minimum-Y-extent = #'(-2 . 2)
   }

Tu peux aussi utiliser l'algo "classique" de 2.10: optimal-page-breaking
(sans "ly:").

Nicolas

As-tu vu une différence entre mettre les pagebreak 1) dans une voix dédié, comme ci-dessous, ou 2) les mettre plus classiquement à différents endroits d'une voix déjà existante?

En principe il n'y en a pas.
Mais comme on a généralement aussi besoin d'imprimé les parties séparées il faut mieux mettre les changements de page du score séparément

Gilles

Je viens d'essayer.

Effectivement, ça fonctionne (et mieux si on "force" aussi les sauts de lignes).
Il n'a pas grogné lors de la compilation mais je vois bien que ça ne l'enchante guère... :wink:
En effet, je l'ai forcé à faire les mêmes sauts de lignes et sauts de page que la partition obtenue avec optimal-page-breaks (3 systèmes par page donc) et si j'ai bien 3 systèmes par pages, le résultat est (légèrement) moins bien qu'en le laissant le faire lui-même avec l'algorithme "classique".
Le défaut qui frappe le plus ce sont les premières notes de la mesure qui sont en général vraiment très proches (trop proches en fait) de la barre de mesure qui précède.

J'ai dû forcer les sauts de lignes aussi car en ne forçant que les \pageBreak il mettait à nouveau 2 systèmes par pages dans certains cas.
Il préférait ne mettre que 2 systèmes avec beaucoup de mesures dans chacun (où chaque mesure était écrasée) plutôt que 3 systèmes avec moins de mesures.
Autant vous dire que le résultat n'était franchement pas terrible (alors que, je me répète, il y a de la place pour 3 systèmes par page tout en gardant un rendu parfaitement lisible)!
Il semblerait donc que l'espacement vertical (estimé) prime sur l'espacement horizontal.

J'avais vu cette "astuce" dans la documentation mais je ne l'avais pas utilisée car j'estimais que lilypond ferait ça mieux que moi.
Le rôle de l'utilisateur c'est de transcrire une partition sous forme de texte brut et c'est à lilypond de mettre en page la partition le mieux possible (idéalement sans avoir besoin de "directives" de la part de ce dernier).

Cela dit merci pour ta réponse.
J'ai maintenant fait l'expérience des sauts de ligne/page explicites, je pense que cela me servira sûrement par après.

Xavier

···

Le dimanche 20 janvier 2008 à 22:57 +0100, Gilles THIBAULT a écrit :

Est-ce que l'un d'entre vous aurait une idée pour "résoudre" ce problème (sans changer global-staff-size 14)?

J'ai aussi beaucoup galéré avec certaines mises en page, et la chose suivante semble marcher :

1-

mettre une voix destinée uniquement au saut de page du genre

pgebreak = {s1 12 \pagebreak s114 \pagebreak ....}

2-

L'incorporer dans une piste, genre

<<

\violinI

\pgebreak

3-

Rajouter le code suivant dans le \layout :

\layout {
\context {

\Score

\override NonMusicalPaperColumn #'page-break-permission = ##f

}
}

Parfois Lilypond grogne un peu, mais ça l'oblige à faire les tournes de page exactement où l'on veut.

Dis moi si ça marche.Si tu n'as que 4 ou 5 pages ça devrait être assez rapide.

Gilles

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

···

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

Remarques et proposition dans le texte.

Nicolas Sceaux a écrit :

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 vois mal qu'un algorithme puisse être meilleur qu'un calcul *rigoureux*...

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)

Sur les forums lilypond, quand on voit la diversité des partitions, j'ai du mal à imaginer qu'un algorithme qui procède par des estimations, puisse donner un résultat correct dans tous les cas.

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.

Il ne faudrait pas que tout soit trop tassé? ou mettre une option de tassement?

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).

Effectivement, essayant de faire de gros livres de musique, avec des systèmes à plusieurs portées, mais sans table des matières, je n'ai pas trouvé d'algorithme lilypond de mise en page qui donne des résultats corrects. Je m'explique.
    Ces livres sont constitués de multiples scores (plusieurs centaines), chaque score fait de 1 à 5 pages. Ils sont presque tous séparés par des sauts de page, ce qui *doit* simplifier grandement la mise en page. Voici pourquoi.

    Actuellement, voici ce qui se passe classiquement avec tous les algorithmes, lors de la construction des livres score par score:

1) premier score: mise en page OK
2) saut de page, puis deuxième score: mise en page généralement OK
3) saut de page puis troisième score: dans le pdf, les deux derniers seront OK... mais la mise en page du premier score est chamboulée, la plupart du temps le nombre de système par page est réduit!! voire un seul système par page.
4) saut de page puis quatrième score: le premier score est OK, ce sont les 2ème et 4ème sont le nombre de systèmes par page a été réduit.
5) ... et ainsi de suite. En résumé, je fait une mini-modification au 31ème score, la mise en page du 7ème est changée.

Or un principe des logiciels de mise en page de quoi que ce soit, musique y compris, est le suivant:

<< Quand on insère un saut de page, cela *scelle* la mise en page du contenu précédent ce saut de page. >>

L'exception est le nombre de pages de la table des matières, si elle se situe au début du document. Et encore là, les logiciels procèdent comme suit: 1) construction de la table avec des numéros bidons pour réserver le nombre de pages de la table 2)
mise à jour de ces numéros. Donc le principe ci-dessus reste valable.

D'ailleurs, tu évoquais plus haut la complexité des algorithmes de mise en page de bouquins entiers: par expérience personnelle d'écriture de plusieurs logiciels de mises en pages dans d'autres contextes, mais valables ici, tu pourras nettement réduire la complexité de ces algorithmes, et donc les besoins en RAM et processeurs, en utilisant le principe évoqué ci-dessus.
    Plus précisément l'idée qu'utilisent les logiciels existants est, au lieu de mettre en page d'un coup tout le livre, il suffit de mettre en page ce qui est situé entre deux sauts de page consécutifs indépendemment du reste. Puis de boucler ainsi sur les sauts de page. Chacun de ces mini-livres demande bien moins de ressources à mettre en page.
    Même *mieux*: la quantité de ressources pour mettre en pages un livre de 1000 pages avec des sauts de pages toutes les 5 ou 10 pages n'est pas très supérieure à la quantité de ressources nécessaires pour mettre en page 10 pages et non PAS 1000! On a gagné un voire deux ordres de grandeur de ressources.
    Le truc génial, c'est qu'alors *on peut se permettre d'optimiser* son algorithme de mise en page comme on n'aurait pas pu le faire sinon.
       Ensuite côté utilisateur, on apprend à mettre les sauts de page là où il faut, suivant le contenu du livre, mais aussi suivant les ressources machine dont on dispose. (c'est valable pour de nombreux logiciels de mise en page, gratuits comme payants.)
       Bon, il faut que j'y aille.
    À ta disposition pour tout renseignement.

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.

Cf ci-dessus.

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.

J'ignorais que tu faisais également partie de l'équipe de développement, chapeau bas!

Pour ly:minimal-breaking, j'avais mal compris son rôle. Je pensais minimal dans le sens "nombre de pages minimal" et non "ressources minimales", d'où mon incompréhension.
Je viens de relire la documentation à ce sujet et je ne vois pas ce qui m'a laissé penser cela...

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.

Oui oui, ce n'est pas un problème.
C'est juste le fait que optimal-page-breaks est décrit dans la doc comme étant "l'ancien algorithme" (et donc dans mon esprit ancien = qui n'évoluera plus, amené à disparaître) et je voulais juste donner mon avis et dire que cet algorithme n'était pas si mal et pouvait encore servir (dans certains cas).
Ah oui, et je tenais quand même à préciser que je trouve lilypond extraordinaire et la doc géniale, même si en général on écrit parce qu'on a un problème ou un truc qui ne va pas (alors qu'on parle très peu de tout le reste qui fonctionne à merveille).

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.

J'apprends plein de choses! :wink:
Et donc si je comprends bien optimal-page-breaks (l'ancien algo), lui, calcule d'abord les sauts de ligne (tout en dessinant les systèmes) puis s'occupe des sauts de pages, c'est bien ça (je m'intéresse)?

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.

Sur ce point je n'ai qu'une chose à dire : je suis d'accord (il est perfectible, il a du potentiel) et courage aux programmeurs (pour le perfectionner et utiliser ce potentiel)! ;-D
De mon côté je ne manquerai pas de l'utiliser ; par contre je suis très peu familier aux procédures de report de bug et malheureusement je n'y connais quasi rien en programmation.

Merci!

Xavier

···

Le lundi 21 janvier 2008 à 22:08 +0100, Nicolas Sceaux a écrit :

Le lundi 21 janvier 2008 à 22:08 +0100, Nicolas Sceaux a écrit :

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

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.

J'ignorais que tu faisais également partie de l'équipe de développement, chapeau bas!

Pas vraiment, j'ai juste envoyé de façon sporadique quelques patches.

Pour ly:minimal-breaking, j'avais mal compris son rôle. Je pensais minimal dans le sens "nombre de pages minimal" et non "ressources minimales", d'où mon incompréhension.
Je viens de relire la documentation à ce sujet et je ne vois pas ce qui m'a laissé penser cela...

Dans la mesure où avec ly:minimal-breaking on remplit au maximum une
page avant de passer à la suivante, le nombre de pages totales (à
systèmes également chargés) sera minimal. Mais "minimal" est aussi
à comprendre dans le sens de la complexité de l'algo lui-même, le plus
simple possible, et donc le moins gourmant.

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.

J'apprends plein de choses! :wink:
Et donc si je comprends bien optimal-page-breaks (l'ancien algo), lui, calcule d'abord les sauts de ligne (tout en dessinant les systèmes) puis s'occupe des sauts de pages, c'est bien ça (je m'intéresse)?

C'est ça, les sauts de lignes sont calculés, les systèmes dessinés,
puis les sauts pages calculés, et enfin les pages dessinées.

Tandis qu'avec le nouvel algo par défaut, les sauts de lignes et de
pages sont calculés, puis les systèmes et les pages dessinées.

···

Le 23 janv. 08 à 01:58, Xavier Scheuer a écrit :

Le lundi 21 janvier 2008 à 22:08 +0100, Nicolas Sceaux a écrit :

Bonjour,

je me demandais si il était possible de faire figurer des bends dans les tablatures guitares.
Je n'ai pas trouvé cela dans la documentation, je suppose que ce n'est pas possible.

···

--
Denis