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