Making sure things run smoothly over the next two weeks

[Mike Solomon]

Hey all,

In this e-mail are a few tips if (when) you find a bug that comes from my recent Stem, Flag, and Tremolo work.

***

* FLAG extents are still kludgy.  You'll see that in Flag::width, the value returned is a half stem-width thinner than the actual width.  This is done to reflect how the calculations were effectuated before Flag was its own grob.  If there are spacing problems with flags (there are not currently any in the regtests, but ya never know, look here first.  It would be ideal if this kludge could be removed and if the flag grob's width could be taken straight from the stencil.  A way to do this may be to create a "kerning" property in the font that tells how far left from the right bound of a stem a flag grob should be moved.  Not that I want to put more work on Janek's plate, but as he is already in this part of the code, this seems like something he may be able to do with more ease than most of us.

* If spacing seems too ample in certain areas, check the STEM pure heights and heights with this function :

\override Stem #'stencil =

#(lambda (grob)

  (let ((y-ext (ly:stem::pure-height grob 0 100000))

         (stem (ly:stem::print grob)))

  (if (null? stem) (ly:make-stencil '() '(0 . 0) '(0 . 0)) (ly:stencil-add stem

    (stencil-with-color (ly:stencil-translate-axis (ly:stencil-translate-axis (make-line-stencil 0.2 0 (car y-ext) 0 (cdr y-ext)) 0 Y) -0.3 X) red)))))

This is the function I used to make sure that the pure height improvements I claimed were happening were in fact happening.

Y-extent is the ONLY property that indicates stem height now.  A quick glossary of what other old-and-now-defunct properties are in Y-extent.

stem-begin-position : in the Y-extent pair, the value that is in the opposite direction of the stem.  stem-begin-posiiton was * 2 / staff_space, whereas Y-extent gives the actual Y coordinate.

stem-end-position : in the Y-extent pair, the value that is in the direction of the stem.  stem-end-posiiton was * 2 / staff_space, whereas Y-extent gives the actual Y coordinate.

length : the absolute value of the difference of the two values in the Y-extent pair.  length was was * 2 / staff_space, whereas Y-extent gives the actual Y coordinate.

Note that manual overrides for stem Y-extent will, without unpure-pure-containers (see below), eliminate stems from pure height calculations.  If a devel release is made while I'm gone and if users complain that:

\override Stem #'Y-extent = #(stem::length 10)

causes collisions, tell them to try:

\override Stem #'Y-extent = #(ly:make-unpure-pure-container (stem::length 10) (stem::length 10))

Or, even better, rewrite stem::length to automatically be a pure-unpure container (in which case the user would need to make sure that the stem in question is not a stemlet - otherwise, this will not work the way they want it to, as stemlets use the beam and are not pure).

* If there is a grob that seems to shift irregularly and that somehow uses STEMS to determine its placement, make sure that:

a) The grob is using stems' pure height before line breaking; and

b) After line breaking, if the grob is aligning to beamed stems, the quantized-positions property of the beamed-stem is triggered.

If this still doesn't work, check the stem heights / pure heights.

* I'll be pushing the UNPURE-PURE-CONTAINRE patch on Wednesday.  This should have no bearing on the current code base's functionality, but can be a great tool for people who are uncomfortable with pure properties (which was me until a couple weeks ago) learn about these properties.  All of the pure stuff towards the bottom define-grobs.scm can (should?) be rewritten using this format.  For example, a lot of the functions in flag-styles.scm needed to be listed in pure-print-callbacks (define-grobs.scm) so that their pure height would be registered.  This is a temporary solution to a larger problem - if someone uses a stencil that is not on this list, its pure height will not be registered.  All of these stencils (and all of this list) should be rewritten as unpure-pure-containers.  An example:

remove ly:bar-line::print from pure-print-callbacks

make the Y-extent of BarLine (ly:unpure-pure-container ly:grob::stencil-height ly:grob::stencil-height)

In layman's terms, the unpure height of the BarLine is given by ly:grob::stencil-height and the pure height is given by the same function.

Of course, for someone more adventurous, you can come up with better interfaces for this.  For example, register the stencil for BarLine (and other similar grobs) as (ly:unpure-pure-container ly:bar-line::print ly:bar-line::print) and then modify the constructor function in grob.cc such that grobs with no Y-extent explicitly set have an unpure-pure-container of (ly:unpure-pure-container ly:grob::stencil-height ly:grob::stencil-height) set as the Y-extent if the stencil property is in an unpure-pure-container and if the unpure and pure part are equal.

In addition to making the code base more maintainable, unpure-pure properties may solve some of the potential problems listed above in cases where users are using overrides that result in weird horizontal spacing because of a lack of pure-height considerations.

****

And there you have it.  Most importantly, if you have any questions about my recent work, don't hesitate to get in touch before Thursday afternoon.  It is likely that some of you will wind up reporting and perhaps even fixing a bug that comes from this work, which I appreciate a great deal.  Hopefully this e-mail and any future correspondence of its ilk will attenuate any difficulties that these problems pose.

Cheers,

MS