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

[discussions-sur-forums]

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.