Re: setting the number of pages for a score

[Joe Neeman]

> I doubt whethre this is convenient.  Since this isn't related to the 
> page size, i think it's easier to use staff-space here, eg. a normal 
> staff is 4 spaces high,
>
>  system-height = #4

Shouldn't this be something like 8 by default? It should approximate the 
stencil height of the staff and I think most staves are likely to have 
notes and markings above and below the staff.

> > System_spec::System_spec (Paper_score *ps, int n_brks)
>
>
> Yes, this is a good idea. My plan for the 3.0 syntax was to make 
> System_spec an explicit part of the input format. The book body is 
> just a list of system-specs.
>
> In your code, System_spec is a C++ object, not accessible from Scheme. 
> I think that this object should considered for smobification. This 
> will make dealing with GC easier. Right now, this code is leaking 
> memory, as the prob_ that is created from make_paper_system() is never 
> unprotected. An alternative is to store the prob_ reference
> in a Protected_scm too.

For now, I guess I can unprotect the probs after I've created the 
systems. But making the similarity between score systems and headers 
explicit sounds much nicer :)

> >   n_score_brk_ = 0;
>
>
> a nitpick, but can you use fully spelled words? This should probably be
>
>   score_break_count_
>
> or something similar. Similarly for idx.
>
>
> >   int p1_sys_left = me.p1_sys_ - 1;
> >   int p2_sys_left = me.p1_sys_ + me.p2_sys_ - 1;
>
>
> p1, p2  ?

int left_page_systems_remain = me.left_page_system_count_ - 1;
int systems_remain = me.left_page_system_count_ + 
me.right_page_system_count_ - 1;

Better? I'll clean up the rest of the variable names, too.

> Also, I prefer /**/ style comments.
>
> > // TODO: allow starting on the right-hand page
> > // this is quite long, but I can't see any obvious places to split it
> > Real
> > Optimal_breaking::best_page_force (vector<System_spec> const &sys,
> >                                    int nsys,
> >                                    vector<int> const &div,
> >                                    int p_num,
> >                                    bool last,
> >                                    int &p1_sys)
> > {
> >   SCM ph = ly_lily_module_constant("calc-page-height");
>
>
> You're hooking into the backend very directly; it would be better to do
>
>   (calc-height (make-page paper))

Ok, I'll do this. Then I can get rid of calc-page-height altogether.

> >   SCM props = book_->paper_->lookup_variable (ly_symbol2scm 
> > ("book-title-properties"));
> >   if (add_prob (props, book_->book_title ()))
> >     add_break_penalty (book_->header_);
>
>
>  I have some reservations about this, in the sense that the 
> interactions between paper_system, paper_score, score, book, etc. are 
> rather hairy now, with different code paths for normal use and 
> lilypond-book. I'm worried that this adds another path, which may lead 
> to more inconsistencies and bugs
>
> in particular, the following
>
> >   SCM page_properties
> >     = scm_call_1 (ly_lily_module_constant 
> > ("layout-extract-page-properties"),
> >           book_->paper_->self_scm ());
> >
> >   SCM header = SCM_EOL;
> >   for (SCM s = scm_reverse (book_->scores_); s != SCM_EOL; s = 
> > scm_cdr (s))
> >     {
>
> >  [..]
>
> Seems like duplication of code that we already have.

Yes, I duplicated a lot of code from Paper_book. Maybe the best solution 
is to make Paper_book capable of producing a vector of System_specs. 
That is, put the stuff that is currently in 
Optimal_breaking::create_system_list in Paper_book::system_specs(), say. 
Then Paper_book::systems () could call Paper_book::system_specs () 
before breaking the scores into lines, thereby avoiding duplicating all 
the making-headers code.

> How about the following proposal for integrating this work?
>
>  - my tentative schedule for 2.8 is to further stabilize 2.7 during 
> the month February, and release 2.8 somewhere in March.
>
>  - We could add restrained line breaking, eg. in 2.7.35, and let users 
> shake out bugs and other problems in that code.

How would users interact with restrained line breaking, though? 
Currently the only way is through Optimal_breaking since the hooks into 
line breaking are all on the C++ side. Also maybe I'll rename it 
constrained breaking since that's a better description.

>  - Once 2.8 is out of the door, we integrate optimal page breaking, 
> and refactor things on the input side, to put System_spec in as a part 
> of the input grammar.
>
>  - In the meantime, would it be worthwhile to setup some kind of 
> infrastructure so work on the page breaker can proceed in parallel?
That sounds good. The easiest thing (for me) to keep this in parallel 
would be to integrate the small changes (like the definition of 
optimal-page-breaking in layout-page-layout.scm and its call in 
paper-book.cc) because then I don't have a lot of small changes to keep 
track of.

Joe