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 - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
