Re: warnings during `make web'

[Juergen Reuter]

On Mon, 6 Nov 2006, Han-Wen Nienhuys wrote:

> The formatting backend doesn't use subclassing at all, except for the spanner 
> vs. item distinction. Therefore, subclassing by definition is the wrong 
> approach. How to organize code should be decided by looking which code is 
> shared. This is easiest to find out by first writing the code independently 
> from the existing code, and then collapsing the common parts.
>
> Without knowing the details, I think it is easiest to define a 
> LigatureNoteHead or XxxxxLigatureNoteHead, and a  XxxxLigature in 
> define-grobs.scm.  (Xxxxx = Gregorian, Vaticana, Coherent, Mensural)
>
> By copying some definitions of the NoteHead grob, some C++ of Note_head can 
> be shared.
>
> A special XXX_Ligature engraver will create those heads, and arrange them 
> correctly within the appropriate XxxxLigature. If the XxxxxLigature is an 
> Item, then it will be on a single PaperColumn.  By putting the XxxxNoteHeads 
> on the XxxxxLigature Item, the notes will also be on the same PaperColumn. 
> The XxxxLigature knows all of the ligature contents, and hence, it can 
> determine the final desired shape.

Ok, this may work provided that there is no code elsewhere in lily that 
receives grobs, looks into them and does some things if and only if this 
grob is a NoteHead.  Otherwise, this code would not apply to ligature 
heads, thus failing special treatment of note heads that should also 
apply on ligature heads.  I actually tried this approach a couple of years 
ago, and it did not work for this reason.  Of course, lily has changed 
dramatically since then; probably I should try again.

> > > IF my hunches are correct, most of the code will collapse and disappear 
> > > because of improvements in the rest of LilyPond.
>
> > I don't think so.  Most of the code is about matching grobs and moving them 
> > from different paper columns into a single one, determining the correct 
> > glyph for each notehead by evaluating local and neighbour heads' 
> > properties, adding new grobs (such as vertical lines) in the right place, 
> > collecting dots from different heads in different paper columns and moving 
> > them into a single dot column (I am already using DotColumn!), etc.
>
> Moving stuff around between paper columns should not be done in the 
> typography backend.

Sorry, I was imprecise.  Moving stuff around between paper columns is done 
in the engravers, of course.

Greetings,
Juergen