Re: [PATCH] Porrectus: second try

[Juergen Reuter]

On Thu, 20 Sep 2001, Han-Wen Nienhuys wrote:

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

I had a look at grob-property-description.scm.  It already contains both,
thickness and line-thickness.  Semantically, line-thickness matches
exactly:

(grob-property-description 'line-thickness number? "the
thickness[stafflinethickness] of the line.")

More important, it might be provident to reserve property name thickness
for the thickness of the porrectus shape.

Regarding use of the term width, grob-property-descriptions.scm contains
arch-width, beam-width, bracket-thick for system start bracket width,
flag-width-function, minimum-width reserved for use in context of rests
only, note-width. But, currently, there is no property width defined in
grob-property-descriptions.scm.

>From that, I guessed that all width properties should consistently be
named according to the form <grob-name>-width.  Why should it be different
for porrectus?

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

Ok, looks like the "take over" approach will finally make it.

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

Ok, before deciding for the "take over" approach, I still will have a look
at it.

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

Theoretically, of course.  But, in practice, I guess this would mean to
restructure quite a lot of the parser, since there may be yet other
syntactical constructs between the first note and the following \~ that
also would have to be regarded.

Greetings,
           Juergen