lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] Porrectus: second try


From: Han-Wen Nienhuys
Subject: [PATCH] Porrectus: second try
Date: Thu, 20 Sep 2001 13:36:45 +0200

address@hidden writes:
> * New porrectus properties: porrectus-width, line-thickness.

Please use simply "width" and "thickness" we want to keep the number
of variables down.

> preceding note request as second argument.  But that results only in a
> "Separation_item: I've been drinking too much"; the porrectus will
> still be aligned with the second note.

it's possible to do it anyway, but indeed you need to twiddle a
lot. It's not a elegant solution.

> on
> > > the note heads.
> >
> > You can always copy the relevant information from the grobs and then
> > kill them.  
> 
> If I kill a note-head item, I fear that other engravers or grobs may
> assume this note-head still to be alive.  Or do you think that should
> not be a problem?

No. Shouldn't be a problem. Or rather: if it were, that would be a bug.

> 
> > An entirely different way of handling it is, to take somehow take over
> > the note head engraver (i.e. modifying it to temporarily switch it
> > off), and have the porrectus engraver accept Note_reqs and generate the
> > ligature without any note head grobs. That also stops the stem
> > engraver from generating stems. It would however, require prefix
> > syntax, something like
> >
> >              \startLigature c4 d4 \endLigature
> 
> Ok, I think I finally got it: I need prefix syntax, because this seems
> to be the only way to avoid the above "I've been drinking too much"
> problem (unless I rewrite the music iteration process...).  Since,
> as

note that prefix syntax is not necessary per se, since you can parse
the first note and the following \~ as a single syntactical construct
and internally switch the order of the two.

-- 

Han-Wen Nienhuys   |   address@hidden    | http://www.cs.uu.nl/~hanwen/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]