Re: setting the number of pages for a score

[Han-Wen Nienhuys]

Joe Neeman wrote:

> > I don't understand; how do you use line breaking in the page-breaker? 
> > Within the current architecture, the vertical formatting step is non 
> > reversible, so you can't really figure out the height of one 
> > line-break  configuration (which requires vertical formatting), and 
> > then try with another set of line-breaks.

> My current code involves having Grob::fixup_refpoint and 
> Grob::handle_broken_dependencies store their previous state. I added 
> Grob::undo_fixup_refpoint, Grob::undo_broken_dependencies and 
> Grob::undo_break_processing to revert to the previous state. Something 
> is going wrong though -- it's either a problem with my implementation or 
> it's something happening in scheme callbacks that I haven't traced yet. 
> After 5 or 6 re-line-breaks, object_alist_'s start to disappear and I 
> get systems with empty extent.

alists disappearing are suicide() calls. When a spanner is broken in 
pieces, its original is suicide()d. The same happens with unneeded 
broken/unbroken items at line breaks/non line breaks.

> There's probably also some caching happening with the Y-extent 
> callbacks, but I'm not up to the point of worrying about that yet.
>
> > Doing that would require some copy-on-write mechanism, so can you 
> > store the pre-line-break state of the formatting problem and run the 
> > line-breaking/formatting-step in on a copy.  That's sort of hairy, 
> > although it should be doable: all state is maintained as Scheme 
> > alists. It's a matter of copying each grob, and doing a global pointer 
> > subsititution. Of course, there will be some details, and the 
> > copy-on-write would have to function across \score boundaries, since a 
> > page may have multiple \scores.
>
> Do you think it's actually necessary to copy the C++ grobs, or would it 
> be sufficient to capture the scheme state? I only ever need to undo one 
> level, so I didn't think capturing the scheme state would be too hard.

I think it would be safest to also store C++ state, but you should be 
able to skip the pointer substitution (ie. making copied grobs point to 
other copies.). Then you don't have to worry about state leaking from 
one pass into an other, and extent caching/refpoints are handled as well 
(the Y-extent ends up in the C++ Dimension_cache dim_cache_ member). You 
have to make a deep copy of everything in object_alist_ though.

> > The code looks good, I'm actually surprised at how simple it is!
> >
> > I expect that a full optimal page layout module is still far away, but 
> > we could roll out constrained line breaking relatively easily. For a 
> > lot of music, specifying a system count will make it easy to force a 
> > piece onto a number of pages, with a few well-placed \pageBreaks. Much 
> > easier than it is now anyway. What do you think?
>
> Yes, I think that might be possible without too much work. Maybe we 
> could allow the user to specify a global page-break-system-extent. We 
> then do the page breaking assuming all music systems have that Y-extent. 
> For 95% of the music I would use this for, that would be acceptable 
> since Y-extents don't vary too much. I think the main problem would be 
> if there are sections with more or less staves than other sections. But 
> this could work in the meantime.

Yes, this is a good idea; could you prepare a patch for that?

> I had started to write my page breaker in C++ because I thought it would 
> be slow. But maybe with this simplified version, it would be much easier 
> to write it in scheme ... so should I add scheme bindings to the line 
> breaker?

No, we don't have any for the current either.

> ...which reminds me: in order to allow line breaking to happen after the 
> number of systems is decided, I attach a patch that will delay 
> Gourlay_breaking until/unless ly:paper-book-systems is called.

I guess I have to see the page breaker patch before I can see the full 
picture.

--
 Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen