Re: [PATCH] Porrectus: first try

[Juergen Reuter]

On Mon, 10 Sep 2001, Han-Wen Nienhuys wrote:

> address@hidden writes:
> > +  written for the GNU LilyPond music typesetter
> 
> Yes, thanks. Integrated the patch into 1.5
> 

Thanks, too!

> > + * moment of the second note.  Actually, it should take the moment of
> > + * the first note.
> > + *
> > + * TODO: Introduce "\~" as alternative syntax for "\porrectus"?
> 
> Looking at the output, maybe it's more appropriate to have this
> engraver react to glissando requests?  OTOH, that might lead to weird
> syntax.
> 

Sounds reasonable.  I will have a look at it.

> > + * TODO: The following issues are not (and should not be) handled by
> > + * this engraver: (1) accidentals placement, (2) avoiding line
> > + * breaking inbetween porrectus, (3) spacing.  For example, currently
> 
> (2) should be handled by the engraver. Look at how the beam engraver
>     forbids line breaks.
> 

Mmmh.  The idea is to finally have complex ligatures, using syntax like

\ligature { e \porrectus c f \porrectus d }
or
\startLigature e \porrectus c f \porrectus d \endLigature

The enclosing delimiters will be necessary as soon as you will be 
able to construct complex ligatures by combining ligature primitives as in
the above example.  In particular, complex ligatures as a whole may not be
broken.  Hence, the idea is to let the delimiter code handle these issues
rather than each ligature primitive doing it by itself together with its
neighbouring primitives.  On the other hand, it should not harm if each
ligature primitive additionally tries to do the same job.

BTW., use of terms "primtive" and "complex" in this context is
a pure invention by me, but I think they fit quite well from a technical
point of view.

> > +     Item *left_head = dynamic_cast<Item*> (unsmob_grob (caar));
> > +     Item *right_head = dynamic_cast<Item*> (unsmob_grob (cdar));
> > +     left_head->set_grob_property("transparent", gh_bool2scm(true));
> 
> ( SCM_BOOL_T )
> 
> > +  if (left_head == SCM_EOL)
> > +    {
> > +      warning (_ ("(left_head == SCM_EOL) (ignored)"));
> > +    }
> 
> if this is a programming error, then use programming_error (). The
> error message looks as if it is not really meant for a
> user. programming_errors are also never translated.
> 

Ok.

> > +// Uugh.  The following two functions are almost duplicated code from
> > +// custos.cc, which itself is similar to code in note-head.cc.  Maybe
> > +// this should be moved to staff-symbol-referencer.cc?
> 
> Why not call Note_head::create_ledger_line () directly?
> 

Because all three versions differ in implementation.  In custos.cc,
a bug of note-head.cc regarding the minimal length of ledger lines was
corrected; effectively, custos.cc contains a complete rewrite of this
function.  But it still shares some bugs with the implementation in
note-head.cc (see custos.cc for detailed information).  In porrectus.cc,
the length of the ledger line must encounter both contributing note heads,
which results in another small change.  But it seems possible to rewrite
this function once again so that is applicable for all of the three grobs.

> > +
> > +  SCM left_head_scm = get_left_head (me);
> > +  SCM right_head_scm = get_right_head (me);
> > +  if ((left_head_scm == SCM_EOL) || (right_head_scm == SCM_EOL))
> > +    {
> > +      warning (_ ("junking lonely porrectus"));
> 
> maybe you want to call me->suicide () as well, to make a clean job of it.
> 

Ok.

> > +  Real space = Staff_symbol_referencer::staff_space (me);
> > +  Real line_thickness = space/6;
> > +  Real width = 2.4 * space;
> 
> We always make these tunable through grob-properties  ('thickness, 'width)
> 

Ok, will eventually be added.

> > +      bool consider_interval =
> > +   ((stem_direction == DOWN) && (interval < 0.0)) ||
> > +   ((stem_direction == UP) && (interval > 0.0));
> 
> i.e.
> 
> 
>       stem_direction * interval > 0.0
> 

Well, for readability, I personally prefer the first form, but I am also
happy with the second one.

> > +++ lilypond-1.5.9.NEW/scm/generic-property.scm     Mon Sep 10 00:10:15 2001
> > @@ -167,6 +167,16 @@
> >     (list (list 'noteNameStyle symbol? 'style))))
> >  
> >  
> > +(define generic-porrectus-properties
> > +  (cons 'porrectus-interface
>  
> this property setting interface is slated for removal. I added a note
> to the file.
> 

Ok.

> > +(grob-property-description 'stem-direction dir? "up or down?.")
> 
> Why not simply use 'direction?
> 

Because it only affects the direction of the stem, but not the direction
of the curved shape of vaticana and (TODO) hufnagel style porrectus.
On the other hand, I have not yet seen a vaticana style porrectus with an
upward stem.  I am not sure about hufnagel style.  Mensural notation
definitely uses stems in both directions, but since the shape of mensural
porrectus is symmetrical, you can philosophize on whether it also changes
its direction when the stem changes its direction. :-)

Greetings,
           Juergen

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