LSR: Update.

[lilypond.git] / Documentation / contributor / programming-work.itexi

diff --git a/Documentation/contributor/programming-work.itexi b/Documentation/contributor/programming-work.itexi
index a48df04ad7ca185f5107bf3d7cb86cb1a4ec67da..ace1646b1bc546e03ff87b8d17b89027e035a518 100644 (file)
--- a/Documentation/contributor/programming-work.itexi
+++ b/Documentation/contributor/programming-work.itexi
@@ -1198,7 +1198,7 @@ the status.
 @node Iterator tutorial
 @section Iterator tutorial
 
-FIXME -- this is a placeholder for a tutorial on iterators
+TODO -- this is a placeholder for a tutorial on iterators
 
 Iterators are routines written in C++ that process music expressions
 and sent the music events to the appropriate engravers and/or
@@ -1207,7 +1207,7 @@ performers.
 @node Engraver tutorial
 @section Engraver tutorial
 
-FIXME -- This is a placeholder for a tutorial on how engravers work.
+TODO -- This is a placeholder for a tutorial on how engravers work.
 
 Engravers are C++ classes that catch music events and
 create the appropriate grobs for display on the page.  Though the
@@ -1259,8 +1259,8 @@ processed prior to beginning the translation for the next timestep.
 
 In certain cases, an engraver might need to ensure private Scheme variables
 (with type SCM) do not get swept away by Guile's garbage collector: for example,
-a cache of the previous key signature which must persist persist between timesteps.
-The method @code{virtual derived_mark () const} can be used in such cases to mark
+a cache of the previous key signature which must persist between timesteps.  The
+method @code{virtual derived_mark () const} can be used in such cases to mark
 such objects as follows:
 
 @example
@@ -1273,7 +1273,7 @@ Engraver_name::derived_mark ()
 
 @subsection Listening to music events
 
-External interfaces to to the engraver are implemented by protected
+External interfaces to the engraver are implemented by protected
 macros including one or more of the following:
 
 @itemize
@@ -1366,7 +1366,7 @@ the engraver.
 @node Callback tutorial
 @section Callback tutorial
 
-FIXME -- This is a placeholder for a tutorial on callback functions.
+TODO -- This is a placeholder for a tutorial on callback functions.
 
 @node LilyPond scoping
 @section LilyPond scoping
@@ -1412,6 +1412,31 @@ This is a place to dump information that may be of use to developers
 but doesn't yet have a proper home.  Ideally, the length of this section
 would become zero as items are moved to other homes.
 
+@subsection Spacing algorithms
+
+Here is information from an email exchange about spacing algorithms.
+
+On Thu, 2010-02-04 at 15:33 -0500, Boris Shingarov wrote:
+I am experimenting with some modifications to the line breaking code,
+and I am stuck trying to understand how some of it works.  So far my
+understanding is that Simple_spacer operates on a vector of Grobs, and
+it is a well-known Constrained-QP problem (rods = constraints, springs
+= quadratic function to minimize).  What I don't understand is, if the
+spacer operates at the level of Grobs, which are built at an earlier
+stage in the pipeline, how are the changes necessitated by differences
+in line breaking, taken into account?  in other words, if I take the
+last measure of a line and place it on the next line, it is not just a
+matter of literally moving that graphic to where the start of the next
+line is, but I also need to draw a clef, key signature, and possibly
+other fundamental things -- but at that stage in the rendering
+pipeline, is it not too late??
+
+Joe Neeman answered:
+
+We create lots of extra grobs (eg. a BarNumber at every bar line) but
+most of them are not drawn. See the break-visibility property in
+item-interface.
+
 @subsection Info from Han-Wen Email
 
 In 2004, Douglas Linhardt decided to try starting a document that would