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 - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
