Re: setting the number of pages for a score

[Han-Wen Nienhuys]

Joe Neeman wrote:
> > 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 

Yes.

> stencil height of the staff and I think most staves are likely to have 
> notes and markings above and below the staff.


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

yup.

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

Yup. You might even want to consider Drul_array<int> if you're doing 
left/right pairs. Are you using a break-node for a page-pair or a single 
 page?

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

Yes, that sounds good. I'll also have a look whether I can add something 
like System_spec to CVS HEAD.

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

We could switch between both breakers if a paper variable

  force-system-count

is defined.  Another option is to calculate the default breaking, and 
provide users with a

  change-system-count

variable (negative= set in fewer systems, positive=in more systems.) and 
then  do a second run with the constrained breaker.

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

Yes,  we should try to integrate patches to existing code with higher 
priority, since those will lead to conflicts more easily


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