Re: Allow scripts to be defined either as glyphs or stencils. (issue 348120043 by address@hidden)

[David Kastrup]

address@hidden 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