Re: warnings during `make web'

[Han-Wen Nienhuys]

Juergen Reuter escreveu:

> > > The easiest solution that I can see is to tolerate little polution of 
> > > "noteheads.cc" and just add the missing interface declaration at the 
> > > end of this file.  However, that's not my decision...
> >
> > I think that this is going about the problem in the wrong way. Given 
> > how much lily has changed over the years, the proper solution IMO is 
> > to redo the ligature stuff completely.
>
> Mmmh, but how?  Given, that things have changed, as you state, do you 
> think there should be a completely new "ligatureheads.cc"?  If so, 
> should I clone the print and internal_print methods or rather try to 
> create a subclass?  I think a ligature primitive _is_ a special note 
> head, so modeling it as a subclass does not sound bad, even if stems are 
> not used.

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.

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

--

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

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com