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

From: "Xavier Scheuer" <[email-masked]>
Date: Sun, 20 Jan 2008 15:44:19 +0100

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

---

From: Nicolas Sceaux <[email-masked]>
Date: Sun, 20 Jan 2008 19:03:31 +0100

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

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

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.

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

---

From: "Gilles THIBAULT" <[email-masked]>
Date: Sun, 20 Jan 2008 22:57:26 +0100

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 s1*14 \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

---

From: discussions-sur-forums <[email-masked]>
Date: Sun, 20 Jan 2008 23:34:35 +0100

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 :
>             \violinI <file://%5C%5CviolinI>
>             \pgebreak
>         >>
> 3-
> ------------------------------------------------------------------------
>
> _______________________________________________
> liste de diffusion lilypond-user-fr
> [email-masked]
> http://lists.gnu.org/mailman/listinfo/lilypond-user-fr
>

---

From: Xavier Scheuer <[email-masked]>
Date: Sun, 20 Jan 2008 23:53:00 +0100

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

---

From: "Gilles THIBAULT" <[email-masked]>
Date: Mon, 21 Jan 2008 00:01:16 +0100

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

---

From: Xavier Scheuer <[email-masked]>
Date: Mon, 21 Jan 2008 01:07:28 +0100

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

---

From: Nicolas Sceaux <[email-masked]>
Date: Mon, 21 Jan 2008 22:08:36 +0100

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

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

> 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

---

From: discussions-sur-forums <[email-masked]>
Date: Tue, 22 Jan 2008 07:19:43 +0100

Remarques et proposition dans le texte.

>> que de "gagner" une compilation.
Je vois mal qu'un algorithme puisse être meilleur qu'un calcul 
*rigoureux*...

> é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.
> débordera sur deux pages.
Il ne faudrait pas que tout soit trop tassé? ou mettre une option de 
tassement?
> (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
Cf ci-dessus.

---

From: Xavier Scheuer <[email-masked]>
Date: Wed, 23 Jan 2008 01:58:48 +0100

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

> le calcul au plus près, utilise optimal-page-breaks, sinon,

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

> débordera sur deux pages.

J'apprends plein de choses!  ;-)
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)?

> plus efficace. Pour cela, il faut l'utiliser et reporter des bugs ou

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

---

From: Nicolas Sceaux <[email-masked]>
Date: Wed, 23 Jan 2008 20:15:14 +0100

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

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

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

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

---

From: denis queffeulou <[email-masked]>
Date: Sat, 26 Jan 2008 15:26:31 +0100

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