On 2019/02/22 21:51:39, Valentin Villenave wrote:
On 2019/02/22 21:00:08, dak wrote:
> You are confusing stencils with stencil expressions. Stencils
satisfy
> ly:stencil? and you can extract their stencil expression (which
usually is a
> pair) with ly:stencil-expr .
Yes, but what we’re dealing with in this function is a stencil
expression, isn’t
it? (At least, as long as it isn’t unsmobbed.)
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. Calling unsmob<Stencil> on its SCM representation
will deliver a 0 pointer. It is not a smob. A Stencil is a smob. It
will satisfy the ly:stencil? predicate and never will satisfy the pair?
predicate. Calling unsmob<Stencil> on its SCM representation will
deliver a valid Stencil * . Calling ly:stencil-expr on it will deliver
its stencil expression. A Stencil type contains both a stencil
expression and a bounding box. Those are basically indendent components
of a Stencil .
If I do
if (scm_is_pair (s) {} else *unsmob<Stencil> (s)
the stencil expression in "s" will never reach the "else" subroutine.
Wrong.
> I don't understand where the difference in what you do with
script-stencil as
a
> property and what you would do with stencil as a property would lie.
Forgive me for not understanding what you mean right away. Right now,
Script.stencil is defined as ly:script-interface::print which is where
glyphs
are looked up (or, with this new patch, stencil expressions), then
printed. Are
you suggesting that we scrap this interface and make Script.stencil
point to a
Scheme callback instead?
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.
https://codereview.appspot.com/348120043/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
