[email protected] writes: > 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.
No, it doesn't. There is ly:interpret-stencil-expression for tracing a stencil expression via a generic callback function but that's for interpreting stencils when drawing, not for creating stencils. For creating a stencil from a bounding box and a stencil expression there is ly:make-stencil . Also there are various callbacks for creating outlines from stencils. >> 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.) No, you use ly:make-stencil to combine a stencil expression with a bounding box. >> 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? Yes? > (Which, since we don’t have ScriptStaccato or ScriptMarcato defined as > different grobs, would affect all Script objects regardless of their > individual specifics?) Sure, but you are trying to override stencils, aren't you? Why do you even place an entry for "script-stencil" then instead of just placing an entry for "stencil"? > «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.) But you are free to have stencil rather than script-stencil replaced, aren't you? > 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. What is there that you cannot put into stencil instead? > The current mechanism relies on the script-stencil property, in a rather > inflexible way: So why do you use script-stencil rather than stencil? > 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. That alist just contains a list of properties to override. It's your decision whether it overrides script-stencil or stencil. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
