On 2019/02/22 22:11:58, dak wrote:
There is some fundamental confusion here. A stencil expression is a
list. It
never satisfies the ly:stencil? predicate and always satisfies the
pair?
predicate.
Oh, I see. I mixed up "unsmob" and "eval": a stencil expression becomes a Stencil when it’s eval’d, not unsmobbed.
A Stencil type contains both a stencil expression and a bounding box.
Indeed: I wondered if I had to create a Box object with appropriate X and y extents, but I realized that the stencil expression does that on its own when evaluated. (At least it’s my understanding.)
ly:script-interface::print is a Scheme callback (it may or may not be implemented in C++ but that's not really relevant). What does
overriding
script-stencil buy you that overriding stencil would not equally well
do? I
want to understand what this achieves in a better way than what we
have already. I’m still struggling to understand; are you referring to the stencil property of the grob? (Which, since we don’t have ScriptStaccato or ScriptMarcato defined as different grobs, would affect all Script objects regardless of their individual specifics?) «What we have» is convenient, as it allows for several Script objects to be defined as an alist, each one with different properties (e.g. avoid-slur, script-prio etc.) and a specific Feta glyph (even allowing for different glyphs depending on direction). That glyph lookup is defined as the script-stencil property, which effectively replaces the Script grob’s stencil (via the script-interface::print callback). (Please correct me if I’m wrong.) As I was aiming for the less disruptive change possible, I suggested that this script-stencil property could also be defined as a stencil expression (in which case there’s no font glyph lookup anymore), but preserving every other part of the current logic. I initially thought about adding an additional property (something maybe called "script-stencil-formatter", that would allow users to _both_ use a specific glyph _and_ throw in a (lambda (stil) (ly:stencil-scale stil)) function, for example. Then I decided against it. The current mechanism relies on the script-stencil property, in a rather inflexible way: see for example the hardcoded "feta" reference in script-interface.cc; I’m merely trying to make it a bit more versatile by allowing users to define new Script objects (or redefine existing ones) as stencil expressions (not just Feta glyphs), _within_ the alist-based structure we already offer (thus keeping the ability to fine-tune all the other properties available individually for each articulation type)… And within that alist, the relevant property happens to be named script-stencil, not just stencil. So I thought that’s where I’d look. V. https://codereview.appspot.com/348120043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
